flink中checkpoint机制总结

CheckPoint 执行过程：

• JobManager 端的 CheckPointCoordinator 向所有 SourceTask 发送 CheckPointTrigger，Source Task 会在数据流中安插 CheckPoint barrier。
• 当 task 收到所有的 barrier 后，向自己的下游继续传递 barrier，然后自身执行快照，并将自己的状态异步写入到持久化存储中。

增量 CheckPoint 只是把最新的一部分更新写入到 外部存储;
为了下游尽快做 CheckPoint，所以会先发送 barrier 到下游，自身再异步进行快照;

• 当 task 完成备份后，会将备份数据的地址（state handle）通知给 JobManager 的 CheckPointCoordinator。

如果 CheckPoint 的持续时长超过了 CheckPoint 设定的超时时间，CheckPointCoordinator 还没有收集完所有的 State Handle，CheckPointCoordinator 就会认为本次 CheckPoint 失败，会把这次 CheckPoint 产生的所有状态数据全部删除。

• 最后 CheckPointCoordinator 会把整个 StateHandle 封装成 completed CheckPoint Meta，写入到 hdfs。

flink中检查点根据是否在barrier对齐做checkpoint
分对齐检查点和非对齐检查点（flink1.11版本引入），区别如下：

1. 对齐检查点在最后一个屏障到达算子时触发，非对齐检查点在第一个屏障到达算子时就触发。

2. 对齐检查点在第一个屏障到最后一个屏障到达的区间内是阻塞的，而非对齐检查点不需要阻塞。

3. 对齐检查点能够保持快照N~N + 1之间的边界，但非对齐检查点模糊了这个边界。

非对齐检查点的特点:

1. 当任务从非对齐检查点恢复时，除了对齐检查点也会涉及到的Source端重放和算子的计算状态恢复之外，未对齐的流数据也会被恢复到各个链路，三者合并起来来保证exactly once的完整现场

2. 需要额外的恢复数据流现场，总的状态大小可能会有比较明显的膨胀，磁盘压力大；从状态恢复时也需要额外恢复数据流的现场，作业重新拉起的耗时可能会很长，容易失败。

flink对齐检查点又根据是否在barrier对齐才下发数据来支持 Exactly Once（对齐下发） 和 At Least Once（非对齐下发），而非对齐检查点只支持 Exactly Once。

总结：

• 非对齐检查点：官方推荐将它应用于那些容易产生反压且I/O压力较小的场景
• 对齐检查点的At Least Once方式： 应用于可以容忍重复数据或者在业务逻辑保证幂等性的场景，且能有效的减少反压
• 对齐检查点的Exactly Once方式：除以上场景，绝大多数的业务适用此场景

参考：
全面讲解Flink中CheckPoint机制和Exactly Once / At Least Once应用
Flink新特性之非对齐检查点（unaligned checkpoint）简介