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顯示了此時的應用程式。