1 Checkpoint的介绍
Checkpoint的官网文档地址：https://nightlies.apache.org/flink/flink-docs-release-1.17/zh/docs/ops/state/checkpoints/
Checkpoint 使 Flink 的状态具有良好的容错性，通过 checkpoint 机制，Flink 可以对作业的状态和计算位置进行恢复。
Flink是一个分布式的流处理引擎，需要保障Flink作业的7*24小时持续稳定运行。
为了保证state容错，Flink提供了处理故障的措施，这种措施称之为checkpoint(一致性检查点)。checkpoint是Flink实现容错的核心功能，主要是周期性地触发checkpoint，将state生成快照持久化到外部存储系统(比如HDFS)。
如果Flink程序出现故障，那么就可以从上一次checkpoint中进行状态、或故障之前某一状态恢复，然后从该状态恢复任务的运行，从而提供容错保障。 在 Flink 中，Checkpoint 机制采用的是 chandy-lamport（分布式快照）算法，通过 Checkpoint 机制，保证了 Flink 程序内部的 Exactly Once 语义。
2 Checkpoint的运行机制
Flink实现检查点一致，是通过barrier实现的。当一个算子接收多于一个输入流时，就需要对这些流进行checkpoint barrier对齐。
可能通过配置、或在程序启动时，启用Checkpoint机制，指定触发运行时间间隔。
Barriers将流里的记录分隔为一段一段的记录集，每一个记录集都对应一个快照。
2.1 JobManager触发Checkpoint
JobManager 根据 Checkpoint 间隔时间，启动 Checkpoint。此时会给每个 Source 发送一个 barrier 消息，消息中的数值表示 Checkpoint 的序号，每次启动新的 Checkpoint 该序号值都会递增。
2.2 Source启动Checkpoint
当Source接收到barrier消息，会将当前的状态（Partition、Offset）保存到 StateBackend，然后向 JobManager 报告Checkpoint 完成。之后Source会将barrier消息广播给下游的每一个 task（Operator）。
2.3 task接收barrier
当task接收到某个上游（如这里的Source1）发送来的barrier，会将该上游barrier之前的数据继续进行处理，而barrier之后发送来的消息不会进行处理，会被缓存起来。
2.4 barrier对齐
如果某个task有多个上游输入，当接收到其中一个 Source 的barrier后，会等待其他 Source 的 barrier 到来。在此期间，接收到 barrier 的 Source 发来的数据不会处理，只会缓存。而未接收到 barrier 的 Source 发来的数据依然会进行处理，直到接收到该Source 发来的 barrier，最终接收到所有流的barrier。这个过程称为 barrier的对齐 。barrier是否对齐决定了程序实现的是 Exactly Once 还是 At Least Once。
2.5 处理缓存数据
当task接收到所有上游发送来的barrier，即可以认为当前task收到了本次 Checkpoint 的所有数据。之后 task 会将 barrier 继续发送给下游，然后处理缓存的数据。
2.6 上报Checkpoint完成
当sink收到barrier后，会向JobManager上报本次Checkpoint完成。至此，本次Checkpoint结束，各阶段的状态均进行了持久化，可以用于后续的故障恢复。
