分散式事務

分散式事務理論CAP（強一致性）

• CAP 定理，又被叫作布魯爾定理。對於共享資料系統，最多隻能同時擁有CAP其中的兩個，任意兩個都有其適應的場景。

• BASE（最終一致性）BASE 是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）。它的核心思想是即使無法做到強一致性（CAP 就是強一致性），但應用可以採用適合的方式達到最終一致性。

  • BA指的是基本業務可用性，支援分割槽失敗；
  • S表示柔性狀態，也就是允許短時間內不同步；
  • E表示最終一致性，資料最終是一致的，但是實時是不一致的。

  原子性和永續性必須從根本上保障，為了可用性、效能和服務降級的需要，只有降低一致性和隔離性的要求。BASE 解決了 CAP 理論中沒有考慮到的網路延遲問題，在BASE中用軟狀態和最終一致，保證了延遲後的一致性。

分散式事務模式

瞭解了分散式事務中的強一致性和最終一致性理論，下面介紹幾種常見的分散式事務的解決方案。

2PC模式（強一致性）

2PC是Two-Phase Commit縮寫，即兩階段提交，就是將事務的提交過程分為兩個階段來進行處理。事務的發起者稱協調者，事務的執行者稱參與者。協調者統一協調參與者執行。

• 階段 1：準備階段

  協調者向所有參與者傳送事務內容，詢問是否可以提交事務，並等待所有參與者答覆。各參與者執行事務操作，但不提交事務，將 undo 和 redo 資訊記入事務日誌中。如參與者執行成功，給協調者反饋 yes；如執行失敗，給協調者反饋 no。

• 階段 2：提交階段

  如果協調者收到了參與者的失敗訊息或者超時，直接給每個參與者傳送回滾(rollback)訊息；否則，傳送提交(commit)訊息。

2PC 方案實現起來簡單，實際專案中使用比較少，主要因為以下問題：

1. 效能問題：所有參與者在事務提交階段處於同步阻塞狀態，佔用系統資源，容易導致效能瓶頸。
2. 可靠性問題：如果協調者存在單點故障問題，如果協調者出現故障，參與者將一直處於鎖定狀態。
3. 資料一致性問題：在階段 2 中，如果發生區域性網路問題，一部分事務參與者收到了提交訊息，另一部分事務參與者沒收到提交訊息，那麼就導致了節點之間資料的不一致。

3PC模式（強一致性）

3PC 三階段提交，是兩階段提交的改進版本，與兩階段提交不同的是，引入超時機制。同時在協調者和參與者中都引入超時機制。三階段提交將兩階段的準備階段拆分為 2 個階段，插入了一個preCommit 階段，解決了原先在兩階段提交中，參與者在準備之後，由於協調者或參與者發生崩潰或錯誤，而導致參與者無法知曉處於長時間等待的問題。如果在指定的時間內協調者沒有收到參與者的訊息則預設失敗。

• 階段1：canCommit

  協調者向參與者傳送 commit 請求，參與者如果可以提交就返回 yes 響應，否則返回 no 響應。

• 階段2：preCommit

  協調者根據階段 1 canCommit 參與者的反應情況執行預提交事務或中斷事務操作。

  1. 參與者均反饋 yes：協調者向所有參與者發出 preCommit 請求，參與者收到preCommit 請求後，執行事務操作，但不提交；將 undo 和 redo 資訊記入事務日誌中；各參與者向協調者反饋 ack 響應或 no 響應，並等待最終指令。
  2. 任何一個參與者反饋 no或等待超時：協調者向所有參與者發出 abort 請求，無論收到協調者發出的 abort 請求，或者在等待協調者請求過程中出現超時，參與者均會中斷事務。

• 階段3：do Commit

  該階段進行真正的事務提交，根據階段 2 preCommit反饋的結果完成事務提交或中斷操作。

相比2PC模式，3PC模式降低了阻塞範圍，在等待超時後協調者或參與者會中斷事務。避免了協調者單點問題，階段 3 中協調者出現問題時（比如網路中斷等），參與者會繼續提交事務。

XA（強一致性）

XA是由X/Open組織提出的分散式事務的規範，是基於兩階段提交協議。 XA規範主要定義了全域性事務管理器（TM）和區域性資源管理器（RM）之間的介面。目前主流的關係型資料庫產品都是實現了XA介面。

XA之所以需要引入事務管理器，是因為在分散式系統中，從理論上講兩臺機器理論上無法達到一致的狀態，需要引入一個單點進行協調。由全域性事務管理器管理和協調的事務，可以跨越多個資源（資料庫）和程序。事務管理器用來保證所有的事務參與者都完成了準備工作(第一階段)。如果事務管理器收到所有參與者都準備好的訊息，就會通知所有的事務都可以提交了（第二階段）。MySQL 在這個XA事務中扮演的是參與者的角色，而不是事務管理器。

TCC模式（最終一致性）

TCC（Try-Confifirm-Cancel）的概念，最早是由 Pat Helland 於 2007 年發表的一篇名為《Lifebeyond Distributed Transactions:an Apostate’s Opinion》的論文提出。TCC 是服務化的兩階段程式設計模型，其 Try、Confifirm、Cancel 3 個方法均由業務編碼實現：

1. Try 操作作為一階段，負責資源的檢查和預留；
2. Confifirm 操作作為二階段提交操作，執行真正的業務；
3. Cancel 是預留資源的取消；

TCC事務模式相對於 XA 等傳統模型如下圖所示：

