flink的checkpoint机制提供了容错能力。那它是怎么实现的呢？
看了《Flink原理、实战预性能优化》，加上两篇文章，大致理清了思路
两篇文章链接：
https://www.jianshu.com/p/9993f514ea0a
https://www.jianshu.com/p/a40a1b92f6a2
checkpoint是怎么做的？
数据流中会定时产生一个barrier，当某个算子接收到这个barrier之后就会开始考虑是否要进行checkpoint。
ok，这里有几个问题（1）barrier是怎么产生的（2）为什么是定时产生，怎么设定的这个定时？（3）为什么算子接收到barrier时开始考虑checkpoint，而不是直接执行checkpoint？下面我们一一解答这几个问题。
（1）barrier是在source task中产生的。
（2）我们启用checkpoint的时候，代码是像下面这样写的。
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// 每隔1000 ms进行启动一个检查点【设置checkpoint的周期】
env.enableCheckpointing(1000);
// 高级选项：
// 设置模式为exactly-once （这是默认值）
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
// 确保检查点之间有至少500 ms的间隔【checkpoint最小间隔】
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
// 检查点必须在一分钟内完成，或者被丢弃【checkpoint的超时时间】
env.getCheckpointConfig().setCheckpointTimeout(60000);
// 同一时间只允许进行一个检查点
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
// 表示一旦Flink处理程序被cancel后，会保留Checkpoint数据，以便根据实际需要恢复到指定的Checkpoint【详细解释见备注】
env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION:表示一旦Flink处理程序被cancel后，会保留Checkpoint数据，以便根据实际需要恢复到指定的Checkpoint
ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION: 表示一旦Flink处理程序被cancel后，会删除Checkpoint数据，只有job执行失败的时候才会保存checkpoint
重点看前两行就好，后面的是一些其他功能，放在这里备忘的。
可以发现，第二行代码里设置了每隔1000ms进行一次checkpoint 。这个功能启动之后，JobMaster会定期触发source task生成barrier。
（3）如果一个算子上游只有一个数据来源，那么它不需要考虑，闭着眼checkpoint就好了（我猜的，可能也可以等吧，但也没啥用）；但是如果一个算子上游有多个数据来源，其中一个来源的barrier到了之后，它就面临选择了，是要等剩下几个数据来源的barrier都到齐了再checkpoint呢，还是现在就直接checkpoint呢？
这个就牵扯到了At-Most-Once、At-Least-Once 和 Exactly-Once。
当不采用checkpoint时，每个event做多就只会被处理一次，这就是At-Most-Once。
当不开启Barrier对齐时，也就是一个源的barrier到达之后就开始checkpoint，并开始处理数据了。然后出现了故障，在这个checkpoint恢复的时候，会导致数据重复处理，也就是At-Least-Once
当开启Barrier对齐时，就是Exactly-Once啦。