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

成都創(chuàng)新互聯(lián)專注于企業(yè)全網(wǎng)營(yíng)銷推廣、網(wǎng)站重做改版、渾南網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5高端網(wǎng)站建設(shè)、商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)公司、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為渾南等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

事務(wù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分布式事務(wù)

摘抄一段 wiki 上解釋。

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

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

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

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

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

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

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

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

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

Eventually consistent（最終一致性）：最終一致是指經(jīng)過一段時(shí)間后，所有節(jié)點(diǎn)數(shù)據(jù)都將會(huì)達(dá)到一致。

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

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

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

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

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

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

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

• TCC

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

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

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

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

整個(gè)過程如下圖。

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

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

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

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

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

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

3. 數(shù)據(jù)不一致。第二階段，協(xié)調(diào)者發(fā)出第一個(gè)提交信號(hào)后后宕機(jī)，則第一個(gè)參與者提交事務(wù)，第二個(gè)參與者因?yàn)槲词盏絽f(xié)調(diào)者信號(hào)，無(wú)法進(jìn)行事務(wù)提交。

于是針對(duì) 2PC 存在的缺點(diǎn)，提出改進(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)者向各個(gè)事務(wù)下發(fā)事務(wù)執(zhí)行通知，鎖定資源，并將執(zhí)行情況返回。

• 部分參與者返回否認(rèn)信息或協(xié)調(diào)者等待超時(shí)。這種情況，協(xié)調(diào)者認(rèn)為事務(wù)無(wú)法正常執(zhí)行，下發(fā)中斷指令，各個(gè)參與者退出預(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)者等待超時(shí)，協(xié)調(diào)者下發(fā)回滾指令，釋放鎖定資源。

具體見下圖。

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

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

TCC

TCC 事務(wù)

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

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

Trying：

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

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

Confirm:

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

• Confirm操作要滿足冪等性

Cancel:

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

• Cancel操作要滿足冪等性

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

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

1. 創(chuàng)建訂單

2. 下單

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

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

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

• 完后支付。

實(shí)際過程如下圖。

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

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

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

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

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

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

TCC TRY:

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

TCC Confirm:

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

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

TCC Cancle：

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

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

總結(jié)與思考

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

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

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

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

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

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

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

當(dāng)前題目：數(shù)據(jù)庫(kù)中分布式事務(wù)是什么-創(chuàng)新互聯(lián)
文章來源：http://weahome.cn/article/ccssic.html