生活就像海洋，只有意志堅強的人，才能到達彼岸 —— 馬克思

文章目錄

• 一、導讀
• 二、分布式理論
• • CAP理論
  • BASE理論: AP理論的衍生
• 三、分布式解決方案
• • 2PC策略
  • • 原子性保障
    • 隔離性保障
    • 小結
  • TCC協議
  • • 原子性保障
    • 一致性保障
    • 隔離性保障
  • Saga 協議
  • 小結
• 四、參考文章

一、導讀

事務提供一種機制將一個活動涉及的所有操作納入到一個不可分割的執行單元，保整原子性、持久性、隔離性(執行程序中互不可見)、一致性，提供一種“要么什么都不做，要么做全套(All or Nothing)”機制，

分布式事務可以看為兩塊，一個是service產生多個節點，另一個是resource產生多個節點，

1. 多個service間進行rpc呼叫操作，一系列的操作組成了一個事務
2. 多個resource的修改放在一個事務里完成(分庫分表導致異地更新、多個表修改、快取修改等)

ACID相關概念可以參考我早期寫的一篇博客: 博文鏈接

二、分布式理論

CAP理論

C (一致性):對某個指定的客戶端來說，讀操作能回傳最新的寫操作，

A (可用性)：非故障的節點在合理的時間內回傳合理的回應(不是錯誤和超時的回應)，

P (磁區容錯性):當出現網路磁區后，系統能夠繼續作業，打個比方，這里個集群有多臺機器，有臺機器網路出現了問題，但是這個集群仍然可以正常作業，

對于分布式，P是必須的，CA選其一達成CP(犧牲一點可用達成強一致)、AP(犧牲一點一致性達成高可用)，同時對于被犧牲的那個特性，也要盡可能保證，

比如你選擇了CP，并不是叫你放棄A，因為P出現的概率實在是太小了，大部分的時間你仍然需要保證CA，就算磁區出現了你也要為后來的A做準備，比如通過一些日志的手段，使其他機器恢復至可用，

BASE理論: AP理論的衍生

1. 基本可用:分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用，
2. 軟狀態:允許系統中存在中間狀態，這個狀態不影響系統可用性，這里指的是CAP中的不一致，
3. 最終一致:最終一致是指經過一段時間后，所有節點資料都將會達到一致，

業內通常把嚴格遵循 ACID 的事務稱為剛性事務；而基于 BASE 思想實作的事務稱為柔性事務，柔性事務并不是完全放棄了 ACID，僅僅是放寬了一致性要求：事務完成后的一致性嚴格遵循，事務中的一致性可適當放寬(最終一致性)，

三、分布式解決方案

warm: 不要為了過度設計導致需要分布式事務

我見過太多團隊一個人維護幾個微服務，太多團隊過度設計，搞得所有人疲勞不堪，而微服務過多就會引出分布式事務，這個時候我不會建議你去采用下面任何一種方案，而是請把需要事務的微服務聚合成一個單機服務，

2PC策略

2PC策略就是兩階段提交策略，核心流程如下所示(以XA協議舉例)，在各大主流資料庫都有自己實作，

XA協議基于X/Open Distributed Transaction Processing（DTP）模型，該模型中包含一個全域事務管理器(TM，Transaction Manager）和多個資源管理器（RM，Resource Manager)，由于事務管理器是單點的，可能會成為分布式事務的性能瓶頸，

1. 全域事務管理器負責管理全域事務狀態與參與的資源，協同資源一起提交或回滾
2. 資源管理器則負責具體的資源操作

原子性保障

XA協議分為兩階段，一階段做本地事務執行和預提交校驗，如果預提交通過則commit事務，否則回滾本地事務，

準備階段：

TM 向每個 RM 發送準備訊息，如果 RM 的本地事務操作執行成功，則回傳成功；如果 RM 的本地事務操作執行失敗，則回傳失敗，

提交階段

如果 TM 收到了所有 RM 回復的成功訊息，則向每個 RM 發送提交訊息；否則發送回滾訊息；RM 根據 TM 的指令執行提交或者回滾本地事務操作，釋放所有事務處理程序中使用的鎖資源，

隔離性保障

XA協議中的隔離性由各個RM(資源管理器)保障，在一個本地事務中，每執行一條更新操作之前，都會先獲取對應的鎖資源，只有獲取鎖資源成功才會執行該操作，并且一旦獲取了鎖資源就會持有該鎖資源直到本事務執行結束，

RM可以保障本地事務對于其他事務不可見，但當出現事務套事務的情況時，中間事務的狀態可能暴露出來，

用下圖舉個例子，RM1和RM2本省是可以保證事務隔離性的，但在在 RM1 的本地子事務提交完畢到 RM2 的本地子事務提交完畢之間，RM1作為中間狀態是可以被觀察到的，

MySQL建議使用SERIALIZABLE級別的隔離級別來保證全域事務隔離性，但這個性能太差，許多分布式實物庫都實作了分布式 MVCC 機制來提供全域的一致性讀，使用快照機制保證中間事務狀態不被讀取，

小結

1. 業務方只需要關注自己的業務SQL，由XA框架實作事務保障，
2. XA協議一般來說只適合短時間的事務，因為整個事務期間都是獨占資料，長時間的事務容易造成堵塞，

TCC協議

一句話總結: 業務開發程式員保障分布式事務，

TCC（Try-Confirm-Cancel）由業務活動管理器控制一致性，它不依萊澩管理器（RM）對分布式事務的支持，而是通過對業務邏輯的分解來實作分布式事務，業務接入 TCC 模型需要拆分業務邏輯成兩個階段，并實作 Try、Confirm、Cancel 三個介面，定制化程度高，開發成本高，

原子性保障

TCC 模型也使用 2PC 原子提交協議來保證事務原子性，Try 操作對應 2PC 的一階段準備（Prepare）；Confirm 對應 2PC 的二階段提交（Commit），Cancel 對應 2PC 的二階段回滾（Rollback），可以說 TCC 就是應用層的 2PC，

一致性保障

TCC 分布式事務模型僅提供兩階段原子提交協議，保證分布式事務原子性，事務的隔離交給業務邏輯來實作，

隔離性保障

一般來講，服務之間的一致性比服務內部的一致性要更加容易榷訓，這也是為什么 XA 等直接在資源層面上實作通用分布式事務的模型會注重一致性的保證，而當上升到服務層面，服務與服務之間已經實作了功能的劃分，邏輯的解耦，也就更容易榷訓一致性，這就是 SOA 架構下 BASE 理論的最終一致性思想

TCC策略其實可以看做服務層面的兩階段提交協議，是否需要保證中間事務的狀態隔離性由具體的業務而定，

Saga 協議

Saga 是一種補償協議，在 Saga 模式下，分布式事務內有多個參與者，每一個參與者都是一個沖正補償服務，需要用戶根據業務場景實作其正向操作和逆向回滾操作，

本質上就是說在一個事物中的多個正向操作里如果有一個正向操作失敗了，則所有操作過的正向操作所對應的逆向操作會執行，

小結

除了以上三種解決方案外還有其他的方案，例如本地訊息表、盡最大努力通知等，可以參考這個文章小米技術團隊，具體的選型結合業務進行判斷，

四、參考文章

1. 再有人問你分布式事務，把這篇扔給他
2. Seata 分布式事務實踐和開源詳解 | GIAC 實錄
3. 分布式事務 Seata 及其三種模式詳解 | Meetup#3 回顧
4. 分布式事務，這一篇就夠了