Checkpoint是Flink实现容错机制最核心的功能，它能够根据配置周期性地基于Stream中各个Operator的状态来生成Snapshot，从而将这些状态数据定期持久化存储下来，当Flink程序一旦意外崩溃时，重新运行程序时可以有选择地从这些Snapshot进行恢复，从而修正因为故障带来的程序数据状态中断
Flink本身为了保证其高可用的特性，以及保证作用的Exactly Once的快速恢复，进而提供了一套强大的Checkpoint机制。
Checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因(如异常退出)出现故障时，能够将整个应用流图的状态恢复到故障之前的某一状态，保 证应用流图状态的一致性。Flink的Checkpoint机制原理来自“Chandy-Lamport algorithm”算法 (分布式快照算法)。
参考：checkpoint
checkpoint执行流程.png
- CheckpointCoordinator周期性的向该流应用的所有source算子发送barrier；
- 当某个source算子收到一个barrier时，便暂停数据处理过程，然后将自己的当前状 态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告 自己快照制作情况，同时向自身所有下游算子广播该barrier，恢复数据处理；
- 下游算子收到barrier之后，会暂停自己的数据处理过程，然后将自身的相关状态制作成快照，并保存到指定的持久化存储中，最后向CheckpointCoordinator报告自身 快照情况，同时向自身所有下游算子广播该barrier，恢复数据处理；
- 每个算子按照步骤3不断制作快照并向下游广播，直到最后barrier传递到sink算子，快照制作完成。
- 当CheckpointCoordinator收到所有算子的报告之后，认为该周期的快照制作成功; 否则，如果在规定的时间内没有收到所有算子的报告，则认为本周期快照制作失败 ;
开始checkpoint的前提是需要barrier对齐
关于barrier对齐,Barrier处理流程：
StreamTask收集到相应的inputChannel的barrier，收集齐之后就将barrier下发，并开始自己task的checkpoint逻辑，如果上下游是rescale或者 forward的形式，下游只需要等待1个并发的barrier，因为是point-to-point的，如果是hash或者rebalance，下游的每一个task开始checkpoint的 前提就是要收集齐上游所有并发的barrier。
结论：
barrier下游无法对齐的主要原因还是在于下游消费能力不足，会导致buffer堆积一段时间，但这时并不足以造成上游反压，因为反压 需要下游channel持续无法写入，导致tcp阻塞，导致上游的outputbuffer占满才会引起反压。
因为数据倾斜导致了问题barrier未对齐的问题，追根溯源还是下游消费能力不足的问题
参考：
Apache Flink** 管理大型状态之增量 Checkpoint 详解：
Flink Checkpoint**超时问题常见排查思路：
网友评论