1.分散式事務

分散式事務是指會涉及到操作多個數據庫的事務。其實就是將對同一庫事務的概念擴大到了對多個庫的事務。目的是為了保證分散式系統中的資料一致性。分散式事務處理的關鍵是必須有一種方法可以知道事務在任何地方所做的所有動作，提交或回滾事務的決定必須產生統一的結果(全部提交或全部回滾)
但是在分散式系統中，各個節點之間相互獨立，通過網路進行進行溝通和協調，由於存在事務機制，可以保證每個獨立節點的資料操作滿足acid。上文提到，分散式事務處理的關鍵是其中所有的機器要麼同一執行事務，要麼統一撤銷事務.為了分散式部署的機器能知道其他節點事務提交究竟是成功還是失敗，所以解決辦法是引入一個協調者

2.兩階段提交

在兩階段提交協議中,系統一般包含兩類機器,一類為協調者,通常一個系統只有一個.另一類是事務參與者,一般包含多個,協調者向事務參與者下命令是否提交

2.1準備階段

準備階段也即投票階段，
協調者通知事務參與者準備提交或者取消事務，每個參與者在本地執行事務，寫本地的redo和undo日誌但是不提交
在請求階段分為如下三步

1. 協調者節點向所有參與者節點詢問是否可以執行提交操作，等待各參與者的響應
2. 參與者節點執行事務操作，並寫入undo和redo資訊日誌
3. 參與者節點響應協調者節點發起的詢問，如果參與者執行事務陳宮則發起同意，若執行事務失敗則發起終止資訊

2.2提交階段

協調者從所有參與者節點獲得的訊息都為同意的時候，參與者和協調者執行如下過程

1. 協調者節點向所有參與者發出”正是提交的請求”
2. 參與者正式完成事務操作並釋放整個事務期內佔用的資源
3. 參與者節點向協調者節點發送完成訊息
4. 協調者節點收到所有參與者反饋完成的訊息後完成事務

如果協調者節點接收到任何參與者在第一階段返回的響應訊息為終止,或者協調者節點在準備階段無法獲取所有節點的響應訊息的時候，參與者與協調者執行如下流程

1. 協調者節點向所有參與者節點發出回滾請求
2. 參與者根據undo日誌進行回滾並釋放事務期間內佔用的資源
3. 參與者向協調發送回滾完成訊息
4. 協調者接受到所有參與者返回的回滾完成訊息後取消事務

3.兩階段提交存在的問題

1. 同步阻塞問題:執行過程中所有參與的節點都是事務阻塞型的。當參與者佔有公共資源的時候，其它執行緒將處於阻塞狀態
2. 單點故障:由於協調者發生故障,參與者會一直阻塞,若協調者在第二階段宕機，即便重選出協調者，那麼參與者仍然會阻塞在第二階段,並長時間鎖定事務資源，無法完成事務操作
3. 資料一致性問題:若協調者向參與者傳送commit請求之後,發生了局部網路異常或者在commit請求過程中,協調者宕機,導致只有一部分參與者接收到commit資訊,而在這部分參與者接收到commit請求後就會執行commit,而未收到資訊的節點會出現無法提交事務的情況,於是就出現了資料不一致的現象
4. 二階段無法解決的問題:協調者發出commit訊息後宕機而唯一接收到這條訊息的參與者同時也宕機了,即使選舉出協調者，也無法知道此事務提交與否