Flink的恢復機制，基於它的一致性檢查點。前面我們已經了解了從流應用中創建檢查點的簡單方法——先暫停應用，保存檢查點，然后再恢復應用程序，這種方法很好理解，但它的理念是“停止一切”，這對於即使是中等延遲要求的應用程序而言也是不實用的。所以Flink沒有這么簡單粗暴，而是基於Chandy-Lamport算法實現了分布式快照的檢查點保存。該算法並不會暫停整個應用程序，而是將檢查點的保存與數據處理分離，這樣就可以實現在其它任務做檢查點狀態保存狀態時，讓某些任務繼續進行而不受影響。接下來我們將解釋此算法的工作原理。
Flink的檢查點算法用到了一種稱為“檢查點分界線”（checkpoint barrier）的特殊數據形式。與水位線（watermark）類似，檢查點分界線由source算子注入到常規的數據流中，它的位置是限定好的，不能超過其他數據，也不能被后面的數據超過。檢查點分界線帶有檢查點ID，用來標識它所屬的檢查點；這樣，這個分界線就將一條流邏輯上分成了兩部分。分界線之前到來的數據導致的狀態更改，都會被包含在當前分界線所屬的檢查點中；而基於分界線之后的數據導致的所有更改，就會被包含在之后的檢查點中。
我們用一個簡單的流應用程序作為示例，來一步一步解釋這個算法。該應用程序有兩個源（source）任務，每個任務都消費一個增長的數字流。源任務的輸出被划分為兩部分：偶數和奇數的流。每個分區由一個任務處理，該任務計算所有收到的數字的總和，並將更新的總和轉發給輸出（sink）任務。這個應用程序的結構如圖3-19所示。
作業管理器會向每個數據源（source）任務發送一條帶有新檢查點ID的消息，通過這種方式來啟動檢查點，如圖3-20所示。
當source任務收到消息時，它會暫停發出新的數據，在狀態后端觸發本地狀態的檢查點保存，並向所有傳出的流分區廣播帶着檢查點ID的分界線（barriers）。狀態后端在狀態檢查點完成后會通知任務，而任務會向作業管理器確認檢查點完成。在發出所有分界線后，source任務就可以繼續常規操作，發出新的數據了。通過將分界線注入到輸出流中，源函數（source function）定義了檢查點在流中所處的位置。圖3-21顯示了兩個源任務將本地狀態保存到檢查點，並發出檢查點分界線之后的流應用程序。
源任務發出的檢查點分界線（barrier），將被傳遞給所連接的任務。與水位線（watermark）類似，barrier會被廣播到所有連接的並行任務，以確保每個任務從它的每個輸入流中都能接收到。當任務收到一個新檢查點的barrier時，它會等待這個檢查點的所有輸入分區的barrier到達。在等待的過程中，任務並不會閑着，而是會繼續處理尚未提供barrier的流分區中的數據。對於那些barrier已經到達的分區，如果繼續有新的數據到達，它們就不會被立即處理，而是先緩存起來。這個等待所有分界線到達的過程，稱為“分界線對齊”（barrier alignment），如圖3-22所示。
當任務從所有輸入分區都收到barrier時，它就會在狀態后端啟動一個檢查點的保存，並繼續向所有下游連接的任務廣播檢查點分界線，如圖3-23所示。
所有的檢查點barrier都發出后，任務就開始處理之前緩沖的數據。在處理並發出所有緩沖數據之后，任務就可以繼續正常處理輸入流了。圖3-24顯示了此時的應用程序。
最終，檢查點分界線會到達輸出（sink）任務。當sink任務接收到barrier時，它也會先執行“分界線對齊”，然后將自己的狀態保存到檢查點，並向作業管理器確認已接收到barrier。一旦從應用程序的所有任務收到一個檢查點的確認信息，作業管理器就會將這個檢查點記錄為已完成。圖3-25顯示了檢查點算法的最后一步。這樣，當發生故障時，我們就可以用已完成的檢查點恢復應用程序了。
