👉引言💎
学习的最大理由是想摆脱平庸，早一天就多一份人生的精彩；迟一天就多一天平庸的困扰。 热爱写作，愿意让自己成为更好的人............
| 铭记于心 | ||
| 🎉✨🎉我唯一知道的，便是我一无所知🎉✨🎉 |
三、端到端 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 预提交阶段
- 协作者向所有参与者发送一个commit消息;
- 每个参与的协作者收到消息后,执行事务,但是不真正提交;
- 若事务成功执行完成,发送一个成功的消息(vote yes);执行失败,则发送一个失败的消息(vote no)
- 3.2 提交阶段
- 若协作者成功接收到所有的参与者vote yes的消息,则将有以下系列步骤:
- 协作者向所有参与者发送一个commit消息;
- 每个收到commit消息的参与者释放执行事务所需的资源,并结束这次事务的执行
- 完成步骤2后,参与者发送一个ack消息给协作者
- 协作者收到所有参与者的ack消息后,标识该事务执行完成
- 若协作者有收到参与者vote no的消息(或者发生等待超时):
- 协作者向所有参与者发送一个rollback消息
- 每个收到rollback消息的参与者回滚事务的执行操作,并释放事务所占资源
- 完成步骤2后,参与者发送一个ack消息给协作者
- 协作者收到所有参与者的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中 - 当前方案
- 在上次记录的位点之后,从Kafka中读取固定大小的数据;
- 对该批数据进行去重和聚合计算,
- 处理完成后写入Mysql中,若全部写入成功,则记录下当前读取到的消息的终止位置;若处理或者写入失败,则不记录位点;
- 跳回步骤1
- 存在的问题:
- 非严格意义上的端到端的Exactly-Once语义:若该批数据处理完成后,在写入MySQL中发生异常,则存在部分数据写入的情况,下次作业启动后,这部分数据仍然会重复写入;
- 去重能力有限:只能在当前处理的一批数据内进行去重,无法在批与批之间进行去重
- Flink解决方案:
严格意义上的端到端的Exactly-Once语义:下游读到的数据是不丢不重的;
增强的去重能力:可以在更长的时间维度对数据进行去重
- 2.2 支持两阶段提交协议的下游存储可以结合Flink Checkpoint机制实现严格意义上端到端的Exactly-Once 语义实现
- 数据流与动态表之间可以互相转化
- 处理无线数据流的算子可以是有状态的
- Flink通过Checkpoint机制实现故障前后的状态快照制作和恢复
- 支持两阶段提交协议的下游存储可以结合Flink Checkpoint 机制实现严格意义上的端到端Exactly-Once语义实现
问题
- 流式处理中算子为什么会有状态？
对历史记录进行存储，以便于后续修改 - 数据流和动态表之间是如何进行转换的？.
在某一时刻对流数据的查询就是一个静态表，通过两种流处理机制 动态化，反之 Upsert 流可以将动态表转化为数据流 - Flink 作业为什么需要考虑故障恢复？
无限数据流的处理，没有一个精确精确时刻进行数据回滚以及故障修复，容易造成数据损失 - Flink 故障恢复前为什么需要Checkpoint？
- 为什么不能保留任意时刻的状态作为故障恢复的时间点？
- Flink Checkpoint 对作业性能的影响有多大？
- 两阶段提交协议对性能影响有多大？
- 写入下游如果不支持事务读写，能做到 Exactly-Once 语义么？
🌹写在最后💖： 路漫漫其修远兮，吾将上下而求索！伙伴们，再见！🌹🌹🌹
