Flink/Blink 原理漫談(六)容錯機制(fault tolerance)詳解

語言: CN / TW / HK

系列文章目錄

Flink/Blink 原理漫談(零)執行時的元件

Flink/Blink 原理漫談(一)時間,watermark詳解

Flink/Blink 原理漫談(二)流表對偶性和distinct詳解

Flink/Blink 原理漫談(三)state 有狀態計算機制 詳解

Flink/Blink 原理漫談(四)window機制詳解

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章節有詳細的介紹。