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

  👉引言💎

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

	铭记于心
	🎉✨🎉我唯一知道的，便是我一无所知🎉✨🎉

三、端到端 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 语义么？

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