Checkpoint介紹
checkpoint機制是Flink可靠性的基石，可以保證Flink集羣在某個算子因爲某些原因(如 異常退出)出現故障時，能夠將整個應用流圖的狀態恢復到故障之前的某一狀態，保 證應用流圖狀態的一致性。Flink的checkpoint機制原理來自“Chandy-Lamport algorithm”算法。
每個需要checkpoint的應用在啓動時，Flink的JobManager爲其創建一個 CheckpointCoordinator(檢查點協調器)，CheckpointCoordinator全權負責本應用的快照製作。
1) CheckpointCoordinator(檢查點協調器) 週期性的向該流應用的所有source算子發送 barrier(屏障)。
2) 當某個source算子收到一個barrier時，便暫停數據處理過程，然後將自己的當前狀態製作成快照，並保存到指定的持久化存儲中，最後向CheckpointCoordinator報告自己快照製作情況，同時向自身所有下游算子廣播該barrier，恢復數據處理
3) 下游算子收到barrier之後，會暫停自己的數據處理過程，然後將自身的相關狀態製作成快照，並保存到指定的持久化存儲中，最後向CheckpointCoordinator報告自身快照情況，同時向自身所有下游算子廣播該barrier，恢復數據處理。
4) 每個算子按照步驟3不斷製作快照並向下遊廣播，直到最後barrier傳遞到sink算子，快照製作完成。
5) 當CheckpointCoordinator收到所有算子的報告之後，認爲該週期的快照製作成功; 否則，如果在規定的時間內沒有收到所有算子的報告，則認爲本週期快照製作失敗。
如果一個算子有兩個輸入源，則暫時阻塞先收到barrier的輸入源，等到第二個輸入源相 同編號的barrier到來時，再製作自身快照並向下遊廣播該barrier。具體如下圖所示：
1) 假設算子C有A和B兩個輸入源
2) 在第i個快照週期中，由於某些原因(如處理時延、網絡時延等)輸入源A發出的 barrier 先到來，這時算子C暫時將輸入源A的輸入通道阻塞，僅收輸入源B的數據。
3) 當輸入源B發出的barrier到來時，算子C製作自身快照並向 CheckpointCoordinator 報告自身的快照製作情況，然後將兩個barrier合併爲一個，向下遊所有的算子廣播。
4) 當由於某些原因出現故障時，CheckpointCoordinator通知流圖上所有算子統一恢復到某個週期的checkpoint狀態，然後恢復數據流處理。分佈式checkpoint機制保證了數據僅被處理一次(Exactly Once)。
持久化存儲
MemStateBackend
該持久化存儲主要將快照數據保存到JobManager的內存中，僅適合作爲測試以及快照的數據量非常小時使用，並不推薦用作大規模商業部署。
MemoryStateBackend 的侷限性：
默認情況下，每個狀態的大小限制爲 5 MB。可以在MemoryStateBackend的構造函數中增加此值。
無論配置的最大狀態大小如何，狀態都不能大於akka幀的大小（請參閱配置）。
聚合狀態必須適合 JobManager 內存。
建議MemoryStateBackend 用於：
本地開發和調試。
狀態很少的作業，例如僅包含一次記錄功能的作業（Map，FlatMap，Filter，…），kafka的消費者需要很少的狀態。
FsStateBackend
該持久化存儲主要將快照數據保存到文件系統中，目前支持的文件系統主要是 HDFS和本地文件。如果使用HDFS，則初始化FsStateBackend時，需要傳入以 “hdfs://”開頭的路徑(即: new FsStateBackend("hdfs:///hacluster/checkpoint"))， 如果使用本地文件，則需要傳入以“file://”開頭的路徑(即:new FsStateBackend("file:///Data"))。在分佈式情況下，不推薦使用本地文件。如果某 個算子在節點A上失敗，在節點B上恢復，使用本地文件時，在B上無法讀取節點 A上的數據，導致狀態恢復失敗。
建議FsStateBackend：
具有大狀態，長窗口，大鍵 / 值狀態的作業。
所有高可用性設置。
RocksDBStateBackend
RocksDBStatBackend介於本地文件和HDFS之間，平時使用RocksDB的功能，將數 據持久化到本地文件中，當製作快照時，將本地數據製作成快照，並持久化到 FsStateBackend中(FsStateBackend不必用戶特別指明，只需在初始化時傳入HDFS 或本地路徑即可，如new RocksDBStateBackend("hdfs:///hacluster/checkpoint")或new RocksDBStateBackend("file:///Data"))。
如果用戶使用自定義窗口(window)，不推薦用戶使用RocksDBStateBackend。在自定義窗口中，狀態以ListState的形式保存在StatBackend中，如果一個key值中有多個value值，則RocksDB讀取該種ListState非常緩慢，影響性能。用戶可以根據應用的具體情況選擇FsStateBackend+HDFS或RocksStateBackend+HDFS。
語法
val env = StreamExecutionEnvironment.getExecutionEnvironment()
// start a checkpoint every 1000 ms
env.enableCheckpointing(1000)
// advanced options:
// 設置checkpoint的執行模式，最多執行一次或者至少執行一次
env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
// 設置checkpoint的超時時間
env.getCheckpointConfig.setCheckpointTimeout(60000)
// 如果在只做快照過程中出現錯誤，是否讓整體任務失敗：true是 false不是
env.getCheckpointConfig.setFailTasksOnCheckpointingErrors(false)
//設置同一時間有多少 個checkpoint可以同時執行
env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)
修改State Backend的兩種方式
第一種：單任務調整
修改當前任務代碼
env.setStateBackend(new FsStateBackend("hdfs://namenode:9000/flink/checkpoints"));
或者new MemoryStateBackend()
或者new RocksDBStateBackend(filebackend, true);【需要添加第三方依賴】
第二種：全局調整
修改flink-conf.yaml
state.backend: filesystem
state.checkpoints.dir: hdfs://namenode:9000/flink/checkpoints
注意：state.backend的值可以是下面幾種：jobmanager(MemoryStateBackend), filesystem(FsStateBackend), rocksdb(RocksDBStateBackend)
Checkpoint的高級選項
默認checkpoint功能是disabled的，想要使用的時候需要先啓用checkpoint開啓之後，默認的checkPointMode是Exactly-once
//配置一秒鐘開啓一個checkpoint
env.enableCheckpointing(1000)
//指定checkpoint的執行模式
//兩種可選：
//CheckpointingMode.EXACTLY_ONCE：默認值
//CheckpointingMode.AT_LEAST_ONCE
env.getCheckpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE)
一般情況下選擇CheckpointingMode.EXACTLY_ONCE，除非場景要求極低的延遲（幾毫秒）
注意：如果需要保證EXACTLY_ONCE，source和sink要求必須同時保證EXACTLY_ONCE
//如果程序被cancle，保留以前做的checkpoint
env.getCheckpointConfig.enableExternalizedCheckpoints(ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION)
默認情況下，檢查點不被保留，僅用於在故障中恢復作業，可以啓用外部持久化檢查點，同時指定保留策略:
ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION:在作業取消時保留檢查點，注意，在這種情況下，您必須在取消後手動清理檢查點狀態
ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION：當作業在被cancel時，刪除檢查點，檢查點僅在作業失敗時可用
//設置checkpoint超時時間
env.getCheckpointConfig.setCheckpointTimeout(60000)
//Checkpointing的超時時間，超時時間內沒有完成則被終止
//Checkpointing最小時間間隔，用於指定上一個checkpoint完成之後
//最小等多久可以觸發另一個checkpoint，當指定這個參數時，maxConcurrentCheckpoints的值爲1
env.getCheckpointConfig.setMinPauseBetweenCheckpoints(500)
//設置同一個時間是否可以有多個checkpoint執行
env.getCheckpointConfig.setMaxConcurrentCheckpoints(1)
指定運行中的checkpoint最多可以有多少個
env.getCheckpointConfig.setFailOnCheckpointingErrors(true)
用於指定在checkpoint發生異常的時候，是否應該fail該task，默認是true，如果設置爲false，則task會拒絕checkpoint然後繼續運行
Flink的重啓策略
Flink支持不同的重啓策略，這些重啓策略控制着job失敗後如何重啓。集羣可以通過默認的重啓策略來重啓，這個默認的重啓策略通常在未指定重啓策略的情況下使用，而如果Job提交的時候指定了重啓策略，這個重啓策略就會覆蓋掉集羣的默認重啓策略。
概覽
默認的重啓策略是通過Flink的 flink-conf.yaml 來指定的，這個配置參數 restart-strategy 定義了哪種策略會被採用。如果checkpoint未啓動，就會採用 no restart 策略，如果啓動了checkpoint機制，但是未指定重啓策略的話，就會採用 fixed-delay 策略，重試 Integer.MAX_VALUE 次。請參考下面的可用重啓策略來了解哪些值是支持的。
每個重啓策略都有自己的參數來控制它的行爲，這些值也可以在配置文件中設置，每個重啓策略的描述都包含着各自的配置值信息。
除了定義一個默認的重啓策略之外，你還可以爲每一個Job指定它自己的重啓策略，這個重啓策略可以在 ExecutionEnvironment 中調用 setRestartStrategy() 方法來程序化地調用，注意這種方式同樣適用於 StreamExecutionEnvironment。
下面的例子展示瞭如何爲Job設置一個固定延遲重啓策略，一旦有失敗，系統就會嘗試每10秒重啓一次，重啓3次。
val env = ExecutionEnvironment.getExecutionEnvironment()
env.setRestartStrategy(RestartStrategies.fixedDelayRestart(
3, // 重啓次數
Time.of(10, TimeUnit.SECONDS) // 延遲時間間隔
))
固定延遲重啓策略(Fixed Delay Restart Strategy)
固定延遲重啓策略會嘗試一個給定的次數來重啓Job，如果超過了最大的重啓次數，Job最終將失敗。在連續的兩次重啓嘗試之間，重啓策略會等待一個固定的時間。
重啓策略可以配置flink-conf.yaml的下面配置參數來啓用，作爲默認的重啓策略:
restart-strategy: fixed-delay
例子:
restart-strategy.fixed-delay.attempts: 3
restart-strategy.fixed-delay.delay: 10 s
固定延遲重啓也可以在程序中設置:
val env = ExecutionEnvironment.getExecutionEnvironment()
env.setRestartStrategy(RestartStrategies.fixedDelayRestart(
3, // 重啓次數
Time.of(10, TimeUnit.SECONDS) // 重啓時間間隔
))
失敗率重啓策略
失敗率重啓策略在Job失敗後會重啓，但是超過失敗率後，Job會最終被認定失敗。在兩個連續的重啓嘗試之間，重啓策略會等待一個固定的時間。
失敗率重啓策略可以在flink-conf.yaml中設置下面的配置參數來啓用:
restart-strategy:failure-rate
例子:
restart-strategy.failure-rate.max-failures-per-interval: 3
restart-strategy.failure-rate.failure-rate-interval: 5 min
restart-strategy.failure-rate.delay: 10 s
失敗率重啓策略也可以在程序中設置:
val env = ExecutionEnvironment.getExecutionEnvironment()
env.setRestartStrategy(RestartStrategies.failureRateRestart(
3, // 每個測量時間間隔最大失敗次數
Time.of(5, TimeUnit.MINUTES), //失敗率測量的時間間隔
Time.of(10, TimeUnit.SECONDS) // 兩次連續重啓嘗試的時間間隔
))
無重啓策略
Job直接失敗，不會嘗試進行重啓
restart-strategy: none
無重啓策略也可以在程序中設置
val env = ExecutionEnvironment.getExecutionEnvironment()
env.setRestartStrategy(RestartStrategies.noRestart())