分散式事務解決方案
阿新 • • 發佈：2019-12-31
什麼是分散式事務
在大的操作集合中，所有的小操作都屬於不同的伺服器，不同的應用，分散式事務需要保證這些小操作要麼一起成功，要麼一起失敗。本質上，分散式事務為了保證資料的一致性
分散式事務產生的原因
- 資料庫分庫分表（當一個操作需要訪問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 都會下降，但是一致性會提高
複製程式碼