文章目錄
- 一. 什么是分布式事務？
- 二. 分布式事務的挑戰
- 三. 事務的ACID特性
- 四. CAP理論與BASE理論
- 1. CAP理論
- 1.1. 三大特性
- 1.2. 三者不能兼得
- 2. BASE理論
- 五. 分布式事務解決方案
- 1. 兩階段提交（2PC）
- 2. TCC（Try-Confirm-Cancel）
- 六. 小結
之前我們了解分布式系統中的互斥問題及其解決方案（分布式鎖）。互斥問題討論的是多個進程對同一個臨界資源進行操作的問題，而本文將要討論的是同一個進程對多個臨界資源進行操作的問題。
一. 什么是分布式事務？
簡單來說，分布式事務就是跨多個獨立的資源（比如數據庫）進行的事務。
舉個例子，假設一個銀行系統需要處理一次轉賬操作：從A賬戶轉出100元分別到B賬戶30元、C賬戶70元。這種操作不僅僅涉及到一個數據庫，而是涉及多個資源（A賬戶、B賬戶、C賬戶）。這個轉賬操作要么完全成功，所有的賬戶變動都要完成；要么完全失敗，沒有任何賬戶被修改。類似這樣的跨多個資源的事務，我們稱之為分布式事務。
?
二. 分布式事務的挑戰
在分布式系統中，跨多個服務和數據庫執行的事務面臨以下幾個挑戰：
- 一致性問題：如何保證數據在多個系統中保持一致？
- 網絡故障：網絡不穩定可能導致事務執行失敗，如何保證事務不會中途丟失或被錯誤提交？
- 并發沖突：多個服務之間并發執行的事務如何互不干擾？
為了處理這些挑戰，分布式事務采用了不同的理論和技術框架來確保數據一致性、可用性和事務的正確性。
?
三. 事務的ACID特性
分布式事務的核心目標是保證事務的一致性和完整性，這與單體應用中的ACID特性密切相關。ACID是事務管理的基本要求，包含以下四個特性：
- 原子性（Atomicity）：事務中的所有操作要么全部成功，要么全部失敗，不能部分成功。
- 一致性（Consistency）：事務執行前后的數據一致，系統從一個一致性狀態轉變到另一個一致性狀態。比如：從 A 賬戶轉出 100元，B 賬戶中到賬 30 元，C 賬戶中到賬 70 元。完成這個事務操作以后，A 賬戶減少的錢數與 B、C 賬戶增加的錢數總和應該是一樣的，都是 100 元。
- 隔離性（Isolation）：并發執行的事務互不干擾，每個事務對外界是隔離的。
- 持久性（Durability）：一旦事務提交，數據更改就會永久保存，即使系統崩潰也不丟失。
在單體架構中，ACID特性易于實現，但在分布式系統中，由于網絡延遲、節點故障等問題，保證強一致性變得困難。此時，我們需要更靈活的解決方案。
?
四. CAP理論與BASE理論
1. CAP理論
1.1. 三大特性
在分布式系統中，由于網絡和硬件的限制，無法同時保證一致性、可用性和分區容錯性，這就是著名的CAP理論的核心思想。CAP理論提出，在一個分布式系統中，最多只能保證以下兩個特性：
-
一致性（Consistency）：所有節點的視圖是相同的，保證每個節點的數據在同一時刻一致。
-
可用性（Availability）：可用性是指在分布式系統中，即使一部分節點出現故障，系統仍然可以響應用戶的請求。
- 分區容錯性（Partition tolerance）：假設兩個數據庫節點（每個節點數據一致）分布在兩個區，而這兩個區的通信發生了問題，因此無法達成數據一致，這就是分區問題，此時需要從一致性和可用性之間做出選擇。是選擇一致性（C）?，等待兩個區的數據同步了再去獲取數據，還是選擇可用性（A）?，只獲取其中一個區的數據？
?
1.2. 三者不能兼得
CAP理論表明，當網絡分區發生時，分布式系統必須在一致性和可用性之間做出選擇。如下例子：
業務代碼對兩個節點的通信失敗，往數據庫 01 寫入記錄 A 時，需要鎖住數據庫02 中的記錄 A，不讓其他業務代碼修改此紀錄，直到數據庫 01 修改完成。一致性和可用性在此刻是矛盾的，不能兼得。
| 保證特性 | 放棄特性 | 適用場景 | 說明 |
|---|---|---|---|
| 一致性、可用性 | 分區容錯性 | 不適用（無法實現） | 如果放棄分區容錯性，就等于放棄使用分布式系統，即單體。 |
| 一致性、分區容錯性 | 可用性 | 金融領域（如銀行、支付系統等） | 需要保證數據一致性，甚至在網絡分區時也要犧牲系統可用性，保證交易數據的正確性和一致性。 |
| 可用性、分區容錯性 | 一致性 | ToC端應用（如電商網站、社交平臺等） | 強調用戶體驗，犧牲部分一致性以換取系統高可用性，允許數據暫時不一致。適合大流量和高并發的應用場景。 |
?
2. BASE理論
由于 CAP 理論導致一個應用同時至多只能支持兩個特性，無法三全其美，且高并發系統追求的往往是可用性，因此對 CAP 理論進行進一步擴充，產生了 BASE 理論。
| 特性 | 說明 | 舉例 |
|---|---|---|
| 基本可用性 | 系統能夠在流量激增或節點故障時，通過限流或降級保證用戶請求可用。 | 電商系統在流量激增時，優先保證核心業務（如訂單處理），將非核心業務降級處理。 |
| 軟狀態 | 數據副本之間允許存在短時間的數據不一致，容忍數據同步延遲。 | 數據庫01中記錄A寫入后，數據庫02中的記錄B會在一定延遲后同步，而不是立即同步。 |
| 最終一致性 | 數據在短時間內可能不一致，但過了一段時間后，數據會最終達到一致。 | 在分布式系統中，數據副本可能會在網絡延遲時出現不一致，但經過一段時間，數據會同步一致。 |
BASE理論強調的是最終一致性，而不是傳統數據庫中的強一致性。它適用于那些需要高可用性和容忍短期不一致的系統，例如電商平臺和社交網絡。
?
五. 分布式事務解決方案
為了在分布式系統中保證事務的正確性，業界提出了多種分布式事務解決方案，常見的有兩階段提交（2PC） 和 TCC（Try、Confirm、Cancel）。
1. 兩階段提交（2PC）
**兩階段提交協議（2PC）的基本思想是通過協調者（Transaction Manager）和參與者（Resource Manager）來控制事務的提交或回滾。2PC的工作過程分為兩個階段：
?
準備階段：
事務協調者（事務管理器）詢問每個參與者是否準備好，馬上要執行事務了。事務參與者會根據自身業務和資源情況進行檢查，然后給出反饋。
檢查過程根據業務內容的不同而不同，例如訂票業務需要檢查是否有剩余票、扣款業務需要檢查余額是否足夠。只有檢查通過，才能返回就緒（ready）信息。否則，事務將終止，并且等待下次詢問。由于檢查過程需要完成一些操作，因此需要寫 redo 日志和 undo 日志，以便事務失敗重試，或者失敗回滾時使用。
?
提交階段：
如下圖：如果事務協調者接收到事務參與者檢查失敗或者超時的消息，會給其發送回滾（rollback）消息，否則發送提交（commit）消息。
以下是整理后的兩種情況的處理過程：
| 情況 | 步驟 |
|---|---|
| 情況 1：事務回滾 | 條件：只要有一個事務參與者反饋未就緒（no ready），事務協調者會回滾事務。 |
| 1. 事務協調者向所有事務參與者發出回滾請求。 | |
| 2. 事務參與者使用第一階段的 undo 日志信息執行回滾操作，并釋放事務期間占用的資源。 | |
| 3. 各事務參與者向事務協調者反饋應答（ack）消息，表示完成回滾操作。 | |
| 4. 事務協調者接收到所有事務參與者的應答消息，即完成事務回滾。 | |
| 情況 2：事務提交 | 條件：當所有事務參與者均反饋就緒（ready）消息時，事務協調者會提交事務。 |
| 1. 事務協調者向所有事務參與者發出正式提交事務的請求。 | |
| 2. 事務參與者執行提交（commit）操作，并釋放事務期間占用的資源。 | |
| 3. 各事務參與者向事務協調者反饋應答（ack）消息，表示完成提交操作。 | |
| 4. 事務協調者接收到所有事務參與者的應答（ack）消息，即完成事務提交。 |
盡管2PC簡單易理解，但它存在問題，比如在網絡分區或故障情況下，可能會導致事務掛起，無法繼續提交或回滾，造成數據不一致。
?
2. TCC（Try-Confirm-Cancel）
TCC（Try-Confirm-Cancel）的核心思想是對于每個資源的原子操作，應用程序都需要注冊一個與此操作對應的確認操作和補償（撤銷）操作。其中確認操作負責在原子操作執行成功時進行事務提交，補償操作負責在原子操作執行失敗時對事務進行回滾。
?
TCC協議分為三個階段：
- Try階段：進行資源的預檢查和預留，確保資源可用。
- Confirm階段：負責對業務系統做確認提交。如果 Try 階段執行成功，表明針對資源的操作已經準備就緒，此時執行 Confirm 便會提交對資源的操作。也就是說當資源準備好時，只用提交該操作執行就好了。
- Cancel階段：負責在業務執行錯誤，需要回滾時執行業務取消操作，此時就需要釋放 Try 階段預留的資源了。換句話說，是在資源操作執行失敗的情況下，根據之前預留的資源情況進行回滾。
?
TCC協議通過提供靈活的補償機制，能夠在事務失敗時進行回滾，保證系統的一致性。
例子：
假設有一個轉賬服務，需要把 A 銀行中 A 賬戶的 100 元分別轉到 B 銀行的 B 賬戶和 C 銀行的 C 賬戶，這三個銀行的轉賬服務各不相同，因此這次轉賬服務就形成了一次分布式事務。
| 階段 | 操作描述 | 具體步驟 |
|---|---|---|
| Try 階段 | 檢測資源是否可用，驗證所有參與者的資源可用性，并記錄相關信息。 | 1. 檢查 A 賬戶余額是否大于 100 元。 2.記錄 A 賬戶的總金額、轉出金額。 3. 記錄 B、C 賬戶的總金額、轉入金額。 4. 在數據庫中保存相關字段（如余額、轉出金額）。 5. 如果資源可用，進入 Confirm 階段；如果不可用，回滾。 |
| Confirm 階段 | 執行具體的轉賬邏輯，進行資源更新，并設置事務的成功狀態。 | 1. 從 A 賬戶扣除 100 元，更新余額為 220 - 100 = 120。2. 更新 B 賬戶余額為 50 + 30 = 80，C 賬戶余額為 60 + 70 = 130。3. 更新交易狀態為轉賬成功。 4. 向所有參與者發出確認提交請求，確認各方操作。 |
| Cancel 階段 | 回滾操作，恢復資源到原始狀態。 | 1. 如果 Try 階段失敗或資源無法提供，回滾所有操作。 2. A 賬戶恢復扣除的 100 元，余額為 120 + 100 = 220。 3. B 賬戶和 C 賬戶分別恢復相應的金額，B 賬戶恢復為 80 - 30 = 50，C 賬戶恢復為 130 - 70 = 60。 4. 事務回滾并釋放占用的資源。 |
?
六. 小結
分布式事務的出現帶來了很多挑戰，但也推動了事務管理理論和實踐的不斷發展。從ACID特性到CAP理論、BASE理論，再到DTP、2PC和TCC等分布式事務協議，每一種理論和方案都在不同的應用場景中發揮著重要作用。
在實際開發中，選擇哪種分布式事務方案應根據業務需求、系統架構、性能要求等因素來決定。對于高一致性要求的金融類系統，2PC可能更合適；而對于電商類高并發系統，TCC和BASE理論的結合則能提供更高的可用性和靈活性。