TCC 模式相比於 XA，解決了如下幾個缺點：

• 解決了協調者單點，由主業務方發起並完成這個業務活動。業務活動管理器可以變成多點，引入叢集。
• 同步阻塞：引入超時機制，超時後進行補償，並且不會鎖定整個資源，將資源轉換為業務邏輯形式，粒度變小。
• 資料一致性，有了補償機制之後，由業務活動管理器控制一致性。

訊息佇列模式（最終一致性）

訊息佇列的方案最初是由 eBay 提出，基於TCC模式，訊息中介軟體可以基於 Kafka、RocketMQ 等訊息佇列。此方案的核心是將分散式事務拆分成本地事務進行處理，將需要分散式處理的任務通過訊息日誌的方式來非同步執行。訊息日誌可以儲存到本地文字、資料庫或MQ中介軟體，再通過業務規則人工發起重試。

下面描述下事務的處理流程：

• 步驟1：事務主動方處理本地事務。事務主動方在本地事務中處理業務更新操作和MQ寫訊息操作。
• 步驟 2：事務主動方通過訊息中介軟體，通知事務被動方處理事務通知事務待訊息。事務主動方主動寫訊息到MQ，事務消費方接收並處理MQ中的訊息。
• 步驟 3：事務被動方通過MQ中介軟體，通知事務主動方事務已處理的訊息，事務主動方根據反饋結果提交或回滾事務。

為了資料的一致性，當流程中遇到錯誤需要重試，容錯處理規則如下：

• 當步驟 1 處理出錯，事務回滾，相當於什麼都沒發生。
• 當步驟 2 處理出錯，由於未處理的事務訊息還是儲存在事務傳送方，可以重試或撤銷本地業務操作。
• 如果事務被動方消費訊息異常，需要不斷重試，業務處理邏輯需要保證冪等。
• 如果是事務被動方業務上的處理失敗，可以通過MQ通知事務主動方進行補償或者事務回滾。
• 如果多個事務被動方已經消費訊息，事務主動方需要回滾事務時需要通知事務被動方回滾。

Saga模式（最終一致性）

Saga這個概念源於 1987 年普林斯頓大學的 Hecto 和 Kenneth 發表的一篇資料庫論文Sagas ，一個Saga事務是一個有多個短時事務組成的長時的事務。 在分散式事務場景下，我們把一個Saga分散式事務看做是一個由多個本地事務組成的事務，每個本地事務都有一個與之對應的補償事務。在Saga事務的執行過程中，如果某一步執行出現異常，Saga事務會被終止，同時會呼叫對應的補償事務完成相關的恢復操作，這樣保證Saga相關的本地事務要麼都是執行成功，要麼通過補償恢復成為事務執行之前的狀態。（自動反向補償機制）。

Saga 事務基本協議如下：

• 每個 Saga 事務由一系列冪等的有序子事務(sub-transaction) Ti 組成。

• 每個 Ti 都有對應的冪等補償動作 Ci，補償動作用於撤銷 Ti 造成的結果。

Saga是一種補償模式，它定義了兩種補償策略：

1. 向前恢復（forward recovery）：對應於上面第一種執行順序，發生失敗進行重試，適用於必須要成功的場景。
2. 向後恢復（backward recovery）：對應於上面提到的第二種執行順序，發生錯誤後撤銷掉之前所有成功的子事務，使得整個 Saga 的執行結果撤銷。

Saga 的執行順序有兩種，如上圖：

1. 事務正常執行完成：T1, T2, T3, ..., Tn，例如：減庫存(T1)，建立訂單(T2)，支付(T3)，依次有序完成整個事務。
2. 事務回滾：T1, T2, ..., Tj, Cj,..., C2, C1，其中 0 < j < n，例如：減庫存(T1)，建立訂單(T2)，支付(T3)，支付失敗，支付回滾(C3)，訂單回滾(C2)，恢復庫存(C1)。

Seata框架

Fescar開源專案，最初願景是能像本地事務一樣控制分散式事務，解決分散式環境下的難題。

Seata（Simple Extensible Autonomous Transaction Architecture）是一套一站式分散式事務解決方案，是阿里集團和螞蟻金服聯合打造的分散式事務框架。Seata目前的事務模式有AT、TCC、Saga和XA，預設是AT模式，AT本質上是2PC協議的一種實現。

Seata AT事務模型包含TM(事務管理器)，RM(資源管理器)，TC(事務協調器)。其中TC是一個獨立的服務需要單獨部署，TM和RM以jar包的方式同業務應用部署在一起，它們同TC建立長連線，在整個事務生命週期內，保持RPC通訊。

• 全域性事務的發起方作為TM，全域性事務的參與者作為RM

• TM負責全域性事務的begin和commit/rollback

• RM負責分支事務的執行結果上報，並且通過TC的協調進行commit/rollback。

在 Seata 中，AT時分為兩個階段的，第一階段，就是各個階段本地提交操作；第二階段會根據第一階段的情況決定是進行全域性提交還是全域性回滾操作。具體的執行流程如下：

• TM 開啟分散式事務，負責全域性事務的begin和commit/rollback（TM 向 TC 註冊全域性事務記錄）；

• RM 作為參與者，負責分支事務的執行結果上報，並且通過TC的協調進行commit/rollback（RM 向 TC 彙報資源準備狀態 ）；

• RM分支事務結束，事務一階段結束;

• 根據TC 彙總事務資訊，由TM發起事務提交或回滾操作；

• TC 通知所有 RM 提交/回滾資源，事務二階段結束；