这是我参与「第四届青训营 」笔记创作活动的第5天

Exactly Once 语义在 Flink 中的实现

01.数据流和动态表

动态表：随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们

连续查询：查询结果会不断更新，产生一个新的动态表****

出现故障时：一致性保证语义

At-most-once：每条数据消费至多一次，处理延迟低

At-least-once：每条数据消费至少一次，一条数据可能存在重复消费

Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生

02.Exactly-Once和Checkpoint

状态快照：数据存储的某一时刻的状态记录

简单的快照制作算法：

1.暂停处理输入的数据

2.等待后续所有算子消费当前已经输入的数据

3.待2处理完后，作业所有算子复制自己的状态并保存到远端可靠存储

4.恢复对输入数据的处理.

Checkpoint对作业性能的影响：

1.解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作制作完成快照；

2.在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟；

3.快照保存到远端也有可能极为耗时。

03.端到端Exactly-Once实现

两阶段提交协议：

Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点

Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点

（一）-预提交阶段

1.协作者向所有参与者发送一个commit 消息；

2.每个参与的协作者收到消息后，执行事务，但是不真正提交；

3.若事务成功执行完成，发送一个成功的消息(vote yes );执行失败，则发送一个失败的消息(vote no)

（二）-提交阶段

若协作者成功接收到所有的参与者vote yes 的消息

    1.协作者向所有参与者发送个commit 消息；

    2.每个收到commit 消息的参与者释放执行事务所需的资源，并结束这次事务的执行；

    3.完成步骤2后，参与者发送个ack消息给协作者；

    4.协作者收到所有参与者的ack消息后，标识该事务执行完成。

若协作者有收到参与者vote no 的消息（或者发生等待超时）

    1.协作者向所有参与者发送个rollback 消息；

    2.每个收到rollback 消息的参与者回滚事务的执行操作，并释放事务所占资源；

    3.完成步骤2后，参与者发送一个ack消息给协作者；

    4.协作者收到所有参与者的ack消息后，标识该事务成功完成回滚。

两阶段提交协议在 Flink 中的应用：

1.事务开启：在sink task 向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读；

2.预提交阶段：JobManager 开始下发Checkpoint Barrier ,当各个处理逻辑接收到barrier)后停止处理后续数据，对当前状态制作快照，此时sink也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向JM成功的消息，失败则发送失败的消息；

3.提交阶段：若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink)发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据；若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据下。