摘要：分布式事務技術理論定理。接下來我們看看分布式事務有哪幾種實現方案。基于協調者與參與者的思想設定，分別提出了與實現分布式事務。

這次使用分布式事務框架過程中了學習了一些分布式事務知識，所以本文我們就來聊聊分布式事務那些事。首先我們先回顧下什么是事務。

什么是事務？這個作為后端開發，日常開發中只要與數據庫有交互，肯定就會使用過事務。現在摘抄一段wiki的解釋，解釋下什么是事務。

是數據庫管理系統執行過程中的一個邏輯單位，由一個有限的數據庫操作序列構成

數據庫系統具有事務特性，這是其有別與文件系統重要特性。傳統的文件系統，如果正在寫文件，操作系統突然崩潰，此時文件可能被破壞。數據庫系統引入事務特性，可以保證數據庫從一種狀態轉換為另一種狀態。在提交工作時,可以確保要么所有修改都被保存，要么所有都不保存。

通常一個事務會有多個讀寫操作構成。

事務具有四個基本特性，俗稱ACID。

A(Atomicity):原子性。事務會被當做一個整體，要么所有語句都成功，要么都失敗，不能存在部分語句成功，部分失敗的情況。

C(Consistenc):一致性。數據庫的狀態從一種狀態轉變為另外一種狀態，事務開始之前和是事務結束之后，數據庫完整性約束不變。什么叫數據庫完整性約束不變？舉個例子，若一個表姓名字段為唯一約束，若在事務提交或回滾后，姓名字段變成非唯一了，這就破壞數據庫的完整性約束。

I(Isolation):隔離性。多個并發事務執行，互不影響。

D(Durability):持久性。事務提交之后，其對數據庫相關修改能永久保存在數據庫。所以該特性需要數據庫系統可以在崩潰時需要恢復時也能提交的數據都不丟失。

因此早期我們的系統只在存在一個數據源情況下，這個時候可以依靠數據庫系統事務來保證業務的正確性。

但是隨著業務的不斷擴展，我們業務的一個單表可能就存在千萬數據，在使用再使用一個數據庫實例，就會可能存在性相關能問題。這個時候我們就會考慮分庫分表。但是這樣就有可能導致，單個應用連接多個數據源的情況。如下圖示例。

上圖一次購買過程，商家余額表與用戶余額表處于兩個多帶帶的數據庫實例中，這樣多帶帶的事務能保證扣減商家余額或用戶余額要么扣減成功，要么扣減失敗。但是我們卻無法保證兩個事務同時成功或同時失敗。

還有一種情況，隨著系統越來越龐大，我們會選擇將系統應用拆分多個微服務，讓單個應用只操作一個數據源。這個時候我們就會碰到，一次業務調用，將會調用多個應用，每個應用多帶帶操作數據源的情況，如下圖。

這種情況下我們更加不能保證所有調用都成功。

由上面的例子下我們可以看出，隨著業務發展，傳統的單機事務已經無法滿足我們的業務的需求，這個時候我們就需要分布式事務來保證。

摘抄一段 wiki 上解釋。

A distributed transaction is a database transaction in which two or more network hosts are involved.

我們先來講下實現分布式事務一些理論基礎。

CAP 定理。在一個分布式系統（指互相連接并共享數據的節點的集合）中，當涉及讀寫操作時，只能保證一致性（Consistence）、可用性（Availability）、分區容錯性（Partition Tolerance）三者中的兩個，另外一個必須被犧牲。

摘錄極客時間從0開始學架構第22章解釋

雖然 CAP 理論定義是三個要素中只能取兩個，但放到分布式環境下來思考，我們會發現必須選擇 P（分區容忍）要素，因為網絡本身無法做到 100% 可靠，有可能出故障，所以分區是一個必然的現象。如果我們選擇了 CA 而放棄了 P，那么當發生分區現象時，為了保證 C，系統需要禁止寫入，當有寫入請求時，系統返回 error（例如，當前系統不允許寫入），這又和 A 沖突了，因為 A 要求返回 no error 和 no timeout。因此，分布式系統理論上不可能選擇 CA 架構，只能選擇 CP 或者 AP 架構

BASE 理論，分別是以下三個單詞的縮寫。

Basically Available（基本可用）：分布式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。

Soft state（軟狀態）：允許系統中存在中間狀態，這個狀態不影響系統可用性，這里指的是CAP中的不一致。

