flink的checkpoint 采用了 Chandy-Lamport 机制，分布式快照
开启checkpoint 需要指定checkpoint的周期和checkpoint的模式
在开启checkpoint后，假如指定了 10秒 一次，ck模式为 exactly once (barrier对其模式)
前10秒的数据流过去之后，此时jobmanager向各个subtask进程发送一个ckeckpoint准备请求，且会从source端往数据流中插入一个barrier标记，每个subtask收到这个barrier后要进行状态的备份。
一个subtask的数据如果只来自于上游的一个subtask，此时遇到barrier后直接备份当前状态，并且向jobmanager发送ack响应。如果一个subtask来自上游多个subtask，因为上有subtask的barrier到达有早有晚，上游最早的barrier到达之后，收到其他上游数据后被缓存到内存中，不会进行处理，直到上游最晚的barrier到达后，这个subtask会进行一次状态备份，并且向jobmanager发送ack响应。简单说就是多个上游任务向同一个下游任务传递分界线时，需要在下游任务执行“barrier对齐”操作，也就是需要等到所有并行分区的barrier都到齐，才可以开始状态的保存。
jobmanager 收到所有的ack响应后。才认为本次checkpoint是完整的，然后给各个subtask发送callBack通知，告诉他们这次checkpoint成功，
当最终的sink端收到了callBack响应后，就会进行commit，比如支持事务的jdbcsink.exactlyOnceSink()，在收到callback后才会进行commit
上述流程就是flink中 barrier对齐的checkpoint算法