分佈式事務解決方案

什麼是分佈式事務

在大的操做集合中，全部的小操做都屬於不一樣的服務器，不一樣的應用，分佈式事務須要保證這些小操做要麼一塊兒成功，要麼一塊兒失敗。本質上，分佈式事務爲了保證數據的一致性

分佈式事務產生的緣由

1. 數據庫分庫分表（當一個操做須要訪問01庫又要訪問02庫的時候就會有這個問題）
2. SOA服務化（全部業務拆分到不一樣的模塊中，數據存儲在不一樣的服務器中，因此須要用到分佈式事務）

ACID事務特性

• 原子性
• 一致性
• 隔離性
• 持久性

分佈式事務的解決方案

1. 基於XA協議的二階段提交
2. 消息事務+最終一致性
3. TCC編程模式

二階段提交

XA是分佈式事務協議， 總的來講 XA協議比較簡單，容易實現，可是缺點是

1. 同步阻塞 全部事務參與都在等待其餘參與者響應的時候都處於同步阻塞的狀態
2. 單點問題
3. 數據不一致
4. 太過保守 任何節點失敗 都會致使整個事務失敗

性能不理想，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 都會降低，可是一致性會提升
複製代碼