👉引言💎

学习的最大理由是想摆脱平庸，早一天就多一份人生的精彩；迟一天就多一天平庸的困扰。 热爱写作，愿意让自己成为更好的人............

三、端到端 Exactly-Once 实现

1 名词解析

• Two-phase commit protocol: 两阶段提交协议
  
• Transaction: 一系列保证原子性操作的集合，即操作同时执行或者都不执行
  
• Kafka: 消息中间件
  
• State Backend: 用于管理和保存状态到远端可靠存储

2 端到端的Exactly-once 语义

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

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

• Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点
  
• Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点

• 3.1 预提交阶段

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

• 3.2 提交阶段

• 若协作者成功接收到所有的参与者vote yes的消息,则将有以下系列步骤:

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

• 若协作者有收到参与者vote no的消息(或者发生等待超时):

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

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

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

5 Flink两阶段提交总结

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

四、Flink 案例讲解

1 名词解析

• Deduplication：去重，在 state 保留的时间内对重复消息进行去重
  
• Aggregation：聚合操作，比如求和、求最大值等

2 案例介绍

• 2.1账单计算服务 举例

• 场景简介
  从Kafka中读取账单消息,进行处理后写入到MySQL中
  
• 当前方案

1. 在上次记录的位点之后,从Kafka中读取固定大小的数据;
   
2. 对该批数据进行去重和聚合计算,
   
3. 处理完成后写入Mysql中,若全部写入成功,则记录下当前读取到的消息的终止位置;若处理或者写入失败,则不记录位点;
   
4. 跳回步骤1
   

• 存在的问题:

• 非严格意义上的端到端的Exactly-Once语义:若该批数据处理完成后,在写入MySQL中发生异常,则存在部分数据写入的情况,下次作业启动后,这部分数据仍然会重复写入;
  
• 去重能力有限:只能在当前处理的一批数据内进行去重,无法在批与批之间进行去重
  

• Flink解决方案:
  
  严格意义上的端到端的Exactly-Once语义:下游读到的数据是不丢不重的;
  增强的去重能力:可以在更长的时间维度对数据进行去重

• 2.2 支持两阶段提交协议的下游存储可以结合Flink Checkpoint机制实现严格意义上端到端的Exactly-Once 语义实现

• 数据流与动态表之间可以互相转化
  
• 处理无线数据流的算子可以是有状态的
  
• Flink通过Checkpoint机制实现故障前后的状态快照制作和恢复
  
• 支持两阶段提交协议的下游存储可以结合Flink Checkpoint 机制实现严格意义上的端到端Exactly-Once语义实现

问题

1. 流式处理中算子为什么会有状态？
   对历史记录进行存储，以便于后续修改
   
2. 数据流和动态表之间是如何进行转换的？.
   在某一时刻对流数据的查询就是一个静态表，通过两种流处理机制 动态化，反之 Upsert 流可以将动态表转化为数据流
   
3. Flink 作业为什么需要考虑故障恢复？
   无限数据流的处理，没有一个精确精确时刻进行数据回滚以及故障修复，容易造成数据损失
   
4. Flink 故障恢复前为什么需要Checkpoint？
   
5. 为什么不能保留任意时刻的状态作为故障恢复的时间点？
   
6. Flink Checkpoint 对作业性能的影响有多大？
   
7. 两阶段提交协议对性能影响有多大？
   
8. 写入下游如果不支持事务读写，能做到 Exactly-Once 语义么？
   

🌹写在最后💖： 路漫漫其修远兮，吾将上下而求索！伙伴们，再见！🌹🌹🌹