聊聊分散式事務
這次使用分散式事務框架過程中了學習了一些分散式事務知識，所以本文我們就來聊聊分散式事務那些事。首先我們先回顧下什麼是事務。
事務
什麼是事務？這個作為後端開發，日常開發中只要與資料庫有互動，肯定就會使用過事務。現在摘抄一段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 分散式事務。
2PC 兩階段提交協議
如名字所知，這個過程主要分為兩步。
第一階段，協調者(事務管理器)將涉及到事務的進行預提交，這個時候資料庫資源開始被 鎖定 。參與者將 undo 與 redo 寫入事務日誌。
第二階段，參與者（資源管理器）行提交事務，或者利用 undo 日誌回滾事務，釋放資源。
整個過程如下圖。
分散式事務提交成功場景：
分散式事務回滾場景：
該方案的優點為:實現比較簡單，主流資料庫都支援，強一致性。MySQL 5.5 以後基於 XA 協議實現.
相應該方案也存在缺點:
- 協調者的單點問題。若協調者在提交階段宕機，參與者一直在等待,就一直鎖定資源，一直阻塞。雖然可以重新選舉協調者，但是無法解決該問題。
- 同步阻塞時間過長，整個執行過程事務是阻塞的，直到提交完成，釋放資源，若在提交過程/回滾過程，因為網路延時，參與者一直未收到指令，則參與者一直被阻塞。
- 資料不一致。第二階段，協調者發出第一個提交訊號後後宕機，則第一個參與者提交事務，第二個參與者因為未收到協調者訊號，無法進行事務提交。
於是針對 2PC 存在的缺點，提出改進方案，3PC。
3PC 三階段提交協議
三階段提交，在兩階段提交的基礎下，改進兩階段。三階段步驟如下。
- CanCommit,協調者詢問參與者是否可以進行事務提交。
- PreCommit ,若所有參與者可以進行事務提交，協調者下達 PreCommit 命令，參與者鎖定資源，並等待最終命令。
- 所有參與者返回確認資訊，協調者向各個事務下發事務執行通知，鎖定資源，並將執行情況返回。
- 部分參與者返回否認資訊或協調者等待超時。這種情況，協調者認為事務無法正常執行，下發中斷指令，各個參與者退出預備狀態
- Do Commit，若第二階段全部迴應 ack，則下達 Do Commit ，進行事務最終提交，否則下達中斷事務命令，所有參與者進行事務回滾。
- 所有參與者正常執行執行事務，協調者下發最終提交指令，釋放鎖定資源。
- 部分參與者執行事務失敗，協調者等待超時，協調者下發回滾指令，釋放鎖定資源。
具體見下圖。
三階段提交對比兩階段，引入超時機制減少事務阻塞，解決單點故障。在第三階段，一旦參與者無法接受到協調者訊號時，等待超時之後，參與者預設執行 commit，釋放資源。
三階段任然不能解決資料一致性問題。若協調者發出回滾命令，但是由於網路問題，參與者在等待時間內都無法接收到，這時參與者預設提交事務，而其他事務進行了回滾，造成事務不一致。
TCC
TCC 事務
為了解決在事務執行過程中大顆粒度資源鎖定的問題，業界提出一種新的事務模型，它是基於 業務層面 的事務定義。鎖粒度完全由業務自己控制。它本質是一種 補償 的思路。它把事務執行過程分成 Try、Confirm / Cancel 兩個階段。在每個階段的邏輯由 業務程式碼 控制。這樣就事務的鎖粒度可以完全自由控制。業務可以在犧牲隔離性的情況下，獲取更高的效能。
TCC 分別為 Trying，Confirm，Cancel 三個單詞縮寫。不同於 2PC 與 3PC 基於資料庫層面，TCC 基於應用層面。
TCC 三個動作分別為：
Trying：
- 完成所有業務檢查(一致性)
- 預留必須業務資源(準隔離性)
Confirm:
- 真正執行業務
- Confirm操作要滿足冪等性
Cancel:
- 釋放Try階段預留的業務資源
- Cancel操作要滿足冪等性
上面說法，一聽起來有點生澀難懂，沒關係我們使用實際案例解釋。
下面我們模擬商城一次支付過程。使用者下單使用組合支付，即餘額加紅包支付。一次正常流程為：
- 建立訂單
- 下單
- 呼叫餘額系統，扣減餘額
- 呼叫紅包系統，扣減紅包餘額
- 修改訂單狀態為已支付
- 完後支付。
實際過程如下圖。
但是這麼一個支付過程呼叫多個子服務，我們不能保證所有服務都能成功，比如我們在呼叫紅包系統扣減紅包系統失敗。這個時候我們就碰到尷尬的場景，由於紅包服務失敗，導致方法異常退出，這個時候訂單狀態為初始狀態，但是使用者餘額已經扣減。這對使用者體驗非常不友好。所以這次支付過程，我們必須存在機制將這次過程當成一次整體的行為，必須保證這其中服務呼叫，要麼都成功，要麼都失敗，成為一個整體的事務。
這時我們可以引入 TCC 事務，將整個下單過程作為一個整體。引入後，由於餘額系統扣減是失敗，這個時候我們回滾訂單系統與紅包系統。整個過程如下圖。
由於餘額系統的失敗，我們需要撤銷這次過程中所有更改，所以我們向訂單系統傳送撤銷通知，向紅包系統發出撤銷通知。
因此係統引入 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 效能較高，可以保證資料最終一致性。但是對於應用層來說，一個方法必須改造成三個方法，且業務中需引入一些中間狀態，相對而言應用改造程度較大。
參考資料
ofollow,noindex" target="_blank">分散式事務：兩階段提交與三階段提交