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

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

1. 数据流和动态表

   1. 传统SQL和流处理

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

   2. 数据流和动态表转换

   

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

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

   Retarct：回撤消息，流式处理中出现的消息模式

   3. 状态：为了查询中的数据保证，查询有状态，用来不断更新查询的结果

   4. 不同数据处理保证的语义

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

2. Exactly-once和Checkpoint

   1. 状态快照与恢复

      故障发生时处理的措施

   2. 制作快照的时间点

      1. 状态恢复的时间点：需要等待所有处理逻辑消费完成source保留状态及之前的数据
      2. 一个简单的快照制作算法：
         1. 暂停处理输入的数据
         2. 等待后续所有处理算子消费当前已经输入的数据
         3. 等2处理完，作业所有算子复制自己的状态并保存到远端可靠存储
         4. 恢复对输入数据的处理

   3. Chandy-Lamport算法

      1. 快照制作的开始

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

      2. Source算子的处理

         各个source保存自己状态后，向所有链接的下游继续发送Checkpoint Barrier，同时告知JM自己状态已经制作完成

      3. Barrier Alignment

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

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

      4. 快照制作和数据解耦

      5. Chaeckpoint的结束

         所有算子都告诉JM快照制作完成，整个Checkpoint就结束了

   4. Checkpoint对作业性能的影响

      1. 各个算子完成制作就可以正常处理数据
      2. 在快照制作和Barrier Alignment过程中需要暂停处理数据，仍会增加数据处理延迟
      3. 快照保存到远端也有可能极为耗时

3. Flink端到端的Exactly-once语义

   1. 两阶段提交协议

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

      1. 预提交阶段
         1. 协作者向所有参与者发送一个commit消息
         2. 每个参与的协作者收到消息后，执行事务，但是不真正提交
         3. 若事务成功执行完成，发送一个成功的消息（vote yes）；执行失败，则发送一个失败的消息（vote no）
      2. 提交阶段
         1. 发送vote yes消息：
            1. 协作者向所有参与者发送一个commit消息
            2. 每个收到commit消息的参与者执行释放执行事务所需的资源，并结束这次事务的执行
            3. 完成步骤2后，参与者发送一个ack消息给协作者
            4. 协作者收到所有参与者的ack消息后，标识该事务执行完成
         2. 发送vote no消息：
            1. 协作者向所有参与者发送一个rollback消息
            2. 每个收到rollback消息的参与者回滚事务的执行操作，并释放事务所占资源
            3. 完成步骤2后，参与者发送一个ack消息给协作者
            4. 协作者收到所有参与者的ack消息后，标识该事务成功完成回滚