Exactly Once 语义在 Flink 中的实现

数据流和动态表

传统SQL和流处理

特征	SQL	流处理
处理数据的有界性	处理的表是有界的	流是一个无限元祖序列
处理数据的完整性	执行查询可以访问完整的数据	执行查询无法访问所有的数据
执行时间	批处理查询产生固定大小结果后终止	查询不断更新结果,永不终止

数据流和动态表转换

Stream: 数据流 Dynamic Table: 动态表 Continuous Queries: 连续查询 Append-only Stream: Append-only 流（只有 INSERT 消息） Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息） Upsert Stream:: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息） Changelog: 包含 INSERT/UPDATE/DELETE 等的数据流 State: 计算处理逻辑的状态

一致性保证语义

• At-most-once：每条数据消费至多一次，处理延迟低
• At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
• Exactly-once(最严格)：每条数据都被消费且仅被消费一次，仿佛故障从未发生

Exactly-once和Checkpoint

制作快照的时间点

• 状态恢复的时间点：需要等待所有处理逻辑消费完成 source保留状态及之前的数据。

快照制作算法:

1. 暂停处理输入的数据
2. 等待后续所有处理算子消费当前已经输入的数据：
3. 待2处理完后，作业所有算子复制自己的状态并保 存到远端可靠存储；
4. 恢复对输入数据的处理

Checkpoint 对作业性能的影响

1. 解耦了快照制作和数据处理过程，各个算子制作完成状态快照后就可以正常处理数据，不用等下游算子制作完成快照；
2. 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍然会增加数据处理延迟；
3. 快照保存到远端也有可能极为耗时。

Flink端到端的Exactly-once语义

两阶段提交协议（2PC）

• 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后停止处理后续数据，对当前状态制作快照，此时sik也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向JM发送成功的消息，失败则发送失败的消息；
3. 提交阶段：若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink)发送可以提交此次事务的消息，sik接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据；若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时sik则丢弃这次事务提交的数据下。