分散式一致性協議

XA介面

 XA是由X/Open組織提出的分散式事務的規範。XA規範主要定義了(全域性)事務管理器(Transaction Manager)和(區域性)資源管理器(Resource Manager)之間的介面。XA介面是雙向的系統介面，在事務管理器（Transaction Manager）以及一個或多個資源管理器（Resource Manager）之間形成通訊橋樑。XA之所以需要引入事務管理器是因為，在分散式系統中，從理論上講（參考Fischer等的論文），兩臺機器理論上無法達到一致的狀態，需要引入一個單點進行協調。事務管理器控制著全域性事務，管理事務生命週期，並協調資源。資源管理器負責控制和管理實際資源（如

Jta規範

作為java平臺上事務規範JTA（Java Transaction API）也定義了對XA事務的支援，實際上，JTA是基於XA架構上建模的，在JTA 中，事務管理器抽象為javax.transaction.TransactionManager介面，並通過底層事務服務（即JTS）實現。像很多其他的java規範一樣，JTA僅僅定義了介面，具體的實現則是由供應商(如J2EE廠商)負責提供，目前JTA的實現主要由以下幾種：
1.J2EE容器所提供的JTA實現(JBoss)
2.獨立的JTA實現:如JOTM，Atomikos.這些實現可以應用在那些不使用J2EE應用伺服器的環境裡用以提供分佈事事務保證。如Tomcat,Jetty以及普通的java應用。

兩段提交協議

交易中介軟體與資料庫通過 XA 介面規範，使用兩階段提交來完成一個全域性事務， XA 規範的基礎是兩階段提交協議。
第一階段是表決階段，所有參與者都將本事務能否成功的資訊反饋發給協調者；

 準備階段：協調者向參與者發起指令，參與者評估自己的狀態，如果參與者評估指令可以完成，則會寫redo或者undo日誌，讓後鎖定資源，執行操作，但並不提交。

協調者會向參與者傳送一個指令，如果參與者收到指令後，會把該業務邏輯是否執行成功結果返回給協調者

如果參與者都返回執行成功，協調者在第二階段傳送提交事務通知，如果有一方執行失敗，就會終止提交。

第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾。

第二階段:如果每個參與者明確返回準備成功，則協調者向參與者傳送提交指令，參與者釋放鎖定的資源，如何任何一個參與者明確返回準備失敗，則協調者會發送中指指令，參與者取消已經變更的事務，釋放鎖定的資源。

兩階段提交方案應用非常廣泛，幾乎所有商業OLTP資料庫都支援XA協議。但是兩階段提交方案鎖定資源時間長，對效能影響很大，基本不適合解決微服務事務問題。

  三階段提交協議

三階段提交協議是兩階段提交協議的改進版本。它通過超時機制解決了阻塞的問題，並且把兩個階段增加為三個階段：

詢問階段：協調者詢問參與者是否可以完成指令，協調者只需要回答是還是不是，而不需要做真正的操作，這個階段超時導致中止。

準備階段：如果在詢問階段所有的參與者都返回可以執行操作，協調者向參與者傳送預執行請求，然後參與者寫redo和undo日誌，執行操作，但是不提交操作；如果在詢問階段任何參與者返回不能執行操作的結果，則協調者向參與者傳送中止請求，這裡的邏輯與兩階段提交協議的的準備階段是相似的，這個階段超時導致成功

提交階段：如果每個參與者在準備階段返回準備成功，也就是預留資源和執行操作成功，協調者向參與者發起提交指令，參與者提交資源變更的事務，釋放鎖定的資源；如果任何一個參與者返回準備失敗，也就是預留資源或者執行操作失敗，協調者向參與者發起中止指令，參與者取消已經變更的事務，執行undo日誌，釋放鎖定的資源，這裡的邏輯與兩階段提交協議的提交階段一致

2PC與3PC提交區別

增加了一個詢問階段，詢問階段可以確保儘可能早的發現無法執行操作而需要中止的行為，但是它並不能發現所有的這種行為，只會減少這種情況的發生在準備階段以後，協調者和參與者執行的任務中都增加了超時，一旦超時，協調者和參與者都繼續提交事務，預設為成功，這也是根據概率統計上超時後預設成功的正確性最大

三階段提交協議與兩階段提交協議相比，具有如上的優點，但是一旦發生超時，系統仍然會發生不一致，只不過這種情況很少見罷了，好處就是至少不會阻塞和永遠鎖定資源。