系列文章目錄
Flink/Blink 原理漫談（一）時間，watermark詳解
Flink/Blink 原理漫談（二）流表對偶性和distinct詳解
Flink/Blink 原理漫談（三）state 有狀態計算機制 詳解
Flink/Blink 原理漫談（五）流式計算的持續查詢實現 詳解
Flink/Blink 原理漫談（六）容錯機制（fault tolerance）詳解
Flink 容錯機制
Flink 檢查點的核心作用是確保狀態正確，即使遇到程序中斷，也要正確。流計算Fault Tolerance的一個很大的挑戰是低延遲，很多Blink任務都是7 x 24小時不間斷，端到端的秒級延遲，要想在遇上網絡閃斷，機器壞掉等非預期的問題時候快速恢復正常，並且不影響計算結果正確性是一件極其困難的事情。在Blink中以checkpointing的機制進行容錯，checkpointing會產生類似binlog一樣的可以用來恢復的任務狀態數據。花費的成本有低到高，如下：
• at-least-once
• exactly-once
檢查點checkpoint
檢查點像普通數據記錄一樣在算子之間流動。檢查點分割線和普通數據記錄類似。它們由算子處理，但並不參與計算，而是會觸發與檢查點相關的行爲。
Checkpoint是故障修復機制的核心，是在某個時間點的一份拷貝。這個時間點是所有任務都恰好處理完一個相同的輸入數據的時候。
從checkpoint恢復狀態的步驟：
全局狀態一致性的問題：
因爲是流式計算，所以如何保證恢復的時候的全局一致性是一個棘手的問題。checkpoint使用的是分佈式快照的方法，這種方法舉例來說就是全學校的人需要拍一張畢業照，但是flink任務場景下，每個結點處理任務都是進度不同的，所以很難將全學校的人都在畢業的這一時刻叫到一起，拍一張照片；所以，我們就讓學校中每一個同學各自拍一張自己畢業時候的照片，然後p圖拼接在一起，這樣就實現了在畢業的這一時刻得到一張全學校同學的畢業照。
Checkpoint的實現過程
Chekpoint用的就是這種分佈式快照的方式，首先，JobManager向每個source任務發送一條帶有檢查點id的信息，啓動檢查點，source將他們的狀態寫入檢查點，併發出一個檢查點barrier，這個barrier信息就和正常的流式數據一樣流動，當某個分區收到barrier信息之後，就會將當前狀態保存到後端檢查點中，接下來向後轉發barrier，這個節點也急需處理數據，這個barrier被傳遞很多次之後，到達了最後的sink任務，sink也將狀態保存，這時候所有的分區都已經將自己的狀態發入檢查點後端，一個checkpoint就完成了。
有些核心的點：
• barrier 由source節點發出；
• barrier會將流上event切分到不同的checkpoint中；
• barrier對齊之後會進行Checkpointing，生成snapshot；
• 完成snapshot之後向下遊發出barrier，繼續直到Sink節點；
這裏引申出一個問題，這解決的是exactly-once還是at-least-once呢？這是分情況的，首先，爲了滿足exactly-once，我們使用的是BarrierBuffer，匯聚到當前節點的多流的barrier要對齊，Barrier提前到達，再有新的數據來，會被緩存；barrier尚未到達，數據被正常處理。如果是爲了滿足at-least-once，要使用的是BarrierTracker：BarrierTracker會對各個輸入接收到的檢查點的barrier進行跟蹤。一旦它觀察到某個檢查點的所有barrier都已經到達，它將會通知監聽器檢查點已完成。
Incremental checkpoint
對於一個流計算的任務，數據會源源不斷的流入，比如要進行雙流join(Blink 漫談系列 - Join 篇會詳細介紹)，由於兩邊的流event的到來有先後順序問題，我們必須將left和right的數據都會在state中進行存儲，Left event流入會在Right的State進行join數據，Right event流入會在LState中join數據。
由於流上數據源源不斷，隨着時間的增加，每次checkpoint產生的snapshot的文件（RocksDB的sst文件）會變的非常龐大，增加網絡IO，拉長checkpoint時間，最終導無法完成checkpoint，Blink失去failover的能力。爲了解決checkpoint不斷變大的問題，Blink內部實現了Incremental checkpoint，這種增量進行checkpoint的機制，會大大減少checkpoint時間，並且如果業務數據穩定的情況下每次checkpoint的時間是相對穩定的，根據不同的業務需求設定checkpoint的interval，穩定快速的進行checkpointing，保障Blink任務在遇到故障時候可以順利的進行failover。Incremental checkpoint的優化對於Blink成百上千的任務節點帶來的利好不言而喻。
另外，爲了實現端到端的一致性，我們仍然需要另外的一些機制，具體在state章節有詳細的介紹。