flink

checkpoint

• Barriers

当接收到jobmanager要进行checkpoint的请求时，会在当前source的数据插入一个barrier，随之该barrier往下游走，期间需要进行快照的操作只要碰到barrier，就会触发自身的快照操作，当所有sink确认快照后，就会向checkpoint协调器发送确认该快照完成，当失败重启时，会从最近一次成功保存的快照恢复。

barrier的作用就是为了把数据区分开，CheckPoint过程中有一个同步做快照的环节不能处理barrier之后的数据，为什么呢？
如果做快照的同时，也在处理数据，那么处理的数据可能会修改快照内容，所以先暂停处理数据，把内存中快照保存好后，再处理数据

• align

接收多个输入流的运算符需要继续快照barrier对齐输入流，比如当flink并行度小于kafka的分区时，必定会有一个task从多个partition读取kafka数据，此时就需要进行对齐。https://blog.csdn.net/xianpanjia4616/article/details/86375224

还没对齐时，从这些流入的数据会被放进缓冲区暂时不会处置，在该对齐并且快照之后，会优先处理缓冲区的数据

所以，对齐会增加流式的等待时间，某些系统对失效性要求较高，精确到毫秒级的，这时可以考虑不对齐。可以不对齐吗？可以的，但是不对齐可能会出现数据重复处理，比如前一个快照处理了后面的数据，当从这个快照失败恢复时，会造成后面的数据部分重复处理

• Exactly Once、At Least Once

Exactly Once时必须barrier对齐，如果barrier不对齐就变成了At Least Once

1. flink内部的exactly once，即上面说的

2. End-to-End Exactly-Once语义

flink和外部系统如何做到一次交付呢？比如kafka，已经输入到kafka了，但是没有进行快照，从最近一次快照恢复，必定会重复数据，只输入到kafka一次，这时需要利用kafka producter的事务机制，在0.11才有的

Solution ---- Two phase commit
Flink采用Two phase commit来解决这个问题.
Phase 1: Pre-commit
Flink的JobManager向source注入checkpoint barrier以开启这次snapshot.
barrier从source流向sink.
每个进行snapshot的算子成功snapshot后,都会向JobManager发送ACK.
当sink完成snapshot后, 向JobManager发送ACK的同时向kafka进行pre-commit.
Phase 2:Commit
当JobManager接收到所有算子的ACK后,就会通知所有的算子这次checkpoint已经完成.
Sink接收到这个通知后, 就向kafka进行commit,正式把数据写入到kafka

不同阶段fail over的recovery举措:
(1)     在pre-commit前fail over, 系统恢复到最近的checkponit
(2)     在pre-com