上一篇《分布式事務，原來可以這么玩?》引起了不少討論，后續準備開一個新系列，講一講分布式的東西，今天就從相對容易理解的“兩階段提交”談起。

畫外音：給自己定了一個目標，用通俗的語言把Paxos講懂。

[[247750]]

分布式事務為什么難?

在分布式環境下，每個節點都可以知曉自己操作的成功或者失敗，卻無法知道其他節點操作的成功或失敗。當一個分布式事務跨多個節點時，保持事務的原子性與一致性，是非常困難的。

什么是兩階段提交?

二階段提交2PC(Two phase Commit)是一種，在分布式環境下，所有節點進行事務提交，保持一致性的算法。

它通過引入一個協調者(Coordinator)來統一掌控所有參與者(Participant)的操作結果，并指示它們是否要把操作結果進行真正的提交(commit)或者回滾(rollback)。

為什么叫兩階段提交?

顧名思義，2PC分為兩個階段：

• 投票階段(voting phase)：參與者通知協調者，協調者反饋結果;

畫外音：可以理解為單機事務的trx.exec()。

• 提交階段(commit phase)：收到參與者的反饋后，協調者再向參與者發出通知，根據反饋情況決定各參與者是否要提交還是回滾;

畫外音：可以理解為單機事務的trx.commit() 或者 trx.rollback()。

舉個栗子：

甲乙丙丁四人要組織一個會議，需要確定會議時間，不妨設甲是協調者，乙丙丁是參與者。

投票階段

(1)甲發郵件給乙丙丁，通知明天十點開會，詢問是否有時間;

(2)乙回復有時間;

(3)丙回復有時間;

(4)丁遲遲不回復，此時對于這個事務，甲乙丙均處于阻塞狀態，算法無法繼續進行;

提交階段

(1)協調者甲將收集到的結果通知給乙丙丁;

畫外音：什么時候通知，以及反饋結果如何，在此例中取決與丁的時間與決定，

• 假設丁回復有時間，則通知commit;
• 假設丁回復沒有時間，則通知rollback;

(2)乙收到通知，并ack協調者;

(3)丙收到通知，并ack協調者;

(4)丁收到通知，并ack協調者;

畫外音：如果甲沒有收到所有ack，則分布式事務遲遲不會結束，下一輪投票則遲遲不會開展。

兩階段提交的缺陷?

2PC在執行過程中，所有節點都處于阻塞狀態，所有節點所持有的資源(例如數據庫數據，本地文件等)都處于封鎖狀態。

典型情況為：

• 某一個參與者回復消息之前，所有參與者以及協調者都處于阻塞狀態;
• 在協調者發出消息之前，所有參與者都處于阻塞狀態;

另外，如有協調者或者某個參與者出現了崩潰，為了避免整個算法處于一個完全阻塞狀態，往往需要借助超時機制來將算法繼續向前推進。

總的來說，2PC是一種比較保守并且低效的算法，分布式事務真的很難做。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文