一.簡述
Flink本身為了保證其高可用的特性，以及保證作用的Exactly Once的快速恢復，進而提供了一套強大的checkpoint機制。但是在實際應用中由于對checkpoint的使用不當會帶來不恰當的影響：比如兩次checkpoint的間隔太短，導致應用一直處于checkpoint的狀態下，甚至會導致整個應用變得不可用。接下來會討論下checkpoint相關內容以及優化參數參考
二.checkpoint是否合理參考參數
對checkpoint進行優化，我們需要參考對應的metrics：
- Checkpoint間隔時間：
比對前后兩次checkpoint的開始時間，是否存在間隔？有則代表當前checkpoint設置時間比較合理。 -
數據Buffered大小：
關于buffered主要是為了flink處理過程會存在一些慢數據流的stream barriers而設計的，通過該參數可以參考當前flink處理流慢數據的比例
checkpoint參數
接下來看看如何合理設置相關的內容
2.1 Checkpoint間隔時間
在實際應用情況下，面對超大數據集規模，每次checkpoint的時間都超過我們設定的或系統的時間，結果會如何？
那就是應用會一直處于checkpoint，甚至導致整個應用都變得不可用了。面對該情況我們提供的方案比如：
1.設置并行checkpoint數 ？？？
2.增量checkpoint：每次只checkpoint出對前一次checkpoint內的狀態數據的增量改動。然后恢復的時候做狀態改動的重放？？？
這里我們來說下第三種方案：強制設置兩次checkpoint的空閑間隔
通過flink提供的config參數來控制,通過該方法我們就可以控制前后checkpoint的間隔不會導致應用一直處于checkpoint。
getCheckpointConfig().setMinPauseBetweenCheckpoints(milliseconds)
該參數并未沒有徹底解決大規模狀態集下checkpoint慢的問題，只是降低慢帶來的風險和影響，接下來看看如果解決大規模數據集下的“慢”問題本質方案
2.2 外部state的存儲
一般來說checkpoint之所以慢 還是因為數據規模大，那如果我們能找到一種更快的存儲狀態的介質（或者策略），來使得這個過程變快。比如可以選擇更加高效的外部存儲介質來做State的存儲（比如RocksDB），而不僅限于存儲于有限的內存空間里，甚至完全落地到磁盤上。
2.2.1 資源設置
由于checkpoint是在每個task上先做數據checkpoint，然后在外部存儲中做checkpoint持久化。在總狀態數據相對固定的情況下，若是減少每個task平均所checkpoint的數據，那么相應地checkpoint的總時間也會變短。所以為每個task設置更多的并行度來加速checkpoint的執行過程。
例如2000W的數據設定100個parallelism，平均=2000W/100；若是將parallelism增大變成200，則平均=2000W/200，相對每份需要處理的數據比較小些，處理的時長就會變少
2.2.2 task恢復
由于checkpoint是分散在每個task上執行，再做匯總持久化。這些task做的checkpoint數據在后面應用恢復時包括并行度擴增或減少時能夠重新打散分布。
那么每個task會為了支持快速恢復，會同時寫checkpoint數據到本地磁盤和遠程分布式存儲，只要task本地的checkpoint數據沒有被破壞，系統在應用恢復時會優先加載本地的checkpoint數據，這樣就大大減少了遠程拉取狀態數據的過程。
2.2.3 常見的配置參數
// checkpoint周期
env.enableCheckpointing(1000);
// checkpoint mode
env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
?
// checkpoint執行有效期：要么1min完成 要么1min放棄
env.getCheckpointConfig().setCheckpointTimeout(60000);
?
// 確保checkpoint時間空閑間隔500ms
env.getCheckpointConfig().setMinPauseBetweenCheckpoints(500);
?
// 允許同一時間只存在一個checkpoint
env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);
?
// job cancellation啟用保留的外部檢查點
env.getCheckpointConfig().enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);
?
// This determines if a task will be failed if an error occurs in the execution of the task’s checkpoint procedure.
env.getCheckpointConfig().setFailOnCheckpointingErrors(true);
使用enableCheckpointing方法來設置開啟checkpoint；
可以使用enableCheckpointing(long interval)或enableCheckpointing(long interval, CheckpointingMode mode)：
interval用于指定checkpoint的觸發間隔(單位milliseconds)；CheckpointingMode默認是CheckpointingMode.EXACTLY_ONCE，也可以指定為CheckpointingMode.AT_LEAST_ONCE或者getCheckpointConfig().setCheckpointingMode來設置CheckpointingMode，一般對于超低延遲的應用(大概幾毫秒)可以使用CheckpointingMode.AT_LEAST_ONCE，其他大部分應用使用CheckpointingMode.EXACTLY_ONCE就可以
checkpointTimeout用于指定checkpoint執行的超時時間(單位milliseconds)，超時沒完成就會被abort掉
minPauseBetweenCheckpoints用于指定checkpoint coordinator上一個checkpoint完成之后最小等多久可以出發另一個checkpoint，當指定這個參數時，maxConcurrentCheckpoints的值為1
maxConcurrentCheckpoints用于指定運行中的checkpoint最多可以有多少個，用于包裝topology不會花太多的時間在checkpoints上面；如果有設置了minPauseBetweenCheckpoints，則maxConcurrentCheckpoints這個參數就不起作用了(大于1的值不起作用)
enableExternalizedCheckpoints用于開啟checkpoint的外部持久化，但是在job失敗的時候不會自動清理，需要自己手工清理state；ExternalizedCheckpointCleanup用于指定當job canceled的時候externalized checkpoint該如何清理，DELETE_ON_CANCELLATION的話，在job canceled的時候會自動刪除externalized state，但是如果是FAILED的狀態則會保留；RETAIN_ON_CANCELLATION則在job canceled的時候會保留externalized checkpoint state
failOnCheckpointingErrors用于指定在checkpoint發生異常的時候，是否應該fail該task，默認為true，如果設置為false，則task會拒絕checkpoint然后繼續運行
