在大的操作集合中，所有的小操作都屬於不同的服務器，不同的應用，分佈式事務需要保證這些小操作要麼一起成功，要麼一起失敗。本質上，分佈式事務為了保證數據的一致性
分佈式事務產生的原因
- 數據庫分庫分表（當一個操作需要訪問01庫又要訪問02庫的時候就會有這個問題）
- SOA服務化（所有業務拆分到不同的模塊中，數據存儲在不同的服務器中，所以需要用到分佈式事務）
ACID事務特性
- 原子性
- 一致性
- 隔離性
- 持久性
分佈式事務的解決方案
- 基於XA協議的二階段提交
- 消息事務+最終一致性
- TCC編程模式
二階段提交
XA是分佈式事務協議， 總的來說 XA協議比較簡單，容易實現，但是缺點是
- 同步阻塞 所有事務參與都在等待其他參與者響應的時候都處於同步阻塞的狀態
- 單點問題
- 數據不一致
- 太過保守 任何節點失敗 都會導致整個事務失敗
性能不理想，mysql的XA實現，沒有記錄prepare階段日誌，許多nosql也沒有支持XA
消息事務+最終一致性
A系統 發送prepare信息到 mq 然後得到mq 的返回後進行本地事務 然後在發送執行成功的消息進入mq，接著B系統獲得到A系統完成本地事務的通知後 執行自己的事務 A系統通過消息回調來知曉 事務是否成功
如果A完成事務 B沒完成 則再mq中會不斷髮起請求，知道B完成事務為止
缺點： 該解決方案只是最終一致性，如果B一直不成功，那其實AB 就不是一致性，所以需要業務方去抉擇，判斷
TCC編程模式
TCC 提供一個編程框架，Try Confirm Cancel 三個操作
每個業務方都需要實現這3種操作 try用於事務資源的預留，cancel用戶資源不足時候的cancel方法，必須保證冪等。
協調器調用每個業務方的confirm接口 發現所有參與者的confirm方法都ok了 則分佈式事務結束
如果失敗次數過多，都需要進行事務補償
缺點 業務需要實現這3個操作 對業務侵入較大
總結
分佈式事務，本質上針對多個數據庫的事務進行統一控制，按照控制力度分為 不控制，部分控制，完全控制
不控制 表現為不引入分佈式事務
部分控制 消息事務+最終一致性，TCC編程
完全控制 兩階段提交
性能優缺點： 控制力度越大 性能，qps 都會下降，但是一致性會提高
分享到:
閱讀更多 sandag 的文章
