兩階段提交協(xié)議（2PC）

兩階段提交協(xié)議（Two－Phase Commit，2PC）是很常用的解決分布式事務(wù)問題的方式，它可以保證在分布式事務(wù)中，要么所有參與進程都提交事務(wù)，要么都取消，即實現(xiàn) ACID 中的 A （原子性）。

在數(shù)據(jù)一致性的環(huán)境下，其代表的含義是：要么所有備份數(shù)據(jù)同時更改某個數(shù)值，要么都不改，以此來達到數(shù)據(jù)的強一致性。

兩階段提交協(xié)議中有兩個重要角色，協(xié)調(diào)者（Coordinator）和參與者（Participant），其中協(xié)調(diào)者只有一個，起到分布式事務(wù)的協(xié)調(diào)管理作用，參與者有多個。

顧名思義，兩階段提交將提交過程劃分為連續(xù)的兩個階段：表決階段（Voting）和提交階段（Commit）。

兩階段提交協(xié)議過程如下圖所示：

兩階段提交協(xié)議

第一階段：表決階段

協(xié)調(diào)者向所有參與者發(fā)送一個 VOTE＿REQUEST 消息。

當參與者接收到 VOTE＿REQUEST 消息，向協(xié)調(diào)者發(fā)送 VOTE＿COMMIT 消息作為回應(yīng)，告訴協(xié)調(diào)者自己已經(jīng)做好準備提交準備，如果參與者沒有準備好或遇到其他故障，就返回一個 VOTE＿ABORT 消息，告訴協(xié)調(diào)者目前無法提交事務(wù)。

第二階段：提交階段

協(xié)調(diào)者收集來自各個參與者的表決消息。如果所有參與者一致認為可以提交事務(wù)，那么協(xié)調(diào)者決定事務(wù)的最終提交，在此情形下協(xié)調(diào)者向所有參與者發(fā)送一個 GLOBAL＿COMMIT 消息，通知參與者進行本地提交；如果所有參與者中有任意一個返回消息是 VOTE＿ABORT，協(xié)調(diào)者就會取消事務(wù)，向所有參與者廣播一條 GLOBAL＿ABORT 消息通知所有的參與者取消事務(wù)。

每個提交了表決信息的參與者等候協(xié)調(diào)者返回消息，如果參與者接收到一個 GLOBAL＿COMMIT 消息，那么參與者提交本地事務(wù)，否則如果接收到 GLOBAL＿ABORT 消息，則參與者取消本地事務(wù)。

兩階段提交協(xié)議在 Flink 中的應(yīng)用

Flink 的兩階段提交思路：

我們從 Flink 程序啟動到消費 Kafka 數(shù)據(jù)，最后到 Flink 將數(shù)據(jù) Sink 到 Kafka 為止，來分析 Flink 的精準一次處理。

當 Checkpoint 啟動時，JobManager 會將檢查點分界線（checkpoint battier）注入數(shù)據(jù)流，checkpoint barrier 會在算子間傳遞下去，如下如所示：

Flink 精準一次處理：Checkpoint 啟動

Source 端：Flink Kafka Source 負責保存 Kafka 消費 offset，當 Chckpoint 成功時 Flink 負責提交這些寫入，否則就終止取消掉它們，當 Chckpoint 完成位移保存，它會將 checkpoint barrier（檢查點分界線） 傳給下一個 Operator，然后每個算子會對當前的狀態(tài)做個快照，保存到狀態(tài)后端（State Backend）。

對于 Source 任務(wù)而言，就會把當前的 offset 作為狀態(tài)保存起來。下次從 Checkpoint 恢復時，Source 任務(wù)可以重新提交偏移量，從上次保存的位置開始重新消費數(shù)據(jù)，如下圖所示：

Flink 精準一次處理：checkpoint barrier 及 offset 保存Slink 端：從 Source 端開始，每個內(nèi)部的 transform 任務(wù)遇到 checkpoint barrier（檢查點分界線）時，都會把狀態(tài)存到 Checkpoint 里。數(shù)據(jù)處理完畢到 Sink 端時，Sink 任務(wù)首先把數(shù)據(jù)寫入外部 Kafka，這些數(shù)據(jù)都屬于預提交的事務(wù)（還不能被消費），此時的 Pre－commit 預提交階段下 Data Sink 在保存狀態(tài)到狀態(tài)后端的同時還必須預提交它的外部事務(wù)，如下圖所示：

Flink 精準一次處理：預提交到外部系統(tǒng)

當所有算子任務(wù)的快照完成（所有創(chuàng)建的快照都被視為是 Checkpoint 的一部分），也就是這次的 Checkpoint 完成時，JobManager 會向所有任務(wù)發(fā)通知，確認這次 Checkpoint 完成，此時 Pre－commit 預提交階段才算完成。才正式到兩階段提交協(xié)議的第二個階段：commit 階段。該階段中 JobManager 會為應(yīng)用中每個 Operator 發(fā)起 Checkpoint 已完成的回調(diào)邏輯。

本例中的 Data Source 和窗口操作無外部狀態(tài)，因此在該階段，這兩個 Opeartor 無需執(zhí)行任何邏輯，但是 Data Sink 是有外部狀態(tài)的，此時我們必須提交外部事務(wù)，當 Sink 任務(wù)收到確認通知，就會正式提交之前的事務(wù)，Kafka 中未確認的數(shù)據(jù)就改為“已確認”，數(shù)據(jù)就真正可以被消費了，如下圖所示：

Flink 精準一次處理：數(shù)據(jù)精準被消費

注：Flink 由 JobManager 協(xié)調(diào)各個 TaskManager 進行 Checkpoint 存儲，Checkpoint 保存在 StateBackend（狀態(tài)后端） 中，默認 StateBackend 是內(nèi)存級的，也可以改為文件級的進行持久化保存。

最后，一張圖總結(jié)下 Flink 的 EOS：

Flink 端到端精準一次處理

此圖建議保存，總結(jié)全面且簡明扼要，再也不慫面試官！