[PyFlink 从入门到精通] Exactly-Once 的实现

1、常见的语义特征

常见的语义特性有如下 3 种：

• Exactly-Once：严格一次（中断后从断点恢复）。数据或事件可以保证被应用程序中的所有运算符严格地仅处理一次。
• At-Most-Once：最多一次（中断后从当前恢复）。数据或事件可以保证被应用程序中的所有运算符最多处理一次。
• At-Least-Once：最少一次（中断后从头恢复）。数据或事件可保证被应用程序图中的所有运算符最少处理一次。

看上去 Exactly-Once 是比较理想的特性，有两种方式来实现这种特性：

• 分布式状态快照：性能和资源开销小，但从失败的的影响是全局的，且随着拓扑规模增大，影响将增高。
• At-Least-Once + 去重：性能开销巨大，但失败的影响是局部的。

实现方式	优点	缺点
分布式状态快照	性能和资源开销小（操作符处理事件时，仅需异步地发送少量状态检查事件）	1）失败时需要暂停应用并回滚所有操作符的状态；2）随着拓扑规模逐渐增大，对性能的潜在影响将增大
At-Least-Once + 去重	1）对性能和资源的影响是局部的； 2）失败的影响未必随着拓扑规模一起增加	1）失败时仅对发生失败的运算符造成影响；2）每个运算符处理每个事件均会产生性能开销（需要执行去重操作）；3）可能需要存储与基础架构提供支持

2、Flink 中的 Exactly-Once 实现

Flink 提供的 Exactly-Once 的语义特性，是通过基于 checkpoint 的状态快照和流重放两种方式组合实现的，由 Chandy-Lamport 分布式快照算法 启发而来。

故障未发生时：

• 在执行任务时，会异步地为每个算子的所有状态创建检查点并记录，同时也会异步地将数据源中消费数据的偏移量记录下来，所有状态快照会存储到一个“持久的状态存储后端”。

故障发生后：

• 每个算子的所有状态会回滚至最新的全局一致检查点。回滚过程中所有处理工作会暂停。随后源也会重置为与最新检查点相符的偏移量。整个流应用程序基本上会被回退到最新一致状态，并从该状态开始重新处理。

下面图文说明一下这个过程，方便理解。

Step1：如下所示，一个 Kafka topic，有两个partition，每个partition都含有 “A”, “B”, “C”, ”D”, “E” 5条消息。我们将两个partition的偏移量（offset）都设置为0.

image

Step2：Kafka comsumer（消费者）开始从 partition 0 读取消息。消息“A”正在被处理，第一个 consumer 的 offset 变成了1。

image

Step3：消息“A”到达了 Flink Map Task。两个 consumer 都开始读取他们下一条消息（partition 0 读取“B”，partition 1 读取“A”）。各自将 offset 更新成 2 和 1 。同时，Flink 的 JobMaster 开始在 source 触发了一个检查点。

image

Step4：接下来，由于 source 触发了检查点，Kafka consumer 创建了它们状态的第一个快照（”offset = 2, 1”），并将快照存到了 Flink 的 JobMaster 中。Source 在消息“B”和“A”从partition 0 和 1 发出后，发了一个 checkpoint barrier。Checkopint barrier 用于各个 operator task 之间对齐检查点，保证了整个检查点的一致性。消息“A”到达了 Flink Map Task，而上面的 consumer 继续读取下一条消息（消息“C”）。

image

Step5：Flink Map Task 收齐了同一版本的全部 checkpoint barrier 后，那么就会将它自己的状态也存储到 JobMaster。同时，consumer 会继续从 Kafka 读取消息。

image

Step6：Flink Map Task 完成了它自己状态的快照流程后，会向 Flink JobMaster 汇报它已经完成了这个 checkpoint。当所有的 task 都报告完成了它们的状态 checkpoint 后，JobMaster 就会将这个 checkpoint 标记为成功。从此刻开始，这个 checkpoint 就可以用于故障恢复了。值得一提的是，Flink 并不依赖 Kafka offset 从系统故障中恢复。

image

Step7：在发生故障时（比如，某个 worker 挂了），所有的 operator task 会被重启，而他们的状态会被重置到最近一次成功的 checkpoint。Kafka source 分别从 offset 2 和 1 重新开始读取消息（因为这是完成的 checkpoint 中存的 offset）。当作业重启后，我们可以期待正常的系统操作，就好像之前没有发生故障一样。如下图所示：

image.png

3、Storm 和 Spark Streaming

Storm 提供了 At-Most-Once、At-Least-Once 和 Exactly Once 这三种不同层次的消息保证机制。其中，Exactly-Once 语义的实现方式是，在 At-Least-Once的基础上进行去重，通过存储历史状态，防止重复发送的数据被重复处理。具体实现可参考《Storm的消息保证机制》。

Spark Streaming 的 Exactly-Once 语义的实现方式是 checkpoint + WAL。具体实现与 Flink 是非常类似的，区别就在于 Spark Streaming 本质上是将流处理当成特殊的批处理（也就是微批 micro-batch ），因此会同时处理多条（一批）记录，保证对每一批的处理要么全部成功，要么全部失败。这就导致在得到结果前， 必须等待一批记录处理结束。这也就是 Spark Streaming 的延迟无法做到毫秒级别的原因。

4、Exactly-Once 讨论

需要注意的是，Flink 中的 Exactly-Once 并非是非常严格的执行一次。例如处理用户的 UDF 时，如果出现失败则可能处理多次。实时上，Flink 所谓的 Exactly-Once 的真正含义是，保证引擎管理的状态更新只提交一次到“****持久的状态存储****”。这里的“持久的状态存储”用于保存全局一致状态检查点（每个算子的状态检查点） 。换句话说，事件的处理可能会进行多次，最新的状态快照后面的 sink 操作也可能执行多次，但处理的效果只会在“持久的状态存储”中体现一次，因此可以认为“有效一次（Effectively-once）”术语可以更精确地描述这样的处理语义。

正是因为如此，最终数据库可能会重复写入数据。而要保证输出操作是幂等的，这就不是流处理引擎要解决的问题了，而是应用程序自己来保证。

关于 Exactly-Once 的更多讨论可见 《Exactly once 未必严格一次》