Flink Checkpoint 机制：如何保证 barrier 和数据之间不乱序？

本文链接：https://blog.csdn.net/sinat_42483341/article/details/122385711

本文深入探讨了Flink的Checkpoint机制，解释了为何需要Checkpoint以实现容错和快速恢复。通过异步障碍快照（ABS）机制，Flink能够在分布式环境中保证状态的一致性。尽管数据在传输过程中可能存在乱序，但通过FIFO数据通道假设和alignment机制，能够确保barrier正确划分数据流，从而不影响Checkpoint的准确性。文章还讨论了数据乱序的原因以及如何在业务中解决乱序问题，强调了timestamp在保证因果关系中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Flink Checkpoint 机制：如何保证 barrier 和数据之间不乱序？

1 前言

1.1 什么是 state？

要说 checkpoint，首先要从 state 聊起。之前有被问到对于 Flink state 的理解，state 的字面含义就是状态。所谓状态，它本身不难理解，简单的说，state 就是你在处理事件的时候需要保存的状态信息。

举个例子，如果你要计时，就要保存开始时间，然后用结束时间减去开始时间，这里的“开始时间”就是先前的状态。

Flink 官方对 state 也有准确的解释：

State in Streaming Applications

Simply put, state is the information that you need to remember across events. Even the most trivial streaming applications are typically stateful because of their need to “remember” the exact position they are processing data from, for example in the form of a Kafka Partition Offset or a File Offset. In addition, many applications hold state internally as a way to support their internal operations, such as windows, aggregations, joins, or state machines.

1.2 为什么要有 checkpoint？

理解了 state 之后，checkpoint 是什么呢？

Flink 作为一个运行在成百上千台机器上的分布式计算引擎，当初被设计的初衷，就是人们想办法利用一大票便宜的PC机，通过一顿猛如虎的数学操作，来自己构建一个宏观上更强性能、更高计算能力的计算机，去替换掉昂贵的小型机、大型机。

正如众多分布式系统的共同点那样，组件失效 / 机器故障应该被视为常态，而不是意外事件。成百上千的廉价机器构成的节点相互访问、交换数据，无论从数量还是质量上，都很难保证时刻的正常运转，所以需要一种机制，让它们可以自动从失败状态恢复过来。因此，持续备份，容错，以及自动恢复这些特性，必须集成到这个计算引擎当中。

实际上，早在 MapReduce 模型被提出的时候，就已经设计了它自己的容错机制，后来随着数据特点的变化（批/流），以及理论和技术的不断发展，到了 Flink 时期，它在现有容错机制的基础上进行改进