Eventually consistent（最終一致性）：最終一致是指經過一段時間后，所有節點數據都將會達到一致。

BASE 是對CAP 中 AP 方案的一種補充。在 BASE 中用軟狀態和最終一致，保證了延遲后的一致性。BASE 和 ACID 是相反的，ACID 是一種強一致性模型，而 BASE 卻是犧牲這種強一致性，允許數據短時間內不一致，最終一致性。

接下來我們看看分布式事務有哪幾種實現方案。

基于數據庫資源層面

2PC 兩階段提交協議

3PC 三階段提交協議

基于業務層面

TCC

基于數據庫資源層面實現方案，由于存在多個事務，我們需要存在一個角色管理各個事務的狀態。我們將這個角色稱為協調者，事務參與者稱為參與者。參與者與協調者一般會基于某種特定協議，目前比較有名的為 XA 接口協議。基于協調者與參與者的思想設定，分別提出了 2PC 與 3PC 實現XA 分布式事務。

如名字所知，這個過程主要分為兩步。

第一階段，協調者(事務管理器)將涉及到事務的進行預提交，這個時候數據庫資源開始被鎖定。參與者將 undo 與 redo 寫入事務日志。
第二階段，參與者（資源管理器）行提交事務，或者利用 undo 日志回滾事務，釋放資源。

整個過程如下圖。

分布式事務提交成功場景：

分布式事務回滾場景：

該方案的優點為:實現比較簡單，主流數據庫都支持，強一致性。MySQL 5.5 以后基于 XA 協議實現.

相應該方案也存在缺點:

協調者的單點問題。若協調者在提交階段宕機，參與者一直在等待,就一直鎖定資源，一直阻塞。雖然可以重新選舉協調者，但是無法解決該問題。

同步阻塞時間過長，整個執行過程事務是阻塞的，直到提交完成，釋放資源，若在提交過程/回滾過程，因為網絡延時，參與者一直未收到指令，則參與者一直被阻塞。

數據不一致。第二階段，協調者發出第一個提交信號后后宕機，則第一個參與者提交事務，第二個參與者因為未收到協調者信號，無法進行事務提交。

于是針對 2PC 存在的缺點，提出改進方案，3PC。

三階段提交，在兩階段提交的基礎下，改進兩階段。三階段步驟如下。

CanCommit,協調者詢問參與者是否可以進行事務提交。

PreCommit ,若所有參與者可以進行事務提交，協調者下達 PreCommit 命令，參與者鎖定資源，并等待最終命令。

所有參與者返回確認信息，協調者向各個事務下發事務執行通知，鎖定資源，并將執行情況返回。

部分參與者返回否認信息或協調者等待超時。這種情況，協調者認為事務無法正常執行，下發中斷指令，各個參與者退出預備狀態

Do Commit，若第二階段全部回應 ack，則下達 Do Commit ，進行事務最終提交，否則下達中斷事務命令，所有參與者進行事務回滾。

所有參與者正常執行執行事務，協調者下發最終提交指令，釋放鎖定資源。

部分參與者執行事務失敗，協調者等待超時，協調者下發回滾指令，釋放鎖定資源。

具體見下圖。

三階段提交對比兩階段，引入超時機制減少事務阻塞，解決單點故障。在第三階段，一旦參與者無法接受到協調者信號時，等待超時之后，參與者默認執行 commit，釋放資源。

三階段任然不能解決數據一致性問題。若協調者發出回滾命令，但是由于網絡問題，參與者在等待時間內都無法接收到，這時參與者默認提交事務，而其他事務進行了回滾，造成事務不一致。

TCC 事務

為了解決在事務運行過程中大顆粒度資源鎖定的問題，業界提出一種新的事務模型，它是基于業務層面的事務定義。鎖粒度完全由業務自己控制。它本質是一種補償的思路。它把事務運行過程分成 Try、Confirm / Cancel 兩個階段。在每個階段的邏輯由業務代碼控制。這樣就事務的鎖粒度可以完全自由控制。業務可以在犧牲隔離性的情況下，獲取更高的性能。

TCC 分別為 Trying，Confirm，Cancel 三個單詞縮寫。不同于 2PC 與 3PC 基于數據庫層面，TCC 基于應用層面。
TCC 三個動作分別為：

Trying：

完成所有業務檢查(一致性)

預留必須業務資源(準隔離性)

Confirm:

真正執行業務

Confirm操作要滿足冪等性

Cancel:

