[[374631]]

本文轉載自微信公眾號「小黑十一點半」，作者樓下小黑哥。轉載本文請聯(lián)系小黑十一點半公眾號。  

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

事務

什么是事務?這個作為后端開發(fā)，日常開發(fā)中只要與數(shù)據(jù)庫有交互，肯定就會使用過事務。現(xiàn)在摘抄一段wiki的解釋，解釋下什么是事務。

是數(shù)據(jù)庫管理系統(tǒng)執(zhí)行過程中的一個邏輯單位，由一個有限的數(shù)據(jù)庫操作序列構成

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

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

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

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

C(Consistenc):一致性。數(shù)據(jù)庫的狀態(tài)從一種狀態(tài)轉變?yōu)榱硗庖环N狀態(tài)，事務開始之前和是事務結束之后，數(shù)據(jù)庫完整性約束不變。什么叫數(shù)據(jù)庫完整性約束不變?舉個例子，若一個表姓名字段為唯一約束，若在事務提交或回滾后，姓名字段變成非唯一了，這就破壞數(shù)據(jù)庫的完整性約束。

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

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

因此早期我們的系統(tǒng)只在存在一個數(shù)據(jù)源情況下，這個時候可以依靠數(shù)據(jù)庫系統(tǒng)事務來保證業(yè)務的正確性。

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

 

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

還有一種情況，隨著系統(tǒng)越來越龐大，我們會選擇將系統(tǒng)應用拆分多個微服務，讓單個應用只操作一個數(shù)據(jù)源。這個時候我們就會碰到，一次業(yè)務調(diào)用，將會調(diào)用多個應用，每個應用單獨操作數(shù)據(jù)源的情況，如下圖。

 

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

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

分布式事務

摘抄一段 wiki 上解釋。

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

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

分布式事務技術理論

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

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

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

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

Basically Available(基本可用)：分布式系統(tǒng)在出現(xiàn)故障時，允許損失部分可用功能，保證核心功能可用。

Soft state(軟狀態(tài))：允許系統(tǒng)中存在中間狀態(tài)，這個狀態(tài)不影響系統(tǒng)可用性，這里指的是CAP中的不一致。

Eventually consistent(最終一致性)：最終一致是指經(jīng)過一段時間后，所有節(jié)點數(shù)據(jù)都將會達到一致。

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

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

分布式事務實現(xiàn)方案

基于數(shù)據(jù)庫資源層面

• 2PC 兩階段提交協(xié)議
• 3PC 三階段提交協(xié)議

基于業(yè)務層面

• TCC

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

2PC 兩階段提交協(xié)議

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

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

整個過程如下圖。

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

 

分布式事務回滾場景：

 

該方案的優(yōu)點為:實現(xiàn)比較簡單，主流數(shù)據(jù)庫都支持，強一致性。MySQL 5.5 以后基于 XA 協(xié)議實現(xiàn).

相應該方案也存在缺點:

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

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

數(shù)據(jù)不一致。第二階段，協(xié)調(diào)者發(fā)出第一個提交信號后后宕機，則第一個參與者提交事務，第二個參與者因為未收到協(xié)調(diào)者信號，無法進行事務提交。

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

3PC 三階段提交協(xié)議

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

1..CanCommit,協(xié)調(diào)者詢問參與者是否可以進行事務提交。

2.PreCommit ,若所有參與者可以進行事務提交，協(xié)調(diào)者下達 PreCommit 命令，參與者鎖定資源，并等待最終命令。

• 所有參與者返回確認信息，協(xié)調(diào)者向各個事務下發(fā)事務執(zhí)行通知，鎖定資源，并將執(zhí)行情況返回。
• 部分參與者返回否認信息或協(xié)調(diào)者等待超時。這種情況，協(xié)調(diào)者認為事務無法正常執(zhí)行，下發(fā)中斷指令，各個參與者退出預備狀態(tài)

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

所有參與者正常執(zhí)行執(zhí)行事務，協(xié)調(diào)者下發(fā)最終提交指令，釋放鎖定資源。

部分參與者執(zhí)行事務失敗，協(xié)調(diào)者等待超時，協(xié)調(diào)者下發(fā)回滾指令，釋放鎖定資源。

具體見下圖。

 

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

三階段任然不能解決數(shù)據(jù)一致性問題。若協(xié)調(diào)者發(fā)出回滾命令，但是由于網(wǎng)絡問題，參與者在等待時間內(nèi)都無法接收到，這時參與者默認提交事務，而其他事務進行了回滾，造成事務不一致。

TCC

TCC 事務

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

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

Trying：

• 完成所有業(yè)務檢查(一致性)
• 預留必須業(yè)務資源(準隔離性)

Confirm:

• 真正執(zhí)行業(yè)務
• Confirm操作要滿足冪等性

Cancel:

• 釋放Try階段預留的業(yè)務資源
• Cancel操作要滿足冪等性

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

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

1. 創(chuàng)建訂單
2. 下單

• 調(diào)用余額系統(tǒng)，扣減余額
• 調(diào)用紅包系統(tǒng)，扣減紅包余額
• 修改訂單狀態(tài)為已支付
• 完后支付。
• 實際過程如下圖。

 

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

 

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

 

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

因此系統(tǒng)引入 TCC 事務后，我們需要改造我們的調(diào)用過程。

系統(tǒng)如何引入 TCC 事務

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

TCC TRY:

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

 

 

TCC Confirm:

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

 

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

TCC Cancle：

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

 

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

總結與思考

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

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

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

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

使用 2PC 或 3PC 實現(xiàn)的分布式框架，業(yè)務應用層無需改動，接入較簡單。但是相對應能較低，數(shù)據(jù)資源鎖定較長。不太適合互聯(lián)網(wǎng)等高并發(fā)業(yè)務場景。

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