數(shù)據(jù)庫中分布式事務(wù)是什么

這篇文章給大家分享的是有關(guān)數(shù)據(jù)庫中分布式事務(wù)是什么的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

事務(wù)

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

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

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

通常一個事務(wù)會有多個讀寫操作構(gòu)成。

事務(wù)具有四個基本特性，俗稱ACID。

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

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

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

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

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

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

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

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

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

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

分布式事務(wù)

摘抄一段 wiki 上解釋。

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

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

分布式事務(wù)技術(shù)理論

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

摘錄極客時間從0開始學(xué)架構(gòu)第22章解釋

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

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ù)都將會達(dá)到一致。

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

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

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

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

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

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

2. 基于業(yè)務(wù)層面

• TCC

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

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

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

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

整個過程如下圖。

分布式事務(wù)提交成功場景：

分布式事務(wù)回滾場景：

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

相應(yīng)該方案也存在缺點:

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

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

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

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

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

三階段提交，在兩階段提交的基礎(chǔ)下，改進(jìn)兩階段。三階段步驟如下。

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

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

• 所有參與者返回確認(rèn)信息，協(xié)調(diào)者向各個事務(wù)下發(fā)事務(wù)執(zhí)行通知，鎖定資源，并將執(zhí)行情況返回。

• 部分參與者返回否認(rèn)信息或協(xié)調(diào)者等待超時。這種情況，協(xié)調(diào)者認(rèn)為事務(wù)無法正常執(zhí)行，下發(fā)中斷指令，各個參與者退出預(yù)備狀態(tài)

3. Do Commit，若第二階段全部回應(yīng) ack，則下達(dá) Do Commit ，進(jìn)行事務(wù)最終提交，否則下達(dá)中斷事務(wù)命令，所有參與者進(jìn)行事務(wù)回滾。

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

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

具體見下圖。

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

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

TCC

TCC 事務(wù)

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

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

Trying：

• 完成所有業(yè)務(wù)檢查(一致性)

• 預(yù)留必須業(yè)務(wù)資源(準(zhǔn)隔離性)

Confirm:

• 真正執(zhí)行業(yè)務(wù)

• Confirm操作要滿足冪等性

Cancel:

• 釋放Try階段預(yù)留的業(yè)務(wù)資源

• Cancel操作要滿足冪等性

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

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

1. 創(chuàng)建訂單

2. 下單

• 調(diào)用余額系統(tǒng)，扣減余額

• 調(diào)用紅包系統(tǒng)，扣減紅包余額

• 修改訂單狀態(tài)為已支付

• 完后支付。

實際過程如下圖。

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

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

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

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

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

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

TCC TRY:

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

TCC Confirm:

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

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

TCC Cancle：

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

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

總結(jié)與思考

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

我們基于此對此總結(jié)下。使用分布式事務(wù)，我們需要結(jié)合我們實際場景應(yīng)用。

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

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

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

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

感謝各位的閱讀！關(guān)于數(shù)據(jù)庫中分布式事務(wù)是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！