為了解決分布式一緻性問題，産生了不少經典的分布式一緻性算法，本文将介紹其中的2PC和3PC。2PC即Two-Phase Commit，譯為二階段送出協定。3PC即Three-Phase Commit，譯為三階段送出協定。
分布式系統，即運作在多台不同的網絡計算機上的軟硬體系統，并且僅通過消息傳遞來進行通信和協調。
分布式一緻性問題，即互相獨立的節點之間如何就一項決議達成一緻的問題。
2PC，二階段送出協定，即将事務的送出過程分為兩個階段來進行處理：準備階段 和 送出階段。事務的發起者稱協調者， 事務的執行者稱參與者。
階段1：準備階段
1、協調者向所有參與者發送事務内容，詢問是否可以送出事務，并等待所有參與者答複。
2、各參與者， 先鎖住資源，然後執行事務操作，将Undo和Redo資訊記入事務日志中（但不送出事務）。// 就是說 執行sql， 但是不執行 commit
3、如參與者執行成功，給協調者回報YES，即可以送出；如執行失敗 ，給協調者回報NO (或回報逾時) ，即不可送出。
階段2：送出階段
此階段分兩種情況：所有參與者均回報YES、或任何一個參與者回報NO。
所有參與者均回報YES時，即送出事務。
任何一個參與者回報NO時，即中斷事務。
送出事務：（所有參與者均回報YES）
1、協調者向所有參與者發出正式送出事務的請求（即Commit請求）。// 就是發通知說 準備執行 commit 吧
2、參與者執行Commit請求，并釋放整個事務期間占用的資源。// 就是正式的 執行 commit ， 送出之後要釋放 資源， 因為鎖已經釋放。
3、各參與者向協調者回報Ack完成的消息。 // ack 也是不能不忘記的
4、協調者收到所有參與者回報的Ack消息後，即完成事務送出。
中斷事務：（任何一個參與者回報NO）
1、協調者向所有參與者發出復原請求（即Rollback請求）。
2、參與者使用階段1中的Undo資訊執行復原操作，并釋放整個事務期間占用的資源。// 就是正式的 執行 rollback，復原 之後也會 釋放 資源， 因為鎖已經釋放。
3、各參與者向協調者回報Ack完成的消息。
4、協調者收到所有參與者回報的Ack消息後，即完成事務中斷。
小結：
2pc中，參與者沒有逾時機制， 是以， 如果協調者沒有或 沒有正确 發生指令過來， 那麼 會 一直占用資源。
協調者會等待 參與者的響應， —— 這是2pc 中 唯一的一個逾時 時間。
送出事務或 中斷 事務 的時候， 協調者 都需要 等待 所有 參與者的 ack， 這個過程可能 參與者、協調者、網絡 發生故障，如果 協調者正常且 隻收到 部分 ack， 怎麼辦？ 事務是否要 繼續 完成？ 還是記為 待 完成狀态？ 比較郁悶的是，找了很多的 部落格， 沒有看到 對這個問題有進行說明的。。 我感覺是 先會記錄為待 完成， 然後 要麼協調者 停止工作； 要麼 發出 error 警告後 繼續工作。
1、同步阻塞：最大的問題即同步阻塞，即：所有參與事務的邏輯均處于阻塞狀态。
2、單點：協調者存在單點問題，如果協調者出現故障，參與者将一直處于鎖定狀态。
3、腦裂：在階段2中，如果隻有部分參與者接收并執行了Commit請求，會導緻節點資料不一緻。// 就是“送出事務”的時候， 協調者隻有收到部分的ack.
由于2PC存在如上同步阻塞、單點、腦裂問題，是以又出現了2PC的改進方案，即3PC。
3PC，三階段送出協定，是2PC的改進版本，即将事務的送出過程分為CanCommit、PreCommit、do Commit三個階段來進行處理。
階段1：CanCommit
1、協調者向所有參與者 發出包含事務内容的CanCommit請求，詢問是否可以送出事務，并等待所有參與者答複。—— 這裡的 等待 肯定有 逾時機制
2、參與者收到CanCommit請求後，如果認為可以執行事務操作，則回報YES并進入預備狀态（某個參與者進入預備狀态之後， 它會等待 協調者的響應， 這裡也有逾時機制， 如果逾時了， 那麼直接 abort ！ ），否則回報NO。 —— 參與者 需要負責 檢測資源是否足夠， 然後 “預留” 資源。 但是， 這一步驟， 參與者 不會鎖住資源。。 預留 不是鎖。
階段2：PreCommit
此階段分兩種情況：
1、所有參與者均回報YES，即執行事務預送出。
2、任何一個參與者回報NO，或者等待逾時後協調者尚無法收到所有參與者的回報，即中斷事務。
事務預送出：（所有參與者均回報YES時）
1、協調者向所有參與者發出PreCommit請求，進入準備階段。
2、參與者收到PreCommit請求後，執行事務操作，将Undo和Redo資訊記入事務日志中（但不送出事務）。—— 鎖住資源， 執行事務， 參與者向協調者回報Ack響應或No響應，并等待最終指令。然後 進入 等待狀态， 逾時後就直接送出， 為什麼呢？ 因為進入了 這一步驟， 那麼一定是 CanCommit 階段所有的參與者都是傳回yes—— 如果這個時候 協調者又發送了 abort 指令呢？ 。
中斷事務：（任何一個參與者回報NO，或者等待逾時後協調者尚無法收到所有參與者的回報時）
1、協調者向所有參與者發出 abort 請求。
2、無論收到協調者發出的abort請求，或者在等待協調者請求過程中出現逾時，參與者均會中斷事務。
階段3：do Commit
此階段也存在兩種情況：
1、所有參與者均回報Ack響應，即執行真正的事務送出。
送出事務：（所有參與者均回報Ack響應時）
1、如果協調者處于工作狀态，則向所有參與者發出do Commit請求。
2、參與者收到do Commit請求後，會正式執行事務送出，并釋放整個事務期間占用的資源。并且， 各參與者向協調者回報Ack完成的消息。
3、協調者收到所有參與者回報的Ack消息後，即完成事務送出。（ 無論如何， 都得完成 這個事務 ）
1、如果協調者處于工作狀态，向所有參與者發出abort請求。 // 如果 協調者處于非工作狀态， ？？
2、參與者使用階段1中的Undo資訊執行復原操作，并釋放整個事務期間占用的資源。并且， 各參與者向協調者回報Ack完成的消息。
3、協調者收到所有參與者回報的Ack消息後，即完成事務中斷。
注意：進入階段三後，無論協調者出現問題，或者協調者與參與者網絡出現問題，都會導緻參與者無法接收到協調者發出的do Commit請求或abort請求。此時，參與者都會在等待逾時之後，繼續執行事務送出。
優點：降低了阻塞範圍，在等待逾時後協調者或參與者會中斷事務。避免了協調者單點問題，階段3中協調者出現問題時，參與者會繼續送出事務。 ？？？
缺陷：腦裂問題依然存在，即在參與者收到PreCommit請求後等待最終指令，如果此時協調者無法與參與者正常通信，會導緻參與者繼續送出事務，造成資料不一緻。
無論2PC或3PC，均無法徹底解決分布式一緻性問題。
解決一緻性問題，唯有Paxos，後續将單獨總結。
3pc 其實 相對于 2pc 就是多了一個CanConmmit 階段， 這個階段的作用呢？ 我想 就是 保證各個 參與者與 協調者 的網絡是ok 的，避免 “參與者 立即 執行事務操作” ！
但是不管是2PC還是3PC都存在資料一緻性的問題：
2PC：比如協調者在隻給部分參與者發送了Commit請求，那就會出現部分參與者執行了Commit，部分沒有送出 （ 會一直阻塞 等待！），出現不一緻問題。
3PC：在第三階段，一旦參與者無法及時收到來自協調者的資訊之後，他會預設執行commit。而不會一直持有事務資源并處于阻塞狀态，但是這種機制也會導緻資料一緻性問題—— 萬一 協調者需要的是 abort 呢？ 因為 可能協調者 執行延遲發送資料而已。。
還有想要說的是， 2pc 或 3pc 也好， 有沒有明确的限定 階段 的操作？ 我認為是有的， 首先要區分是協調者還是參與者， 然後再看具體情況：
對于 2pc：
協調者一開始處于準備階段， 發送事務及 詢問 後， 然後等待回報。 但參與者還沒有，協調者雖然發送出去了， 但是參與者還沒有立即收到， 有一定的網絡延遲。 參與者收到了之後， 參與者就算正式進入了 準備階段。 然後參與者 進行sql操作（并不送出），然後 回報Yes 或者 No。 這個時候， 回報已經完畢， 參與者就算了 準備完成了。
參與者等待回報逾時，進入中斷流程，完了準備階段 結束， 但是沒有進入送出階段。
然後，協調者收到了各個參與者的回報， 然後，
如果有一個是No，然後進入中斷流程，完了準備階段 結束， 但是沒有進入送出階段。
如果都是Yes，然後協調者就算是進入了送出階段，協調者向各個參與者發送Commit指令，完了就等待響應。
參與者并不知道 協調者會發送什麼指令過來， 會一直 一直等待。 如果收到了Commit指令，那麼就算是進入了送出階段， 然後正式的 commit， 然後回報ack（Y 還是N ？這個時候 有可能回報N 嗎？）， 然後完成 送出階段。這個時候參與者是完成了送出階段， 但是協調者還沒有。
協調者如果收到了所有的node 回報ack， 那麼就結束 送出階段。 （如果不呢？）
注意，各個階段直接是沒有 其他多餘的操作的， 也就是沒有其他階段了！
簡單說 2pc是這樣的，其一，協調者在第一次發送之後 進入階段一，要麼逾時時間内收到回報， 然後處理，然後結束第一階段； 要麼逾時後處理，然後結束第一階段。 發生在這個階段内的 中斷處理也算是 第一階段的内容。 其二， 協調者在第二次發送之 後進入階段二，隻有一個選擇，全部送出，然後收集所有回報， 沒有逾時機制（原因待查）。
簡單說 3pc是這樣的， 它有4個逾時時間， 第一階段，協調者等待 參與者（記為T1），參與者響應後等待協調者（記為T2），第二階段，協調者等待 參與者（記為T3），參與者響應後等待協調者（記為T4），出現其中任何的一個，那麼中斷。
通常認為執行sql（但不送出）， 是可能會失敗的， 這裡必須做确認檢查， 要保證所有節點都Yes否則就中斷， 但是最後階段的 執行 commit 或 rollback 是不會失敗的， 故我們沒有對 commit 或 rollback 的成功還是失敗做檢查（ 不清楚為什麼，可能是因為這些操作沒有占據新的 資源的原因吧。但是試想，如果每個操作都要檢查， 那麼互相之間通信就會沒玩沒了。 或許需要對比一下 paxos 算法了）。