分佈式事務種類介紹
如果覺得還可以 記得關注一下公衆號哦！一起交流學習！
一、2PC 二階段提交
1.算法思路
參與者將本身事務的執行情況發送給事務協調者，由事務協調者判斷事務調用鏈是否執行提交操作還是回滾操作
2.提交步驟
1.準備階段
1.1 事務協調者向所有的事務參與者詢問是否可以執行提交操作，並開始等待各事務參與者的執行迴應！
1.2 事務參與者迴應事務協調者的請求，並執行本地的事務日誌操作，等待事務協調者的通知！
2.提交階段
2.1 事務協調者收到參與者的失敗消息或者超時消息，則通知所有事務參與者執行回滾操作！若全部成功則通知所有的事務參與者執行提交操作！
2.2 釋放事務操作所佔用的所有鎖資源！
3.缺陷
- 阻塞問題
1.1 所有的事務操作都處於同步阻塞狀態，即所有的是事務參與者都必須等待事務協調者的消息，收不到消息則處於持續阻塞狀態！
- 單點故障
2.1 當事務協調者服務宕機活出現其他故障後，所有的事務都處於掛起阻塞狀態！（雖然在協調者掛掉之後能夠選舉出新的協調者，但是他仍不能解決各參與者的鎖定狀態！）
3.數據不一致性
3.1 網絡是不可靠的，當二階段進行中，由事務協調者發送給參與者的事務操作信息，因爲網絡原因，部分事務參與者沒有收到，則會出現，部分事務無法進行事務操作，從而造成事務的不一致性！
3.2 當事務協調者掛了，唯一接收這條消息的參與者也掛了！那麼當新的協調者被選舉出來之後，也無法知道事務是否已經進行操作！
二、3PC 三階段提交
相對於二階段提交，三階段提交在一階段和二階段中增加了一步準備階段，以確保事務在提交時，所有節點的狀態是一致的！
1. canCommit階段 詢問階段
這一階段對比二階段提交的第一階段，即事務協調者去詢問各事務參與者：“你們是否可以執行本次事務，即參與者對自身狀態的檢查”，若參與者能夠執行則迴應 YES反之NO。
2.preCommit階段 預提交階段
根據一階段返回的狀態信息 YES AND NO 此時事務協調者會想參與者發送預提交或預回滾請求。參與者收到後開始執行事務操作，想本地寫入事務日誌，但是不執行提交或回滾命令！操作完成後向協調者發送ACK命令，等待下一步指令！
3. DoCommit 提交階段
當收到所有參與者都發送的ACK命令後，向參與者發送提交或回滾請求！
4. 相對二階段提交所做的優化
相比較2PC而言，3PC對於協調者和參與者都設置了超時時間，而2PC只有協調者才擁有超時機制。
主要是避免了參與者在長時間無法與協調者節點通訊（協調者掛掉了）的情況下，無法釋放資源的問題，因爲參與者自身擁有超時機制會在超時後，自動進行本地commit從而進行釋放資源。而這種機制也側面降低了整個事務的阻塞時間和範圍。
另外，通過CanCommit、PreCommit、DoCommit三個階段的設計，相較於2PC而言，多設置了一個緩衝階段保證了在最後提交階段之前各參與節點的狀態是一致的。但是3PC依然沒有完全解決數據不一致的問題。
三、補償事務（TCC）
TCC（Try-Confirm-Cancel）又稱補償事務。其核心思想是：“針對每個操作都要註冊一個與其對應的確認和補償（撤銷操作）”。它分爲三個操作：
-
Try階段：主要是對業務系統做檢測及資源預留。
-
Confirm階段：確認執行業務操作。
-
Cancel階段：取消執行業務操作。
1.Try: 嘗試執行業務
• 完成所有業務檢查(一致性)
• 預留必須業務資源(準隔離性)
2.Confirm:確認執行業務
• 真正執行業務
• 不作任何業務檢查
• 只使用Try階段預留的業務資源
• Confirm操作要滿足冪等性
3.Cancel: 取消執行業務
• 釋放Try階段預留的業務資源
• Cancel操作要滿足冪等性
4.TCC與2PC協議比較
• 位於業務服務層而非資源層
• 沒有單獨的準備(Prepare)階段， Try操作兼備資源操作與準備能力
• Try操作可以靈活選擇業務資源的鎖定粒度(以業務定粒度)
• 較高開發成本
5. 缺陷
tcc事務補償性對業務代碼的侵入性過高，開發成本大！需要開發人員在業務層手動提供提交操作以及混滾操作！所以對開發人員要求也比較高！
喜歡這篇文章的小夥伴，請識別下方二維碼關注本公衆號，小編不定期贈送免費的學習資源哦
下面是我的個人微信號，歡迎叨擾！
