分布式事務的 2PC ,3PC 送出

在分布式系統中，當一個事務操作需要跨越多個分布式節點時，為了保持事務的ACID特性，就出現了“協調者(Coordinator)”來統一排程所有分布式節點的執行邏輯，而被排程的分布式節點則被稱為“參與者(Cohort)”。協調者(Coordinator)負責排程參與者(Cohort)的行為，并最終決定這些參與者(Cohort)是否把事務真正進行送出。基于這個思想，衍生出2PC和3PC兩種協定。

一. 2PC (Two-Phase Commit)

2PC(Two-Phase Commit)為二階段送出，為了分布式系統下所有節點操作事務能夠儲存原子性和一緻性而設計的一種算法。主要應用在關系型資料庫來完成分布式事務處理，利用該協定可以友善地利用協調者(Coordinator)進行統一的事務送出和復原，進而能夠有效的保證分布式資料一緻性。

2PC的兩階段

階段一(送出請求階段)

各參與者(Cohort)投票表明是否要繼續執行接下來的事務送出操作：

協調者(Coordinator)節點向所有參與者(Cohort)節點詢問是否可以執行送出操作，并開始等待各參與者(Cohort)節點的響應。
參與者(Cohort)節點執行詢問發起為止的所有事務操作，并将Undo資訊和Redo資訊寫入日志。
各參與者(Cohort)節點響應協調者(Coordinator)節點發起的詢問。如果參與者(Cohort)節點的事務操作實際執行成功，則它傳回一個"同意"消息；如果參與者(Cohort)節點的事務操作實際執行失敗，則它傳回一個"中止"消息。

階段二(送出執行階段)

協調者(Coordinator)會根據參與者(Cohort)的回報情況來決定是否可以進行事務送出操作，可分為事務送出以及事務中斷兩種情況。

事務送出：

當協調者(Coordinator)節點從所有參與者(Cohort)節點獲得的對應的消息都為"Yes"時：

協調者(Coordinator)節點向所有參與者(Cohort)節點發出"Commit"的請求。
參與者(Cohort)節點收到Commit請求後，正式執行事務操作，并釋放在整個事務期間内占用的資源。
參與者(Cohort)節點向協調者(Coordinator)節點發送"Ack"消息，确認完成。
協調者(Coordinator)節點收到所有參與者(Cohort)節點回報的"Ack"完成消息後，完成事務。

image

事務中斷：

如果任一參與者(Cohort)節點在第一階段傳回的響應消息為"No"，或者協調者(Coordinator)節點在第一階段的詢問逾時之前無法擷取所有參與者(Cohort)節點的響應消息時：

協調者(Coordinator)節點向所有參與者(Cohort)節點發出"Rollback"請求。
參與者(Cohort)節點接收到"Rollback"請求，利用之前寫入的Undo資訊執行復原，并釋放在整個事務期間内占用的資源。
參與者(Cohort)節點向協調者(Coordinator)節點發送"Ack"復原完成消息。
協調者(Coordinator)節點收到所有參與者(Cohort)節點回報的"Ack"復原完成消息後，取消事務。

缺點

同步阻塞問題：執行過程中，所有參與者(Cohort)節點都是事務阻塞型。各個參與者(Cohort)在等待其他參與者響應的過程中，将無法進行其他任務操作；
單點故障：由于協調者(Coordinator)的重要性，一旦協調者(Coordinator)發生故障，參與者(Cohort)會一直阻塞下去。特别是在階段二中，協調者(Coordinator)發生故障，那麼所有的參與者(Cohort)還都處于鎖定事務資源的狀态中，而無法繼續完成事務操作。
資料不一緻：在階段二中，當協調者(Coordinator)向參與者(Cohort)發送commit請求之後，發生了局部網絡異常或者在發送commit請求過程中協調者(Coordinator)出現問題，将導緻隻有一部分參與者(Cohort)收到commit請求，以至于這部分參與者(Cohort)接到commit請求之後就會執行commit操作，而其他部分未接到commit請求的參與者(Cohort)則無法執行事務送出。于是整個分布式系統便出現了資料部一緻性的現象。
不具備完善容錯機制：任意一個節點的失敗都會導緻整個事務的失敗。參與者(Cohort)當機或者逾時，都需要協調者(Coordinator)自身機制去判斷或者協調者(Coordinator)在發出commit消息之後當機，而唯一接收到這條消息的參與者(Cohort)同時也當機了。那麼即使協調者(Coordinator)通過選舉協定産生了新的協調者，這條事務的狀态也是不确定的，沒人知道事務是否被已經送出。

