Exactly Once 语义在 Flink 中的实现 | 青训营笔记

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

1. 数据流和动态表

传统 SQL 和流处理

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

动态表：与表示批处理数据的静态表不同，动态表是随时间变化的。可以向查询静态批处理表一样查询它们。

不同数据处理保证的语义：

0. At-most-once：出现故障的时候，啥也不做。数据处理不保证人恶化语义，处理时延低；
1. At-least-once：保证每条数据均至少被处理依次，一条数据可能存在重复消费。
2. Exactly-once：最严格的语义，从输出结果来看，每条数据均被消费且仅消费一次，仿佛故障从未发生。

2. Exactly-Once 和 Checkpoint

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

一个简单的快照制作方法：

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

Chandy-Lamport 算法

3. 端到端 Exactly-Once 实现

两阶段提交协议：在多个节点参与执行的分布式系统中，为了协调每个节点都能同时执行或者回滚某个事务性的操作，引入了一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫作 协作者，被中心节点调度的节点叫作 参与者

• 预提交阶段

  0. 协作者向所有参与者发送一个 commit 消息；
  1. 每个参与的协作者收到消息后，执行事务，但是不真正提交；
  2. 若事务成功执行完成，发送一个成功的消息（vote yes）；执行失败，则发送一个失败消息（vote no）；

• 提交阶段

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

  0. 协作者向所有参与者发送一个 commit 消息；
  1. 每个收到 commit 消息的参与者释放执行事务所需的资源，并结束这次事务的执行；
  2. 完成步骤 2 后，参与者发送一个 ack 消息给协作者；
  3. 协作者收到所有参与者的 ack 消息后，表示该事务执行完成。

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

  0. 协作者向所有参与者发送一个 rollback 消息；
  1. 每个收到 rollback 消息的参与者回滚事务的执行操作，并释放事务所占的资源；
  2. 完成步骤 2 后，参与者发送一个 ack 消息给协作者；
  3. 协作者收到所有参与者的 ack 消息后，标识该事务成功完成回滚。

Flink 两阶段提交总结：

0. 事务开启：在 Sink task 向下游写数据之前，均会开启一个事务，后续所有写数据的操作均会在这个事务中执行，事务未提交前，事务写入的数据下游不可读；
1. 预提交阶段：JobManager 开始下发 Checkpoint Barrier，当每个处理逻辑接收到 barrier 后停止处理后续数据，对当前状态制作快照，此时 sink 也不在当前事务下继续处理数据（处理后续的数据需要更新打开下一个事务）。状态制作成功则向 JM 发送成功消息，失败则发送失败的消息；
2. 提交阶段：若 JM 收到所有预提交成功的消息，则向所有逻辑（包括 sink）发送可以提交此次事务的消息，sink 接收到此消息后，则完成此次事务的提交，此时下游可以读到此次事务写入的数据；若 JM 有收到预处理失败的消息，则通知所有处理逻辑回滚这次事务的操作，此时 sink 则丢弃这次事务提交的数据。