目錄
一致性檢查點（checkpoint）
從檢查點恢復狀態
Flink檢查點算法
保存點（save points）
一致性檢查點（checkpoint）
(1) flink故障恢復機制的核心，就是應用狀態的一致性檢查點
(2) 有狀態流應用的一直檢查點，其實就是所有任務的狀態，在某個時間點的一份拷貝（一份快照）；這個時間點，應該是所有任務都恰好處理完一個相同的輸入數據的時候
從檢查點恢復狀態
（1）在執行流應用期間，Flink會定期保存狀態的一致檢查點
（2）如果發生故障，Flink將會使用最近的檢查點來一致恢復應用程序的狀態，並且重新啓動處理流程
遇到故障之後，第一步就是重啓應用
第二步是從checkpoint中讀取狀態，將狀態重置
從檢查點重新啓動應用程序後，其內部狀態與檢查點完成時的狀態完全相同
第三步：開始消費並處理檢查點到發生故障之間的所有數據
這種檢查點的保存和恢復機制可以爲應用程序狀態提供“精確一次”的一致性，因爲所有算子都會保存檢查點並恢復其所有狀態，這樣所有的輸入流都會被重置到檢查點完成時的位置
檢查點的實現算法
簡單的想法：暫停應用，保存狀態到檢查點，再重新恢復應用
Flink的改進實現：
——基於Chandy-Lamport算法的分佈式快照
——將檢查點的保存和數據處理分離開，不暫停整個應用
Flink檢查點算法
檢查點分界線（Checkpoint Barrier）
（1）Flink的檢查點算法用到了一種稱爲分界線的特殊數據形式，用來把一條流上數據按照不同的檢查點分開
（2）分界線之前到來的數據導致的狀態更改，都會被包含在當前分界線所屬的檢查點中；而基於分界線之後的數據導致的所有更改，就會被包含在之後的檢查點中
現在是一個有兩個輸入流的應用程序，用並行的兩個Source任務來讀取
JobManager會向每個source任務發送一條帶有新檢查點ID的消息，通過這種方式來啓動檢查點
數據源將他們的狀態寫入檢查點，併發出一個檢查點barrier
數據源將他們的狀態寫入檢查點之後，會返回通知給source任務，source任務就會向JobManager確認檢查點完成
分界線對齊：barrier向下遊傳遞，sum任務會等待所有輸入分區的barrier到達
對於barrier已經到達的分區，繼續到達的數據會被緩存
而barrier尚未到達的分區，數據會被正常處理
當收到所有輸入分區的barrier時，任務就將其狀態保存到狀態後端的檢查點中，然後將barrier繼續向下遊轉發
向下遊轉發檢查點barrier後，任務繼續正常的數據處理
Sink任務向JobManager確認狀態保存到checkpoint完畢
當所有任務都確認已成功將狀態保存到檢查點時，檢查點就真正完成了
保存點（save points）
（1）Flink還提供了可以自定義的鏡像保存功能，就是保存點（savepoints）
（2）原則上，創建保存點使用的算法與檢查點完全相同，因此保存點可以認爲就是具有一些額外元數據的檢查點
（3）Flink不會自動創建保存點，因此用戶必須明確地觸發創建操作
（4）保存點是一個強大的功能。除了故障恢復外，保存點可以用於：有計劃的手動備份，更新應用程序，版本遷移，暫停和重啓應用，等等