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

用户7347976837029
83 阅读5分钟

这是我参与「第四届青训营 」笔记创作活动的第3天，本文将介绍Flink+Kafka如何实现端到端的exactly-once语义。

1.端到端Exactly-once语义

  • Exactly-Once 是 Flink、Spark 等流处理系统的核心特性之一，这种语义会保证每一条消息只被流处理系统处理一次。
  • Flink 自身是无法保证外部系统“精确一次”语义的，所以 Flink 若要实现所谓“端到端（End to End）的精确一次”的要求，那么外部系统必须支持“精确一次”语义；然后借助 Flink 提供的分布式快照和两阶段提交才能实现。

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

2.两阶段提交协议

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

image.png

2.1预提交阶段

若协作者(coordinator)成功接收到所有的参与者vote yes的消息 ， 则：
1．coordinator向所有participant发送一个commit消息; 2．每个收到commit消息的participant释放执行事务所需的资源，并结束这次事务的执行; 3．完成步骤2后，participant发送一个ack消息给coordinator; 4.coordinator收到所有participant的ack消息后，标识该事务执行完成。

2.2提交阶段

若coordinator有收到participantvote no的消息（或者发生等待超时)∶
1．coordinator向所有participant发送一个rollback消息;
2．每个收到rollback消息的participant回滚事务的执行操作，并释放事务所占资源;
3．完成步骤2后，participant发送一个ack消息给coordinator;
4. coordinator收到所有participant的ack消息后，标识该事务成功完成回滚。

若coordinator有收到participantvote no的消息(或者发生等待超时)： 1．coordinator向所有participant发送一个rollback消息;
2．每个收到 rollback消息的participant回滚事务的执行操作，并释放事务所占资源;
3．完成步骤2后，participant发送一个ack消息给coordinator;
4. coordinator收到所有participant的ack消息后，标识该事务成功完成回滚。

3.Flink中2PC Sink

Flink由JobManager协调各个TaskManager进行checkpoint存储，checkpoint保存在 StateBackend中，默认StateBackend是内存级的，也可以改为文件级的进行持久化保存。 image.png

①当 checkpoint 启动时，JobManager 会将检查点分界线（barrier）注入数据流；barrier会在算子间传递下去。

image.png

②每个算子会对当前的状态做个快照，保存到状态后端。对于source任务而言，就会把当前的offset作为状态保存起来。下次从checkpoint恢复时，source任务可以重新提交偏移量，从上次保存的位置开始重新消费数据。 image.png

③每个内部的 transform 任务遇到 barrier 时，都会把状态存到 checkpoint 里。sink 任务首先把数据写入外部 kafka，这些数据都属于预提交的事务（还不能被消费）；

遇到 barrier 时，把状态保存到状态后端，并开启新的预提交事务。

image.png

④当所有算子任务的快照完成，也就是这次的 checkpoint 完成时，JobManager 会向所有任务发通知，确认这次 checkpoint 完成。

当sink 任务收到确认通知，就会正式提交之前的事务，kafka 中未确认的数据就改为“已确认”，数据就真正可以被消费了。

image.png 两阶段提交步骤总结：

  • 第一条数据来了之后，开启一个 kafka 的事务（transaction），正常写入 kafka 分区日志但标记为未提交，这就是“预提交”
  • jobmanager 触发 checkpoint 操作，barrier 从 source 开始向下传递，遇到 barrier 的算子将状态存入状态后端，并通知 jobmanager
  • sink 连接器收到 barrier，保存当前状态，存入 checkpoint，通知jobmanager，并开启下一阶段的事务，用于提交下个检查点的数据
  • jobmanager 收到所有任务的通知，发出确认信息，表示 checkpoint 完成
  • sink 任务收到 jobmanager 的确认信息，正式提交这段时间的数据
  • 外部kafka关闭事务，提交的数据可以正常消费了。

4.总结

image.png 1.事务开启:在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行事务未提交前，事务写入的数据下游不可读;

2.预提交阶段:JobManager开始下发Checkpoint Barrier，当各个处理逻辑接收到barrier后停止处理后续数据，对当前状态制作快照，此时 sink 也不在当前事务下继续处理数据（处理后续的数据需要新打开下一个事务)。状态制作成功则向JM成功的消息，失败则发送失败的消息;

3.提交阶段:若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink)发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事务的提交，此时下游可以读到这次事务写入的数据;若JM有收到预提交失败的消息则通知所有处理逻辑回滚这次事务的操作，此时sink则丢弃这次事务提交的数据下。

avatar
文章
阅读
粉丝