本文將對checkpoint的執行流程逐步拆解進行分析:
checkpointcoordinator:整個checkpoint的發起者,由jobmanger管理著
source:資料來源
sink:資料sink
map:運算元
hdfs:checkpoint儲存地
如下圖:
第二步:每個source節點向下游所有task廣播barrier,這個barrier是流中的一種特殊資料,
實現了chandy-lamport分布式快照演算法核心,當下游所有task接收到所有input的barrier才會執行checkpoint,對於在barrier後面的來到的資料,但是還有沒有做完checkpoint的資料,會先快取在記憶體中,對於barrier之前的資料,會等計算完了,才做對應checkpoint.
如下圖:
第三步:當所有task完成state備份以後,會將備份的資料位址(state handle)通知給checkpoint coordinator.
第四步:下游的sink節點收集齊上游所有的source輸出的barrier之後,會進行本地快照,這裡特地展示了 rocksdb incremental checkpoint 的流程，首先 rocksdb 會全量刷資料到磁碟上（紅色大三角表示），然後 flink 框架會從中選擇沒有上傳的檔案進行持久化備份（紫色小三角）。
第五步:sink節點在完成自己的checkpoint之後,會將state handle返回通知 coordinator.
第六步:當checkpoint coordinator收集器所有的task的state handle,就會認為這一次的check point全域性完成了,向持久化儲存再備份乙個checkpoint meta檔案.
對於事務寫入,兩種實現方式:預寫日誌和兩階段提交為了實現exactly_once語義,flink通過barrier將對齊階段收到的資料快取起來,等對齊之後再完成之後的處理,對於at least once語義,無需快取收集到的資料,對後續直接處理,所以導致重啟時,資料可能會被多次處理,導致資料的重複
flink的checkpoint機制只能保證flink的計算過程可以做到exactly_once,但是端到端的exactly once需要source和sink的支援,而且取決於source sink中最弱的一端
如果想要端到端的exactly_once
flink內部:checkpoint機制
source:可以重置資料的讀取位置
sink:需要保證從故障恢復是,資料不會重複寫入
sink有兩種具體的實現方式:
1.冪等性
所謂冪等操作，是說乙個操作，可以重複執行很多次，但只導致一次結果更改，也就是說，後面再重複執行就不起作用了。
2.事務寫入
需要構建事務來寫入外部系統，構建的事務對應著 checkpoint，等到 checkpoint 真正完成的時候，才把所有對應的結果寫入 sink 系統中。
對於事務寫入,兩種實現方式:預寫日誌和兩階段提交
內部:flink的checkpoint
source:kafka source,可以設定重置偏移量
sink:kakfa sink 實現了兩階段提交
具體步驟:
我們知道flink由jobmanager管理各個taskmanager進行checkpoint的.
1.jobmanager會啟動checkpoint coordinator,向所有的source 觸發checkpoint
2.所有source會向所有的task廣播barrier,barrier會在運算元間傳遞下去
3.當每個運算元對當前狀態都做了快照,儲存在轉台後端了,source就會把當前offset作為狀態儲存起來,下次checkpoint恢復是,重新提交偏移量,從上次儲存的位置開始重寫消費資料
4.每個運算元遇到barrier時,都會把狀態存到checkpoint中
5.sink任務當第一條資料來到時,會開啟乙個事務,把資料寫入kafka中,此時是預提交,資料不能被消費,當遇到 barrier 時，把狀態儲存到狀態後端，並開啟新的預提交事務。
當所有運算元任務的快照完成，也就是這次的 checkpoint 完成時，jobmanager 會向所有任務發通知，確認這次 checkpoint 完成。
當sink 任務收到確認通知，就會正式提交之前的事務，kafka 中未確認的資料就改為「已確認」，資料就真正可以被消費了。
執行過程實際上是乙個兩段式提交，每個運算元執行完成，會進行「預提交」，直到執行完sink操作，會發起「確認提交」，如果執行失敗，預提交會放棄掉。
具體總結:
1.當第一條資料來了之後,開啟乙個kafka事務,正常寫入kafka的分割槽中,但是此時資料被標記為預提交,不能被消費
2.jobmanager觸發了checkpoint操作,barrier從source向下游傳遞,運算元遇到barrier就會將狀態存入狀態後端,並且會通知jobmanager
3.sink接收到barrier後,儲存當前狀態,儲存checkpoint中,通知jobmanager開啟一階段的事務,用於提交下階段的資料
4.jobmanager接收到所有任務的通知後,發出確認資訊,表示此次checkpoint完成.
5.當sink接收到了jobmanager的確定資訊後,就會正式提交事務.
6.外部kafka就會關閉該階段的事務,資料就可以被消費了
``
session執行機制
session機制是一種伺服器端的機制，伺服器使用一種類似於雜湊表 的結構 也可能就是使用 雜湊表 來儲存資訊。當程式需要為某個客戶端的請求建立乙個session的時候，伺服器首先檢查這個客戶端的請求裡是否已包含了乙個session標識 稱為sessionid，如果已包含乙個sessionid則說明...
try catch finally執行機制
finally的執行 如下的程式所示，注釋中是執行的順序 public class test public static string test finally public static string test1 finally其實是僅在return 語句執行前執行，如果return 乙個函式，那...
runtime執行機制
這篇文章主要介紹的是runtime是什麼以及怎麼用！希望對讀者有所幫助！第乙個問題，1 runtime實現的機制是什麼,怎麼用，一般用於幹嘛？runtime是一套比較底層的純c語言api,屬於1個c語言庫,包含了很多底層的c語言api。在我們平時編寫的oc 中,程式執行過程時,其實最終都是轉成了ru...