2PC兩階段提交協議

一句話總結：2PC兩階段提交協議應用於分佈式事務場景，解決分佈式多個系統間數據的一致性，如數據庫XA機制。

 

背景：

假設有兩個系統A和B，同一個原子業務，舉個經常使用的轉帳例子，A系統加1000元，B系統相應減1000元，這時若A執行成功了，B執行失敗了，對業務來講確定出問題了。這裏的問題出在系統A不感知B的狀態，B也不感知A。對於分佈式系統，須要一個協調者來感知每一個系統的執行狀態。這個協調者能夠由應用或數據庫/緩存的Agent來承擔均可以。

 

2PC兩階段提交協議：

 

你們不要將兩階段提交想的複雜，事實上，這個協議很簡單，prepare階段參與者只是執行事務，但不提交，此時已能知道可否成功執行，並將此狀態反饋給協調者。協調者收到都成功，則通知全部參與者commit。若只要有一個反饋失敗，則通知全部參與者rollback。協調者在commit階段發出commit或rollback通知後就無論了。

 

延伸思考：

上面描述的是正常流程，生產環境還要全面考慮各類異常場景。

一、協調者節點掛了

此場景比較主流的方案是選舉機制，首次即經過選舉決定誰是協調者，當協調者掛掉後從新選舉。

二、commit階段出現部分失敗

2PC協議在commit階段發出commit或rollback通知後就無論了，若此時因爲網絡或系統緣由，A執行commit/rollback成功，B執行失敗，仍是會出現數據不一致。此場景就須要考慮3PC、另外一個獨立Agent進程、超時機制等來確保事務不管如何都會被執行。

 

備註：網上不少有說一個問題是同步阻塞，性能不行。我以爲大多數場景特別是針對事務數據一致性的場景對性能要求並不高，不應把這個做爲問題。畢竟作1230六、微信、抖音、王者榮耀等這些高併發實時性強項目的場景很少，普通數千併發實時要求也不強以當前服務器性能徹底hold的住的。

 

引用：

 https://en.wikipedia.org/wiki/Two-phase_commit_protocol

 

注：圖片來源於網絡，侵刪。