1.兩階段提交

這裡只寫原理，不談具體實現過程。

首先需要兩個載體，一個是事務提交者，一個是協調器。

   第一階段：

協調器向所有的事務提交者發起詢問，是否可以執行本地事務。

不同的事務提交者在本地執行事務，執行成功向協調器傳送成功，失敗則傳送失敗（超時也算失敗）。

   第二階段：

協調器如果在第一階段收到失敗，則通知所有事務提交者進行rollback操作。如果沒有收到失敗則向事務提交者傳送可以進行提交。

事務提交者提交事務，釋放資源，並向協調器傳送成功，如果是回滾成功，則傳送回滾成功。

協調器收到回信後，結束事務。（未收到回信，例如commit沒有傳到事務提交者也結束，所以有很大缺點）

2.三階段提交

第一階段：

協調器向所有的事務提交者發起詢問，是否可以執行本地事務。

事務提交者認為可以執行則傳送true，不可以則傳送false（或者超時）。

第二階段：

如果協調器收到false，則中斷事務併發送中斷請求，全部收到true，則向事務提交者傳送可以準備執行事務的資訊。

事務提交者（未收到或者超時或者收到中斷請求，執行事務的中斷）收到可以準備執行時，會執行事務操作，

成功執行會向協調器傳送true，失敗返回false。

第三階段：

協調器收到二階段全為true時，向事務提交者傳送可以提交，否則傳送回滾（未收到或者超時也回滾）。

事務提交者收到可以提交，提交事務，返回成功（如果超時未收到依然提交事務）。收到回滾，則回滾事務，傳送回滾成功。

協調器收到所有的提交事務成功，結束事務，收到回滾成功，中斷事務。

三階段加入了超時機制，但仍無法完全解決一致性問題，因為在三階段時，發生超時情況，事務會預設提交。

3.訊息事務（效能高）

基於訊息中介軟體的分散式事務。（要支援本地執行和訊息傳送是原子性的，也可以使用別的方法來實現，使用日誌或者狀態表）

最簡單的，事務A執行完本地事務後，向訊息佇列傳送訊息，訊息中介軟體提醒其他事務完成剩餘的操作。

但是需要很多的手段來確保事務的最終一致性，直接使用分散式事務效能低，但開發難度小。

4.Paxos演算法

還沒看明白