何為分布式事務(wù)

這篇文章主要介紹“何為分布式事務(wù)”，在日常操作中，相信很多人在何為分布式事務(wù)問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”何為分布式事務(wù)”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

事務(wù)

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

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

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

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

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

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

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

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

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

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

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

上圖一次購買過程，商家余額表與用戶余額表處于兩個(gè)單獨(dú)的數(shù)據(jù)庫實(shí)例中，這樣單獨(dú)的事務(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)無法滿足我們的業(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ò)本身無法做到 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)方案

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

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

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

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

• TCC

基于數(shù)據(jù)庫資源層面實(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ù)庫資源開始被鎖定。參與者將 undo 與 redo  寫入事務(wù)日志。第二階段，參與者(資源管理器)行提交事務(wù)，或者利用 undo 日志回滾事務(wù)，釋放資源。

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

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

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

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

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

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

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

數(shù)據(jù)不一致。第二階段，協(xié)調(diào)者發(fā)出第一個(gè)提交信號(hào)后后宕機(jī)，則第一個(gè)參與者提交事務(wù)，第二個(gè)參與者因?yàn)槲词盏絽f(xié)調(diào)者信號(hào)，無法進(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ù)無法正常執(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)故障。在第三階段，一旦參與者無法接受到協(xié)調(diào)者信號(hào)時(shí)，等待超時(shí)之后，參與者默認(rèn)執(zhí)行  commit，釋放資源。

三階段任然不能解決數(shù)據(jù)一致性問題。若協(xié)調(diào)者發(fā)出回滾命令，但是由于網(wǎng)絡(luò)問題，參與者在等待時(shí)間內(nèi)都無法接收到，這時(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ù)庫層面，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. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 創(chuàng)建訂單

3. 下單

• 調(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í)這么無情，生產(chǎn)系統(tǒng) confirm 或 cancle 肯定會(huì)有幾率失敗，這個(gè)時(shí)候就需要 TCC 框架記錄調(diào)用 confirm  結(jié)果。如果 confirm 調(diào)用失敗，TCC 框架需要記錄下來，然后間隔一定時(shí)間再次去調(diào)用。

到此，關(guān)于“何為分布式事務(wù)”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！