Exactly Once 语义在 Flink 中的实现 | 青训营笔记这是我参与「第四届青训营」笔记创作活动的第3天

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

数据流和动态表的概念

动态表 ： 随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们

如图，在stream不断流入数据从而形成动态表。对于这个动态表可以不断进行SQL查询，然后有得到另一个动态表。而这个动态表是因为查询从不终止（Continuous Queries: 连续查询），并且查询结果不断更新。

查询的对比

这种可以理解成一条一条处理，对于新的数据，我们需要去更新先前输出的结果，即定义结果的changelog流包含INSERT和UPDATE操作。这种是按小时分组每一组的结果输出到一张表中，是所以结果表的changelog流只包含INSERT操作

这种就是需要引用Retract机制，对于新的stream数据，需要查询state，然后根据state取retract数据和insert数据。

对于stream流计算这里可以抽象成数字流进行计算，这里有三个计算：

假设我们对于消费5的时候做一个备份，保存它的消费位点以及当前的累加和。然后我们消费6，此时没有出现问题，但是到我们消费7的时候，sum_odd出现问题，导致作业运行不下去。当我们修复这个问题后，重启作业，然后拿上一个保存点的状态去恢复之前的状态，然后从5之后从新消费6、7，这样保证了数据不丢不重。

制作快照的时间点：需要等待所有处理逻辑消费完成source保留状态及之前的数据。

快照制造算法：

在这个过程中JM会向source发送CheckpointBarrier表示制作开始。

各个source保存自己状态后，向所有连接的下游继续发送Checkpoint Barrier，同时告知JM自己状态已经制作完成，之后可以继续处理数据，不需要等待下游的算子的制作。

在这个过程中：

所有算子都告知JM状态制作完成后，整个Checkpoint就结束了

cd6c4d3ef3cd486fa5b7eb5a7bc2e36e~tplv-k3u1fbpfcp-zoom-in-crop-mark 3024 0 0 0.webp

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

若协作者成功接收到所有的参与者vote.yes的消息：

若协作者有收到参与者vote.no的消息（或者发生等待超时）：

两阶段提交协议总结：

事务开启：在sink task向下游写数据之前，均会开启一个事务，后续所有写数据的操作均在这个事务中执行，事务未提交前，事务写入的数据下游不可读；
预提交阶段：JM开始下发Checkpoint Barrier，当各个处理逻辑接收到barrier后停止处理后续数据，对当前状态制作快照，此时sink也不再当前事务下继续处理数据（处理后续的数据需要新打开下一个事务）。状态制作成功则向JM发送成功的消息，失败则发送失败的消息；数据已经写到kafka，但没有commit，下游不可读。
提交阶段：若JM收到所有预提交成功的消息，则向所有处理逻辑（包括sink）发送可以提交此次事务的消息，sink接收到此消息后，则完成此次事物的提交，下一次恢复可以从这个点安全的从新写数据，此时下游可以读到这次事务写入的数据；若JM有收到预提交失败的消息，则通知所有处理逻辑回滚这次事物的操作，此时sink 搜到回滚时，将kafka中所有的数据丢弃，下游永远不会读到，consumer负责读kafka的数据会直接跳过，读下一部分的数据。