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

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

[[247750]]

分布式事務為什么難?

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

什么是兩階段提交?

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

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

為什么叫兩階段提交?

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

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

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

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

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

舉個栗子：

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

投票階段

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

(2)乙回復有時間;

(3)丙回復有時間;

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

提交階段

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

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

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

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

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

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

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

兩階段提交的缺陷?

2PC在執(zhí)行過程中，所有節(jié)點都處于阻塞狀態(tài)，所有節(jié)點所持有的資源(例如數(shù)據(jù)庫數(shù)據(jù)，本地文件等)都處于封鎖狀態(tài)。

典型情況為：

• 某一個參與者回復消息之前，所有參與者以及協(xié)調者都處于阻塞狀態(tài);
• 在協(xié)調者發(fā)出消息之前，所有參與者都處于阻塞狀態(tài);

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

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

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】

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