二. 3PC (Three-Phase Commit)

3PC (Three-Phase Commit)為了改進2PC中出現的同步阻塞、單點問題、腦裂以及保守的容錯機制缺陷提出的三階段送出協定，分為CanCommit、PreCommit和doCommit三階段進行事務處理協定。如下圖：

階段一：CanCommit

協調者(Coordinator)向參與者(Cohort)發送commit請求，參與者(Cohort)如果可以送出就傳回Yes響應進入預備狀态，否則傳回No響應。

階段二：PreCommit

協調者(Coordinator)根據參與者(Cohort)的反應情況來決定是否可以繼續事務的PreCommit操作。根據響應情況，有以下兩種可能執行送出和中斷事務：

執行送出：

協調者(Coordinator)從所有的參與者(Cohort)獲得的回報都是Yes響應，那麼就會進行事務的預執行：

發送預送出請求:：協調者(Coordinator)向參與者(Cohort)發送PreCommit請求，并進入Prepared階段。
事務預送出:參與者(Cohort)接收到PreCommit請求後，會執行事務操作，并将undo和redo資訊記錄到事務日志中。
響應回報:如果參與者(Cohort)成功的執行了事務操作，則傳回ACK響應，同時開始等待最終指令。

中斷事務:

有任何一個參與者(Cohort)向協調者(Coordinator)發送了No響應，或者等待逾時之後，Coordinator都沒有接到參與者(Cohort)的響應，那麼就中斷事務:

發送中斷請求:協調者(Coordinator)向所有參與者(Cohort)發送abort請求。
中斷事務:參與者(Cohort)收到來自協調者(Coordinator)的abort請求之後（或逾時之後，仍未收到參與者(Cohort)的請求），執行事務的中斷。

階段三：DoCommit

該階段進行真正的事務送出，也可以分為以下兩種情況執行送出和中斷事務:

執行送出

發送送出請求：協調者(Coordinator)接收到參與者(Cohort)t發送的ACK響應，那麼他将從預送出狀态進入到送出狀态。并向所有參與者(Cohort)發送doCommit請求。
事務送出：參與者(Cohort)接收到doCommit請求之後，執行正式的事務送出。并在完成事務送出之後釋放所有事務資源。
響應回報：事務送出完之後，向協調者(Coordinator)發送ACK響應。
完成事務：協調者(Coordinator)接收到所有參與者(Cohort)的ACK響應之後，完成事務。

中斷事務：

協調者(Coordinator)正常，接收到參與者(Cohort)發送的回報No響應，或者沒有收到到Ack響應（可能是接受者發送的不是ACK響應，也可能響應逾時），那麼就會執行中斷事務。

發送中斷請求：協調者(Coordinator)向所有參與者節點發送abort請求；
事務復原：參與者(Cohort)接收到abort請求後，利用記錄的Undo資訊進行事務復原操作，并在復原完成後釋放整個事務執行期間占用的資源。
回報事務復原結果：參與者(Cohort)在完成事務復原之後，向協調者(Coordinator)發送Ack消息。
中斷事務：協調者(Coordinator)接收所有參與者(Cohort)的回報Ack消息後，中斷事務。

優缺點

優點：降低參與者阻塞範圍，并能夠在出現單點故障後繼續達成一緻
缺點：引入preCommit階段，在這個階段如果出現網絡分區，協調者無法與參與者正常通信，參與者依然會進行事務送出，造成資料不一緻。

作者：Ccwwl

連結：https://www.jianshu.com/p/a3ffc9792bc1

來源：簡書

著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。