在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。
很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資料庫的完整性約束實現的，永續性則是通過commit日誌來實現的，不是由兩階段提交來保證的。至於兩階段提交如何保證隔離性，可以參考large-scale incremental processing using distributed transactions and notifications中兩階段提交的具體實現。
兩階段提交的過程涉及到協調者和參與者。協調者可以看做成事務的發起者，同時也是事務的乙個參與者。對於乙個分布式事務來說，乙個事務是涉及到多個參與者的。具體的兩階段提交的過程如下：
第一階段：
首先，協調者在自身節點的日誌中寫入一條的日誌記錄，然後所有參與者傳送訊息prepare t，詢問這些參與者（包括自身），是否能夠提交這個事務；
參與者在接受到這個prepare t 訊息以後，會根據自身的情況，進行事務的預處理，如果參與者能夠提交該事務，則會將日誌寫入磁碟，並返回給協調者乙個ready t資訊，同時自身進入預提交狀態狀態；如果不能提交該事務，則記錄日誌，並返回乙個not commit t資訊給協調者，同時撤銷在自身上所做的資料庫改；
參與者能夠推遲傳送響應的時間，但最終還是需要傳送的。
第二階段：
協調者會收集所有參與者的意見，如果收到參與者發來的not commit t資訊，則標識著該事務不能提交，協調者會將abort t 記錄到日誌中，並向所有參與者傳送乙個abort t 資訊，讓所有參與者撤銷在自身上所有的預操作；
如果協調者收到所有參與者發來prepare t資訊，那麼協調者會將commit t日誌寫入磁碟，並向所有參與者傳送乙個commit t資訊，提交該事務。若協調者遲遲未收到某個參與者發來的資訊，則認為該參與者傳送了乙個vote_abort資訊，從而取消該事務的執行。
參與者接收到協調者發來的abort t資訊以後，參與者會終止提交，並將abort t 記錄到日誌中；如果參與者收到的是commit t資訊，則會將事務進行提交，並寫入記錄
一般情況下，兩階段提交機制都能較好的執行，當在事務進行過程中，有參與者宕機時，他重啟以後，可以通過詢問其他參與者或者協調者，從而知道這個事務到底提交了沒有。當然，這一切的前提都是各個參與者在進行每一步操作時，都會事先寫入日誌。
唯一乙個兩階段提交不能解決的困境是：當協調者在發出commit t訊息後宕機了，而唯一收到這條命令的乙個參與者也宕機了，這個時候這個事務就處於乙個未知的狀態，沒有人知道這個事務到底是提交了還是未提交，從而需要資料庫管理員的介入，防止資料庫進入乙個不一致的狀態。當然，如果有乙個前提是：所有節點或者網路的異常最終都會恢復，那麼這個問題就不存在了，協調者和參與者最終會重啟，其他節點也最終也會收到commit t的資訊。
兩階段提交
1 二階段提交協議 一般分為協調器c和若干事務執行者si兩種角色 當執行某一事務t的所有站點si都通知c事務執行完成，c即啟動二階段提交協議。1.首先c向所有si發訊息 c先將訊息寫到本機日誌 si收到訊息後，根據本機t的執 況，如果成功返回，不成功返回。返回前都應把要返回的訊息寫到日誌裡 2.c收...
兩階段提交
翻譯自 不像在本地資料庫的事務，分布式資料庫涉及到在多個資料庫中改變資料，因此，分布式事務處理更加複雜，因為資料庫間必須協調保證整個事務的原子性，即要不全部成功，要不全部失敗。事務一旦提交，無法回滾 資料保證資料的完整性的方式是使用兩階段提交 xa transaction 第一階段稱為準備階段，事務...
兩階段提交事務
2pc two phase commitment protocol 兩階段提交協議 實現分布式事務的關鍵就是兩階段提交協議。在此協議中，乙個或多個資源管理器的活動均由乙個稱為事務協調器的單獨軟體元件來控制。此協議中的五個步驟如下 應用程式呼叫事務協調器中的提交方法。事務協調器將聯絡事務中涉及的每個資...