一句話總結：2PC兩階段提交協議應用於分布式事務場景，解決分布式多個系統間數據的一致性，如數據庫XA機制。
背景：
假設有兩個系統A和B，同一個原子業務，舉個常用的轉賬例子，A系統加1000元，B系統相應減1000元，這時若A執行成功了，B執行失敗了，對業務來說肯定出問題了。這里的問題出在系統A不感知B的狀態，B也不感知A。對於分布式系統，需要一個協調者來感知每個系統的執行狀態。這個協調者可以由應用或數據庫/緩存的Agent來承擔都可以。
2PC兩階段提交協議：
大家不要將兩階段提交想的復雜，事實上，這個協議很簡單，prepare階段參與者只是執行事務，但不提交，此時已能知道能否成功執行，並將此狀態反饋給協調者。協調者收到都成功，則通知所有參與者commit。若只要有一個反饋失敗，則通知所有參與者rollback。協調者在commit階段發出commit或rollback通知后就不管了。
延伸思考：
上面描述的是正常流程，生產環境還要全面考慮各種異常場景。
1、協調者節點掛了
此場景比較主流的方案是選舉機制，首次即通過選舉決定誰是協調者，當協調者掛掉后重新選舉。
2、commit階段出現部分失敗
2PC協議在commit階段發出commit或rollback通知后就不管了，若此時由於網絡或系統原因，A執行commit/rollback成功，B執行失敗，還是會出現數據不一致。此場景就需要考慮3PC、另一個獨立Agent進程、超時機制等來確保事務無論如何都會被執行。
備注：網上很多有說一個問題是同步阻塞，性能不行。我覺得大多數場景特別是針對事務數據一致性的場景對性能要求並不高，不該把這個作為問題。畢竟做12306、微信、抖音、王者榮耀等這些高並發實時性強項目的場景不多，普通數千並發實時要求也不強以當前服務器性能完全hold的住的。
引用：
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
注：圖片來源於網絡，侵刪。