分布式提交

在分布式系統中，事務往往包含多個參與者的活動，單個參與者的活動是能夠保證原子性的，而保證多個參與者之間原子性則需要通過兩階段提交或者三階段提交演算法來實現。

兩階段提交：

兩階段提交協議（two-phase commit protocol,2pc）的過程涉及協調者和參與者。協調者可以看做是事務的發起者，同時也是事務的乙個參與者。對於乙個分布式事務來說，乙個事務是涉及多個參與者的。具體過程如下：

第一階段（準備階段）：

第二階段（提交階段）：

如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾（rollback）訊息；否則，傳送提交（commit）訊息；參與者根據協調者的指令執行提交或者回滾操作，釋放所有事務處理過程中使用的鎖資源（注意：必須在最後階段釋放鎖資源）

如果任一參與者節點在第一階段返回返回的響應資訊為「中止」，或者協調者節點在第一階段的詢問在超時之前無法獲取所有參與者節點的響應訊息時：

不管最後結果如何，第二階段都會結束當前事務。

優點：原理簡單，實現方便。

缺點：

三階段提交：

三階段提交協議（3pc）是2pc的改進版本，與2pc不同的是，3pc有兩個改動點：

引入超時機制，同時在協調者和參與者中都引入超時機制。

在第一階段和第二階段中插入乙個準備階段，保證了在最後提交階段之前各個參與節點的狀態是一致的。

即3pc將2pc的準備階段再次一分為二，這樣3pc就有了cancommit、precommit、docommit三個階段。

cancommit階段：

cancommit階段其實和2pc的準備階段很像。協調者向參與者傳送commit請求，參與者如果可以提交就返回yes響應，否則返回no響應。

precommit階段：

協調者根據參與者的反應情況來決定是否可以執行事務的precommit操作。根據響應情況，有以下兩種可能。

假如協調者從所有的參與者處獲得的反饋都是yes指令，那麼就會執行事務的預執行。

傳送預提交請求：協調者向參與者傳送precommit請求，進入prepared階段。

事務預提交：參與者接收到precommit請求後，會執行事務操作，並將undo和redo資訊記錄到事務日誌中。

響應反饋：如果參與者成功的執行了事務操作，則返回ack響應，同時開始等待最終指令。

加入有任何乙個參與者向協調者傳送了no響應，或者等待超時之後，協調者都沒有接收到參與者的響應，那麼就執行事務的中斷操作。

傳送中斷請求：協調者向所有參與者傳送abort請求。

中斷事務：參與者接收到來自協調者的abort請求之後（或者超時之後，仍未收到協調者的請求），執行事務的中斷操作。

docommit階段：

該階段執行真正的事務提交，也可以分為以下兩種情況。

中斷事務：協調者沒有收到參與者傳送的ack響應（可能參與者傳送的不是ack響應，也可能是響應超時），那麼就會執行中斷事務操作。

在docommit階段，如果參與者無法及時接收到來自協調者的docommit或者rebort請求，會在等待超時之後，繼續執行事務的提交。即當進入第三階段時，由於網路超時等原因，雖然參與者沒有收到commit或者abort響應，事務仍然會提交。

3pc不會一直持有事務資源ing處於阻塞狀態。但這種機制也會導致資料一致性問題。因為，由於網路原因，協調者傳送的abort響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了commit操作，這樣就和其他街道abort命令並執行回滾的參與者之間存在資料不一致的情況。