jee的xa協議就是根據兩階段提交來保證事務的完整性，並實現分布式服務化的強一致性。
兩階段協議提交的流程
①準備階段：協調者向參與者發起指令，參與者評估自己的狀態。如果參與者評估指令可以完成，則會寫redo或者undo的日誌，然後鎖定資源，執行操作，但不提交
②提交階段：如果每個參與者明確返回準備成功，也就是預留資源和執行操作成功，則協調者向參與者發起提交指令，參與者提交資源變更的事務，釋放鎖定資源。如果任何乙個參與者明確返回準備失敗，也就是預留資源和執行操作失敗，則協調者向參與者發起中止指令嗎，參與者取消已經變更的事務，執行undo日誌 ，釋放鎖定資源
致命的問題：
①阻塞：對於任何一次指令都必須收到明確的響應，才會繼續進行下一步，否則處於阻塞狀態，占用的資源被一直鎖定，不會被釋放
②單點故障：如果協調者宕機，參與者麼有協調者指揮，則會一直阻塞，雖然有選舉機制
③腦裂：協調者傳送提交指令，有的參與者接收到並執行事務，有的參與者沒有接受到事務就沒有執行事務，多個參與者之間是不一致的
三階段提交是兩階段提交協議的改進版本，它通過超時機制解決了阻塞的問題。
流程：①：詢問階段：協調者詢問參與者是否可以完成指令，協調者只需要回答是或者不是，而不需要做真正的操作，這個階段超時會導致終止
②準備階段：協調者向參與者發起指令，參與者評估自己的狀態。如果參與者評估指令可以完成，則會寫redo或者undo的日誌，然後鎖定資源，執行操作，但不提交
③提交階段：如果每個參與者明確返回準備成功，也就是預留資源和執行操作成功，則協調者向參與者發起提交指令，參與者提交資源變更的事務，釋放鎖定資源。如果任何乙個參與者明確返回準備失敗，也就是預留資源和執行操作失敗，則協調者向參與者發起中止指令嗎，參與者取消已經變更的事務，執行undo日誌 ，釋放鎖定資源
兩階段與三階段提交協議
首先了解一下為什麼要使用多階段提交協議這個東西。在分布式系統中，我們會存在乙個方法對多個庫進行插入或更新。但是每個節點只能知曉自己的操作是成功或失敗，卻無法知道其他節點的成功和失敗。這樣的話就會導致資料的不一致性。當乙個事務跨越了多個節點時，為了保持資料的一致性，所以就引進了兩階段提交協議這個東西。...
二階段提交協議，三階段提交協議
其實三者都是為了解決分布式一致性問題而存在的協議和演算法。首先先來了解幾個概念。協調者 coordinator 在分布式系統中，當事務操作需要跨越多個分布式節點的時候，為了保持分布式處理的acid特性，需要引入它來統一排程所有節點的執行邏輯。參與者 participant 協調者排程的這些節點就是參...
兩階段提交協議
閱讀次數 142次 類別 我的文章 永久鏈結 trackback 實現分布式事務的關鍵就是兩階段提交協議。在此協議中，乙個或多個資源管理器的活動均由乙個稱為事務協調器的單獨軟體元件來控制。實現分布式事務的關鍵就是兩階段提交協議。在此協議中，乙個或多個資源管理器的活動均由乙個稱為事務協調器的單獨軟體元...