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啦。