分布式基礎(chǔ)，啥是兩階段提交？
上一篇《分布式事務(wù)，原來可以這么玩?》引起了不少討論，后續(xù)準(zhǔn)備開一個新系列，講一講分布式的東西，今天就從相對容易理解的“兩階段提交”談起。
畫外音：給自己定了一個目標(biāo)，用通俗的語言把Paxos講懂。
分布式事務(wù)為什么難?
在分布式環(huán)境下，每個節(jié)點都可以知曉自己操作的成功或者失敗，卻無法知道其他節(jié)點操作的成功或失敗。當(dāng)一個分布式事務(wù)跨多個節(jié)點時，保持事務(wù)的原子性與一致性，是非常困難的。
什么是兩階段提交?
二階段提交2PC(Two phase Commit)是一種，在分布式環(huán)境下，所有節(jié)點進行事務(wù)提交，保持一致性的算法。
它通過引入一個協(xié)調(diào)者(Coordinator)來統(tǒng)一掌控所有參與者(Participant)的操作結(jié)果，并指示它們是否要把操作結(jié)果進行真正的提交(commit)或者回滾(rollback)。
為什么叫兩階段提交?
顧名思義，2PC分為兩個階段：
- 投票階段(voting phase)：參與者通知協(xié)調(diào)者，協(xié)調(diào)者反饋結(jié)果;
畫外音：可以理解為單機事務(wù)的trx.exec()。
- 提交階段(commit phase)：收到參與者的反饋后，協(xié)調(diào)者再向參與者發(fā)出通知，根據(jù)反饋情況決定各參與者是否要提交還是回滾;
畫外音：可以理解為單機事務(wù)的trx.commit() 或者 trx.rollback()。
舉個栗子：
甲乙丙丁四人要組織一個會議，需要確定會議時間，不妨設(shè)甲是協(xié)調(diào)者，乙丙丁是參與者。
投票階段
(1)甲發(fā)郵件給乙丙丁，通知明天十點開會，詢問是否有時間;
(2)乙回復(fù)有時間;
(3)丙回復(fù)有時間;
(4)丁遲遲不回復(fù)，此時對于這個事務(wù)，甲乙丙均處于阻塞狀態(tài)，算法無法繼續(xù)進行;
提交階段
(1)協(xié)調(diào)者甲將收集到的結(jié)果通知給乙丙丁;
畫外音：什么時候通知，以及反饋結(jié)果如何，在此例中取決與丁的時間與決定，
- 假設(shè)丁回復(fù)有時間，則通知commit;
- 假設(shè)丁回復(fù)沒有時間，則通知rollback;
(2)乙收到通知，并ack協(xié)調(diào)者;
(3)丙收到通知，并ack協(xié)調(diào)者;
(4)丁收到通知，并ack協(xié)調(diào)者;
畫外音：如果甲沒有收到所有ack，則分布式事務(wù)遲遲不會結(jié)束，下一輪投票則遲遲不會開展。
兩階段提交的缺陷?
2PC在執(zhí)行過程中，所有節(jié)點都處于阻塞狀態(tài)，所有節(jié)點所持有的資源(例如數(shù)據(jù)庫數(shù)據(jù)，本地文件等)都處于封鎖狀態(tài)。
典型情況為：
- 某一個參與者回復(fù)消息之前，所有參與者以及協(xié)調(diào)者都處于阻塞狀態(tài);
- 在協(xié)調(diào)者發(fā)出消息之前，所有參與者都處于阻塞狀態(tài);
另外，如有協(xié)調(diào)者或者某個參與者出現(xiàn)了崩潰，為了避免整個算法處于一個完全阻塞狀態(tài)，往往需要借助超時機制來將算法繼續(xù)向前推進。
總的來說，2PC是一種比較保守并且低效的算法，分布式事務(wù)真的很難做。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
