分布式基礎,啥是兩階段提交?
上一篇《分布式事務,原來可以這么玩?》引起了不少討論,后續準備開一個新系列,講一講分布式的東西,今天就從相對容易理解的“兩階段提交”談起。
畫外音:給自己定了一個目標,用通俗的語言把Paxos講懂。
分布式事務為什么難?
在分布式環境下,每個節點都可以知曉自己操作的成功或者失敗,卻無法知道其他節點操作的成功或失敗。當一個分布式事務跨多個節點時,保持事務的原子性與一致性,是非常困難的。
什么是兩階段提交?
二階段提交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沈劍”原創稿件,轉載請聯系原作者】


































