Exactly Once|青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第五天，在听完课《Exactly Once 语义在 Flink中的实现》，回忆的过程中，发现这一部分蕴含了很多自己并未真正理解的知识点，为了加深自己的理解，对于本课时，做了一些整理如下：

1.数据流和动态表

1.1 在流上定义表

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

1.2 连续查询和实时流的查询特点

• 查询从不终止
• 查询结果会不断更新，并且会产生一个新的动态表
• 结果的动态表也可转换成输出的实时流
• 在任何时候，连续查询的结果在语义上与以批处理模式在输入表快照上执行的相同查询的结果相同

1.3 动态表到实时流的转换

• Append-only Stream: Append-only 流（只有 INSERT 消息）
• Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）

2.1 一致性保证语义

• At-most-once:出现故障的时候，啥也不做，数据处理不保证任何语义，处理时延低
• At-least-once:保证每条数据至少被处理一次。一条数据可能存在重复消费
• Exactly-once:最严格的处理语义，从输出结果来看。每条数据均被消费且仅消费一次

2. Exactly-Once 和 Checkpoint

2.2 Checkpoint

• 状态快照与恢复-

• 制作快照的时间点

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

  • 一个简单的快照制作算法

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

• Chandy-Lamport 算法

• Checkpoint barrier 的下发： 每一个source算子都接受到JM发送的Checkpoint Barrier 标识状态快照制作的开始

• 算子状态制作和 barrier 传递： 各个source保存自己状态后，向所有连接的下游继续发送 Checkpoint Barrier，同时告知JM自己状态已经制作完成

• 多个上游的等待 barrier 对齐现象，Barrier Alingnment：

• 算子会等待所有上游的barrier到达后才开始快照的制作

• 已经制作完成的上游算子会继续处理数据，并不会被下游算子制作快照的过程阻塞

• Checkpoint 快照制作和处理数据的解耦

• Checkpoint ACK和制作完成： 所有算子都告知JM状态制作完成后，整个checkpoint 就结束了

3. 端到端 Exactly-Once 实现

3.1 端到端 Exactly-Once 语义

• Checkpoint能保证每条数据都对各个有状态的算子更新一次，sink输出算子仍然可能下发重复的数据
• 严格意义的端到端的Exactly-Once 语义需要特殊的sink算子实现

3.2 两阶段提交协议（2PC）

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

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

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

3.2.1 预提交阶段

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

3.2.2 提交阶段

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

  • 协作者向所有参与者发送一个commit消息
  • 每个收到commit消息的参与者释放执行事务所需要的资源，并结束这次事务执行
  • 完成上步骤后，参与者发送一个ack消息给协作者
  • 协作者收到所有参与者的ack消息后，标识该事务执行完成

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

  • 协作者向所有参与者发送一个rollback消息
  • 每个收到rollback消息的参与者回滚事务的执行操作，释放事务所占的资源
  • 完成上步骤后，参与者发送一个ack消息给协作者
  • 协作者收到所有参与者的ack消息后，标识该事务执行完成回滚

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

• Flink 中协作者和参与者的角色分配
• 协作者（JobManager）发起阶段一提交
• 各算子 Checkpoint 的制作
• 提交阶段及 Checkpoint 的制作完成

3.4 Flink 两阶段提交总结

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