Flink可靠性的基石－checkpoint機制詳細解析
兩階段提交協(xié)議（2PC）
兩階段提交協(xié)議（Two－Phase Commit，2PC）是很常用的解決分布式事務問題的方式，它可以保證在分布式事務中，要么所有參與進程都提交事務，要么都取消，即實現 ACID 中的 A （原子性）。
在數據一致性的環(huán)境下，其代表的含義是：要么所有備份數據同時更改某個數值，要么都不改，以此來達到數據的強一致性。
兩階段提交協(xié)議中有兩個重要角色，協(xié)調者（Coordinator）和參與者（Participant），其中協(xié)調者只有一個，起到分布式事務的協(xié)調管理作用，參與者有多個。
顧名思義，兩階段提交將提交過程劃分為連續(xù)的兩個階段：表決階段（Voting）和提交階段（Commit）。
兩階段提交協(xié)議過程如下圖所示：
兩階段提交協(xié)議
第一階段：表決階段
協(xié)調者向所有參與者發(fā)送一個 VOTE＿REQUEST 消息。
當參與者接收到 VOTE＿REQUEST 消息，向協(xié)調者發(fā)送 VOTE＿COMMIT 消息作為回應，告訴協(xié)調者自己已經做好準備提交準備，如果參與者沒有準備好或遇到其他故障，就返回一個 VOTE＿ABORT 消息，告訴協(xié)調者目前無法提交事務。
第二階段：提交階段
協(xié)調者收集來自各個參與者的表決消息。如果所有參與者一致認為可以提交事務，那么協(xié)調者決定事務的最終提交，在此情形下協(xié)調者向所有參與者發(fā)送一個 GLOBAL＿COMMIT 消息，通知參與者進行本地提交；如果所有參與者中有任意一個返回消息是 VOTE＿ABORT，協(xié)調者就會取消事務，向所有參與者廣播一條 GLOBAL＿ABORT 消息通知所有的參與者取消事務。
每個提交了表決信息的參與者等候協(xié)調者返回消息，如果參與者接收到一個 GLOBAL＿COMMIT 消息，那么參與者提交本地事務，否則如果接收到 GLOBAL＿ABORT 消息，則參與者取消本地事務。
兩階段提交協(xié)議在 Flink 中的應用
Flink 的兩階段提交思路：
我們從 Flink 程序啟動到消費 Kafka 數據，最后到 Flink 將數據 Sink 到 Kafka 為止，來分析 Flink 的精準一次處理。
當 Checkpoint 啟動時，JobManager 會將檢查點分界線（checkpoint battier）注入數據流，checkpoint barrier 會在算子間傳遞下去，如下如所示：
Flink 精準一次處理：Checkpoint 啟動
Source 端：Flink Kafka Source 負責保存 Kafka 消費 offset，當 Chckpoint 成功時 Flink 負責提交這些寫入，否則就終止取消掉它們，當 Chckpoint 完成位移保存，它會將 checkpoint barrier（檢查點分界線） 傳給下一個 Operator，然后每個算子會對當前的狀態(tài)做個快照，保存到狀態(tài)后端（State Backend）。
對于 Source 任務而言，就會把當前的 offset 作為狀態(tài)保存起來。下次從 Checkpoint 恢復時，Source 任務可以重新提交偏移量，從上次保存的位置開始重新消費數據，如下圖所示：
Flink 精準一次處理：checkpoint barrier 及 offset 保存Slink 端：從 Source 端開始，每個內部的 transform 任務遇到 checkpoint barrier（檢查點分界線）時，都會把狀態(tài)存到 Checkpoint 里。數據處理完畢到 Sink 端時，Sink 任務首先把數據寫入外部 Kafka，這些數據都屬于預提交的事務（還不能被消費），此時的 Pre－commit 預提交階段下 Data Sink 在保存狀態(tài)到狀態(tài)后端的同時還必須預提交它的外部事務，如下圖所示：
Flink 精準一次處理：預提交到外部系統(tǒng)
當所有算子任務的快照完成（所有創(chuàng)建的快照都被視為是 Checkpoint 的一部分），也就是這次的 Checkpoint 完成時，JobManager 會向所有任務發(fā)通知，確認這次 Checkpoint 完成，此時 Pre－commit 預提交階段才算完成。才正式到兩階段提交協(xié)議的第二個階段：commit 階段。該階段中 JobManager 會為應用中每個 Operator 發(fā)起 Checkpoint 已完成的回調邏輯。
本例中的 Data Source 和窗口操作無外部狀態(tài)，因此在該階段，這兩個 Opeartor 無需執(zhí)行任何邏輯，但是 Data Sink 是有外部狀態(tài)的，此時我們必須提交外部事務，當 Sink 任務收到確認通知，就會正式提交之前的事務，Kafka 中未確認的數據就改為“已確認”，數據就真正可以被消費了，如下圖所示：
Flink 精準一次處理：數據精準被消費
注：Flink 由 JobManager 協(xié)調各個 TaskManager 進行 Checkpoint 存儲，Checkpoint 保存在 StateBackend（狀態(tài)后端） 中，默認 StateBackend 是內存級的，也可以改為文件級的進行持久化保存。
最后，一張圖總結下 Flink 的 EOS：
Flink 端到端精準一次處理
此圖建議保存，總結全面且簡明扼要，再也不慫面試官！
分享
請輸入評論內容...
請輸入評論/評論長度6~500個字
