在事務的基本概念一文中，我們知道了事務必須要滿足acid四個基本特性。如果你要讓程式提供事務的特性，要滿足acid的特性，就得試著遵從一些規範。當然，如果有足夠的能力，也可以自定義一些規範。
本文將學習了解相對比較簡單的一階段(1pc)事務提交協議。
先來看乙個序列圖
一階段提交協議只有兩部分
1）開啟乙個事務
2）正常commit事務，或者異常的時候rollback事務
1pc的優點非常顯而易見。非常的簡單，只需要跟乙個服務端互動，在互動上的損耗明顯更少，所以效能上相對是很好的。
而它的缺點也很明顯。如果超過乙個服務端的時候，它無法對多個服務端進行協調。所以使用場景就比較有限。
這麼一看，1pc提交協議是不是很像jdbc關於事務的介面設計呢？
前面，我們說1pc比較適合單個服務端的情況。如果是多個服務端，那麼1pc不能夠協調多個服務端的事務。
那麼，我們假設1pc處理多個服務端會是怎麼樣？
我們看到，活**中開啟了3個事務，如果一路commit成功，那麼都沒問題。
如果其中乙個失敗，那麼rollback當前事務，並需要人工干預之前提交過事務導致的資料不一致問題。
當然，在某些場景下，我們也可以選擇不斷地重試commit，直到成功為止（比如mq，傳送訊息可以重**送，消費訊息維持冪等性即可。而且mq也很少出現commit失敗的情況，即使有也相對容易恢復）。但在大多數場景下，1pc很明顯不適合於多資料來源。
我們可以這麼認為，如果只針對乙個資料來源，或者我們可以不斷重試commit（維持最終一致性）的場景下我們選擇1pc事務提交協議是乙個簡單高效的方案。
分布式事務2PC協議
two phase commit protocol 在事務處理，資料庫，計算機網路中，兩階段提交 2pc 是一種原子提交協議。它是一種分布式演算法，協調參與分布式原子事務的所有程序，決定是提交事務還是中止 回滾 事務 它是一種協商一致性協議 該協議即使在許多臨時系統故障 包括程序 網路節點 通訊等故...
二段提交協議 三段提交協議
1 二段提交協議 2pc提交事務階段 投票階段 協調者發起事務請求到所有的參與者，參與者接收到事務請求後判斷自身情況，如果不能執行事務，則反饋不能提交事務，返回no，如果可以就執行事務，並將undo和redo資訊記錄事務日誌中，反饋yes 執行事務階段 協調者收到所有參與者反饋yes就發布commi...
二段提交協議與三段提交協議
第一階段 準備階段 協調者向參與者發起指令，參與者評估自己的狀態，如果參與者評估指令可以完成，則會寫redo或者undo日誌，讓後鎖定資源，執行操作，但並不提交。第二階段 如果每個參與者明確返回準備成功，則協調者向參與者傳送提交指令，參與者釋放鎖定的資源，如何任何乙個參與者明確返回準備失敗，則協調者...