釋放Try階段預留的業務資源

Cancel操作要滿足冪等性

上面說法，一聽起來有點生澀難懂，沒關系我們使用實際案例解釋。

下面我們模擬商城一次支付過程。用戶下單使用組合支付，即余額加紅包支付。一次正常流程為：

創建訂單

下單

調用余額系統，扣減余額

調用紅包系統，扣減紅包余額

修改訂單狀態為已支付

完后支付。

實際過程如下圖。

但是這么一個支付過程調用多個子服務，我們不能保證所有服務都能成功，比如我們在調用紅包系統扣減紅包系統失敗。這個時候我們就碰到尷尬的場景，由于紅包服務失敗，導致方法異常退出，這個時候訂單狀態為初始狀態，但是用戶余額已經扣減。這對用戶體驗非常不友好。所以這次支付過程，我們必須存在機制將這次過程當成一次整體的行為，必須保證這其中服務調用，要么都成功，要么都失敗，成為一個整體的事務。

這時我們可以引入 TCC 事務，將整個下單過程作為一個整體。引入后，由于余額系統扣減是失敗，這個時候我們回滾訂單系統與紅包系統。整個過程如下圖。

由于余額系統的失敗，我們需要撤銷這次過程中所有更改，所以我們向訂單系統發送撤銷通知，向紅包系統發出撤銷通知。

因此系統引入 TCC 事務后，我們需要改造我們的調用過程。

根據 TCC 事務三步，這個時候我們必須將各個服務改造成 Try Confirm Cancle 三步、

TCC TRY:

根據上面的業務，訂單系統增加 try 方法將訂單狀態修改成 PAYING。余額系統增加一個 try 方法，先檢查用于余額是否充足，然后先將余額扣減，然后將扣減的余額增加到凍結金額。紅包系統同余額系統。從改造過程可以看出，TCC try 方法需檢查各業務資源，且這過程需要引入中間狀態。我們根據下圖來看整個過程。

TCC Confirm:

TCC 第一步 TRY 如果所有子服務調用都成功，這個時候我們就需要確認各服務。各個服務增加 confirm 方法。如余額系統 confirm 方法用來將凍結金額置為0，紅包系統如上。訂單系統將訂單狀態修改為 SUCCESS。confirm 方法需要注意實現冪等。如訂單系統更新前，一定要先判斷該筆訂單狀態處于 PAYING，才能更新訂單。整個過程如下圖。

講到這里，必須用到 TCC 事務框架推動各服務。TCC 事務管理器感知到 TRY 方法結束后，自動調用各服務提供的 confirm 方法，將各服務狀態修改為終態。

TCC Cancle：

如若 TCC Try 過程中，凍結紅包方法失敗，這時我們就需要將之前修改都撤銷，修改成其初始狀態。cancle 方法也需要實現冪等如 confirm 方法 如下圖：

看到這，我們我們可以看出 TCC Try 成功，confirm 必定要成功，try 失敗，cancle 必定要成功。因為 confirm 是系統更新為終態的關鍵。但是現實這么無情，生產系統 confirm 或 cancle 肯定會有幾率失敗，這個時候就需要 TCC 框架記錄調用 confirm 結果。如果 confirm 調用失敗，TCC 框架需要記錄下來，然后間隔一定時間再次去調用。

看完全文，基本上對分布式事務又一定了解了吧。

我們基于此對此總結下。使用分布式事務，我們需要結合我們實際場景應用。

如果業務還處于開始階段，我們其實可以選擇數據庫事務來保證快速上線迭代。

等到業務一定階段，系統開始拆分，數據庫也拆分，這時如果業務需要保證一致性，這時必須使用分布式事務。這時候使用分布式事務，我們需要基于業務考慮使用哪種。

使用 2PC 或 3PC 實現的分布式框架，業務應用層無需改動，接入較簡單。但是相對應能較低，數據資源鎖定較長。不太適合互聯網等高并發業務場景。

而使用基于 TCC 實現分布式框架，相對 2PC 性能較高，可以保證數據最終一致性。但是對于應用層來說，一個方法必須改造成三個方法，且業務中需引入一些中間狀態，相對而言應用改造程度較大。

分布式事務：兩階段提交與三階段提交

關于分布式事務、兩階段提交協議、三階提交協議

拜托，面試請不要再問我TCC分布式事務的實現原理！

2PC和3PC一點理解

如果覺得好的話，請幫作者點個贊唄~ 謝謝