本篇文章給大家分享的是有關(guān)分布式事務(wù)的解決方案有哪些，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

創(chuàng)新互聯(lián)公司主營中山網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,app軟件開發(fā)公司,中山h5成都小程序開發(fā)搭建,中山網(wǎng)站營銷推廣歡迎中山等地區(qū)企業(yè)咨詢

事務(wù)，即將一個活動涉及的所有操作作為一個不可分割的執(zhí)行單元，提供一種“要么一個都不執(zhí)行，要么全都執(zhí)行”的機(jī)制。在單機(jī)系統(tǒng)中，我們很容易能夠?qū)崿F(xiàn)一套滿足ACID特性的事務(wù)處理系統(tǒng)，但是在分布式系統(tǒng)中，數(shù)據(jù)分散在各臺不同的機(jī)器上，如何對這些數(shù)據(jù)進(jìn)行分布式事務(wù)處理具有非常大的挑戰(zhàn)。

背景

1、一個服務(wù)操作一個數(shù)據(jù)庫

一個服務(wù)一個數(shù)據(jù)庫

一個服務(wù)操作一個對應(yīng)的數(shù)據(jù)庫，這就是我們大多數(shù)服務(wù)的場景，這種場景的事務(wù)很好保證，利用數(shù)據(jù)庫本身的事務(wù)特性即可，我們稱之為本地事務(wù)。

2、同一個服務(wù)操作多個數(shù)據(jù)庫

一個服務(wù)多個數(shù)據(jù)庫

隨著系統(tǒng)功能的增加，數(shù)據(jù)量的增多，我們可能需要隊數(shù)據(jù)庫進(jìn)行劃分，按照劃分方式，分為垂直劃分和水平劃分：

• 垂直劃分
  隨著服務(wù)功能的增多，我們可能會把某些功能方法放到一個單獨的其他數(shù)據(jù)庫中，或者我們會直接去訪問其他服務(wù)的數(shù)據(jù)庫，這時就會操作多個數(shù)據(jù)庫了，我們把這種情況，稱為數(shù)據(jù)庫的垂直劃分。（其實這種場景不應(yīng)該存在，因為如果是本服務(wù)的，那么就應(yīng)該是同一個數(shù)據(jù)庫為好；如果是其他的服務(wù)，那么不應(yīng)該直接操作其他服務(wù)的數(shù)據(jù)庫，而是應(yīng)該調(diào)用其他服務(wù)提供的接口），因此這種場景不是很常見；

• 水平劃分
  上面那種場景不常見，但還有一種情況，卻是經(jīng)常遇到的，尤其是數(shù)據(jù)量很大的情況下。那就是當(dāng)我們對數(shù)據(jù)庫進(jìn)行分庫分表后，這時候就需要操作多個數(shù)據(jù)庫了，這種情況我們稱為水平劃分；

3、微服務(wù)SOA跨服務(wù)調(diào)用

微服務(wù)調(diào)用

上面說到直接操作其他服務(wù)的DB，并不合適，正確的方式是使用其他服務(wù)提供的接口。

“一個服務(wù)操作一個數(shù)據(jù)庫”的場景的事務(wù)，我們稱之為本地事務(wù)；“同一個服務(wù)操作多個數(shù)據(jù)庫”和“微服務(wù)SOA跨服務(wù)調(diào)用”這兩種的事務(wù)，我們稱之為分布式事務(wù)。

對于本地事務(wù),我們可以利用數(shù)據(jù)庫本身的事務(wù)特性保證事務(wù)，那么在分布式場景下，我們該如何保證事務(wù)了？

基礎(chǔ)

談到事務(wù)，就必須知道三個規(guī)則，分別是：ACID,CAP和BASE。單機(jī)系統(tǒng)一般遵循ACID規(guī)則；而分布式系統(tǒng)則一般遵循CAP規(guī)則或者BASE規(guī)則。

ACID

ACID是事務(wù)的四個基本性質(zhì)，屬于傳統(tǒng)數(shù)據(jù)庫常用的設(shè)計理念，追求強(qiáng)一致性模型。ACID是指Atomicity（原子性）、Consistency（一致性）、Isolation（隔離型）、Durability（持久性）：

• A：原子性（Atomicity)

一個事務(wù)(transaction)中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾（Rollback）到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣。

• C:一致性（Consistency)

事務(wù)的一致性指的是在一個事務(wù)執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫都必須處于一致性狀態(tài)。如果事務(wù)成功地完成，那么系統(tǒng)中所有變化將正確地應(yīng)用，系統(tǒng)處于有效狀態(tài)。如果在事務(wù)中出現(xiàn)錯誤，那么系統(tǒng)中的所有變化將自動地回滾，系統(tǒng)返回到原始狀態(tài)。

• I:隔離型（Isolation)

指的是在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時操縱相同的數(shù)據(jù)時，每個事務(wù)都有各自的完整數(shù)據(jù)空間。由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離。事務(wù)查看數(shù)據(jù)更新時，數(shù)據(jù)所處的狀態(tài)要么是另一事務(wù)修改它之前的狀態(tài)，要么是另一事務(wù)修改它之后的狀態(tài)，事務(wù)不會查看到中間狀態(tài)的數(shù)據(jù)。

• D:持久性（Durability)

指的是只要事務(wù)成功結(jié)束，它對數(shù)據(jù)庫所做的更新就必須永久保存下來。即使發(fā)生系統(tǒng)崩潰，重新啟動數(shù)據(jù)庫系統(tǒng)后，數(shù)據(jù)庫還能恢復(fù)到事務(wù)成功結(jié)束時的狀態(tài)。

CAP

CAP

CAP是Consistent(一致性)、Available(可用性)和Partition Tolerance (分區(qū)容錯性)三個詞的縮寫：

• C (一致性):對某個指定的客戶端來說，讀操作能返回最新的寫操作。對于數(shù)據(jù)分布在不同節(jié)點上的數(shù)據(jù)上來說，如果在某個節(jié)點更新了數(shù)據(jù)，那么在其他節(jié)點如果都能讀取到這個最新的數(shù)據(jù)，那么就稱為強(qiáng)一致，如果有某個節(jié)點沒有讀取到，那就是分布式不一致。

• A (可用性)：非故障的節(jié)點在合理的時間內(nèi)返回合理的響應(yīng)(不是錯誤和超時的響應(yīng))?？捎眯缘膬蓚€關(guān)鍵一個是合理的時間，一個是合理的響應(yīng)。合理的時間指的是請求不能無限被阻塞，應(yīng)該在合理的時間給出返回。合理的響應(yīng)指的是系統(tǒng)應(yīng)該明確返回結(jié)果并且結(jié)果是正確的，這里的正確指的是比如應(yīng)該返回50，而不是返回40。

• P (分區(qū)容錯性):當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)后，系統(tǒng)能夠繼續(xù)工作。打個比方，這里個集群有多臺機(jī)器，有臺機(jī)器網(wǎng)絡(luò)出現(xiàn)了問題，但是這個集群仍然可以正常工作。

CAP三者不可能共有，一個分布式系統(tǒng)最多只能同時滿足一致性（Consistence）、可用性（Availability）和分區(qū)容錯性（Partition tolerance）這三項中的兩項:

CA without P

這種情況在分布式系統(tǒng)中幾乎是不存在的。在分布式環(huán)境下，主機(jī)眾多、部署分散，分區(qū)是一個必然的事實。在這個存在分區(qū)的事實下，我們選擇了CA而放棄了P，那么為了保證一致性，這個時候必須拒絕請求，但是A又不允許。因此在分布式場景下，不可能選擇CA架構(gòu)，只能選擇CP或者AP架構(gòu)。

我們熟知的關(guān)系型數(shù)據(jù)庫是CA架構(gòu)，如My Sql和Oracle就是保證了可用性和數(shù)據(jù)一致性，但是他并不是個分布式系統(tǒng)。一旦關(guān)系型數(shù)據(jù)庫要考慮主備同步、集群部署等就必須要把P也考慮進(jìn)來。

CP without A

如果一個分布式系統(tǒng)不要求強(qiáng)的可用性，即容許系統(tǒng)停機(jī)或者長時間無響應(yīng)的話，就可以在CAP三者中保障CP而舍棄A。一個保證了CP而一個舍棄了A的分布式系統(tǒng)，一旦發(fā)生網(wǎng)絡(luò)故障或者消息丟失等情況，就要犧牲用戶的體驗，等待所有數(shù)據(jù)全部一致了之后再讓用戶訪問系統(tǒng)。

設(shè)計成CP的系統(tǒng)的，最典型的就是很多分布式數(shù)據(jù)庫，他們都是設(shè)計成CP的。在發(fā)生極端情況時，優(yōu)先保證數(shù)據(jù)的強(qiáng)一致性，代價就是舍棄系統(tǒng)的可用性。如redis、HBase等，還有分布式系統(tǒng)中常用的Zookeeper也是在CAP三者之中選擇優(yōu)先保證CP的。對于大規(guī)模金融服務(wù)也是，他們必須保證C，同時存在P，因此也只能犧牲A.

AP wihtout C

要高可用并允許分區(qū)，則需放棄一致性。一旦網(wǎng)絡(luò)問題發(fā)生，節(jié)點之間可能會失去聯(lián)系。為了保證高可用，需要在用戶訪問時可以馬上得到返回，則每個節(jié)點只能用本地數(shù)據(jù)提供服務(wù)，而這樣會導(dǎo)致全局?jǐn)?shù)據(jù)的不一致性。

這種舍棄強(qiáng)一致性而保證系統(tǒng)的分區(qū)容錯性和可用性的場景和案例非常多。前面我們介紹可用性的時候說到過，很多系統(tǒng)在可用性方面會做很多事情來保證系統(tǒng)的全年可用性可以達(dá)到N個9，所以，對于很多業(yè)務(wù)系統(tǒng)來說，比如淘寶的購物，12306的買票。都是在可用性和一致性之間舍棄了一致性而選擇可用性。

你在12306買票的時候肯定遇到過這種場景，當(dāng)你購買的時候提示你是有票的（但是可能實際已經(jīng)沒票了），你也正常的去輸入驗證碼，下單了。但是過了一會系統(tǒng)提示你下單失敗，余票不足。這其實就是先在可用性方面保證系統(tǒng)可以正常的服務(wù)，然后在數(shù)據(jù)的一致性方面做了些犧牲，會影響一些用戶體驗，但是也不至于造成用戶流程的嚴(yán)重阻塞。

但是，我們說很多網(wǎng)站犧牲了一致性，選擇了可用性，這其實也不準(zhǔn)確的。就比如上面的買票的例子，其實舍棄的只是強(qiáng)一致性。退而求其次保證了最終一致性。也就是說，雖然下單的瞬間，關(guān)于車票的庫存可能存在數(shù)據(jù)不一致的情況，但是過了一段時間，還是要保證最終一致性的。

對于多數(shù)大型互聯(lián)網(wǎng)應(yīng)用的場景，主機(jī)眾多、部署分散，而且現(xiàn)在的集群規(guī)模越來越大，所以節(jié)點故障、網(wǎng)絡(luò)故障是常態(tài)，而且要保證服務(wù)可用性達(dá)到N個9，即保證P和A，舍棄C（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達(dá)到造成用戶流程的嚴(yán)重程度。

對于AP來說，放棄一致性(這里說的一致性是強(qiáng)一致性)，追求分區(qū)容錯性和可用性，這是很多分布式系統(tǒng)設(shè)計時的選擇，后面的BASE也是根據(jù)AP來擴(kuò)展。

BASE

BASE理論是對CAP理論的延伸，核心思想是即使無法做到強(qiáng)一致性（CAP的一致性就是強(qiáng)一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性。

BASE 是指 Basically Available(基本可用)、Soft state(軟狀態(tài))和 Eventually consistent (最終一致性)：

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

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

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

BASE中用軟狀態(tài)和最終一致，保證了分布死網(wǎng)絡(luò)延遲后的一致性。BASE和 ACID 是相反的，它完全不同于ACID的強(qiáng)一致性模型，而是通過犧牲強(qiáng)一致性來獲得可用性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達(dá)到一致狀態(tài)。

分布式事務(wù)解決方案

目前分布式事務(wù)解決的方案主要有對業(yè)務(wù)無入侵和有入侵的方案，無入侵方案主要有基于數(shù)據(jù)庫 XA 協(xié)議的兩段式提交（2PC）方案，它的優(yōu)點是對業(yè)務(wù)代碼無入侵，但是它的缺點也是很明顯：必須要求數(shù)據(jù)庫對 XA 協(xié)議的支持，且由于 XA 協(xié)議自身的特點，它會造成事務(wù)資源長時間得不到釋放，鎖定周期長，而且在應(yīng)用層上面無法干預(yù)，因此它性能很差，它的存在相當(dāng)于七傷拳那樣“傷人七分，損己三分”，因此在互聯(lián)網(wǎng)項目中并不是很流行這種解決方案。

為了這個彌補這種方案帶來性能低的問題，又想出了很多種方案來解決，但這無一例外都需要通過在應(yīng)用層做手腳，即入侵業(yè)務(wù)的方式，比如很出名的 TCC 方案，基于 TCC 也有很多成熟的框架，如 ByteTCC、tcc-transaction 等。以及基于可靠消息的最終一致性來實現(xiàn)，如 RocketMQ 的事務(wù)消息。

入侵代碼的方案是基于現(xiàn)有情形“迫不得已”才推出的解決方案，實際上它們實現(xiàn)起來非常不優(yōu)雅，一個事務(wù)的調(diào)用通常伴隨而來的是對該事務(wù)接口增加一系列的反向操作，比如 TCC 三段式提交，提交邏輯必然伴隨著回滾的邏輯，這樣的代碼會使得項目非常臃腫，維護(hù)成本高。

2PC

在分布式系統(tǒng)中，每個節(jié)點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節(jié)點的操作的成功或失敗。當(dāng)一個事務(wù)跨越多個節(jié)點時，需要引入一個作為協(xié)調(diào)者的組件來統(tǒng)一掌控所有節(jié)點(稱作參與者)的操作結(jié)果并最終指示這些節(jié)點是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫入磁盤等)。因此，二階段提交的思路可以概括為：參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。所謂的兩個階段是指：第一階段：準(zhǔn)備階段；第二階段：提交階段。

準(zhǔn)備階段

事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個參與者(資源管理器)發(fā)送Prepare消息，每個參與者要么直接返回失敗(如權(quán)限驗證失敗)，要么在本地執(zhí)行事務(wù)，寫本地的redo和undo日志，但不提交，到達(dá)一種“萬事俱備，只欠東風(fēng)”的狀態(tài)。

詳細(xì)步驟如下：
1）協(xié)調(diào)者節(jié)點向所有參與者節(jié)點詢問是否可以執(zhí)行提交操作(vote)，并開始等待各參與者節(jié)點的響應(yīng)；

2）參與者節(jié)點執(zhí)行詢問發(fā)起為止的所有事務(wù)操作，并將Undo信息和Redo信息寫入日志；

3）各參與者節(jié)點響應(yīng)協(xié)調(diào)者節(jié)點發(fā)起的詢問。如果參與者節(jié)點的事務(wù)操作實際執(zhí)行成功，則它返回一個”同意”消息；如果參與者節(jié)點的事務(wù)操作實際執(zhí)行失敗，則它返回一個”中止”消息。

提交階段

如果協(xié)調(diào)者收到了參與者的失敗消息或者超時，直接給每個參與者發(fā)送回滾(Rollback)消息；否則，發(fā)送提交(Commit)消息；參與者根據(jù)協(xié)調(diào)者的指令執(zhí)行提交或者回滾操作，釋放所有事務(wù)處理過程中使用的鎖資源。

提交通過

所有的參與者，如果在準(zhǔn)備階段，都返回OK，那么第二階段均進(jìn)行提交。

提交通過

提交回滾

所有參與者，在準(zhǔn)備階段，只要有一個返回NO，那么第二階段就都進(jìn)行回滾。

提交回滾

2PC缺點

單點問題:事務(wù)管理器在整個流程中扮演的角色很關(guān)鍵，如果其宕機(jī)，比如在第一階段已經(jīng)完成，在第二階段正準(zhǔn)備提交的時候事務(wù)管理器宕機(jī)，資源管理器就會一直阻塞，導(dǎo)致數(shù)據(jù)庫無法使用。

同步阻塞:在準(zhǔn)備就緒之后，資源管理器中的資源一直處于阻塞，直到提交完成，釋放資源。

數(shù)據(jù)不一致:兩階段提交協(xié)議雖然為分布式數(shù)據(jù)強(qiáng)一致性所設(shè)計，但仍然存在數(shù)據(jù)不一致性的可能，比如在第二階段中，假設(shè)協(xié)調(diào)者發(fā)出了事務(wù)commit的通知，但是因為網(wǎng)絡(luò)問題該通知僅被一部分參與者所收到并執(zhí)行了commit操作，其余的參與者則因為沒有收到通知一直處于阻塞狀態(tài)，這時候就產(chǎn)生了數(shù)據(jù)的不一致性。

總的來說，XA協(xié)議比較簡單，成本較低，但是其單點問題，以及不能支持高并發(fā)(由于同步阻塞)依然是其最大的弱點。

TCC

TCC與2PC二階段提交機(jī)制類似，區(qū)別在于層面不同，2PC是在數(shù)據(jù)庫層面解決數(shù)據(jù)庫之間的分布式事務(wù)，TCC是在應(yīng)用層面解決分布式系統(tǒng)中的分布式事務(wù)。

TCC模式需要事務(wù)參與者根據(jù)自己的業(yè)務(wù)場景實現(xiàn) Try、Confirm 和 Cancel 三個操作接口；事務(wù)參與者在一階段中，執(zhí)行Try方式；在二階段中，如果是提交，則執(zhí)行Confirm方法，如果是回滾，則執(zhí)行 Cancel方法：

• Try接口：嘗試執(zhí)行,完成所有業(yè)務(wù)檢查（一致性）,預(yù)留必須業(yè)務(wù)資源（準(zhǔn)隔離性）

• Confirm接口：確認(rèn)執(zhí)行真正執(zhí)行業(yè)務(wù)，不作任何業(yè)務(wù)檢查，只使用Try階段預(yù)留的業(yè)務(wù)資源，Confirm要求一定要成功，因此Confirm失敗后需要進(jìn)行重試。因此Confirm操作需要滿足冪等性。

• Cancel接口：釋放Try階段預(yù)留的業(yè)務(wù)資源。Cancel操作失敗也會一直重試，因此也需要滿足冪等性。

舉個簡單的例子，你去商店用兩30塊錢買一瓶礦泉水，那么參與方為你和店主，資源為你的錢和老板的水，操作為你付錢，老板收錢和給你水：

第一階段（try)：各自檢查并資源。對于你，你需要檢查你錢包里是否夠2塊錢，如果有那么就要凍結(jié)這兩塊錢；對于老板，它看看冰箱里是不是還要礦泉水，如果有，那么鎖定這瓶水。

第二階段（Confirm)：如果你和老板都檢查了，沒問題，那么就執(zhí)行交易Confirm，你付兩塊錢，老板收到兩塊錢，并給你一瓶礦礦水。

第二階段（Cancel)：如果你倆在檢查時，操作有失敗情況或者超時，則進(jìn)行cancel，你解凍你的錢，老板的那一瓶水也可以賣給別人了；

對于你這邊，詳細(xì)列出TCC執(zhí)行過程，如下：

TCC過程示例

用戶接入 TCC 模式，最重要的事情就是考慮如何將業(yè)務(wù)模型拆成 2 階段，實現(xiàn)成 TCC 的 3 個方法，并且保證 Try 成功 Confirm 一定能成功。相對于 AT 模式，TCC 模式對業(yè)務(wù)代碼有一定的侵入性，但是 TCC 模式無 AT 模式的全局行鎖，TCC 性能會比 AT 模式高很多。

本地消息表

此方案的核心是將需要分布式處理的任務(wù)通過消息日志的方式來異步執(zhí)行。消息日志可以存儲到本地文本、數(shù)據(jù)庫或消息隊列，再通過業(yè)務(wù)規(guī)則自動或人工發(fā)起重試。人工重試更多的是應(yīng)用于支付場景，通過對賬系統(tǒng)對事后問題的處理。

本地消息表

對于本地消息隊列來說核心是把大事務(wù)轉(zhuǎn)變?yōu)樾∈聞?wù)。還是舉上面用100元去買一瓶水的例子。

1）當(dāng)你扣錢的時候，你需要在你扣錢的服務(wù)器上新增加一個本地消息表，你需要把你扣錢和寫入減去水的庫存到本地消息表放入同一個事務(wù)(依靠數(shù)據(jù)庫本地事務(wù)保證一致性）；

2.這個時候有個定時任務(wù)去輪詢這個本地事務(wù)表，把沒有發(fā)送的消息，扔給商品庫存服務(wù)器，叫他減去水的庫存，到達(dá)商品服務(wù)器之后這個時候得先寫入這個服務(wù)器的事務(wù)表，然后進(jìn)行扣減，扣減成功后，更新事務(wù)表中的狀態(tài)；

3.商品服務(wù)器通過定時任務(wù)掃描消息表或者直接通知扣錢服務(wù)器，扣錢服務(wù)器本地消息表進(jìn)行狀態(tài)更新；

4.針對一些異常情況，定時掃描未成功處理的消息，進(jìn)行重新發(fā)送，在商品服務(wù)器接到消息之后，首先判斷是否是重復(fù)的，如果已經(jīng)接收，在判斷是否執(zhí)行，如果執(zhí)行在馬上又進(jìn)行通知事務(wù)，如果未執(zhí)行，需要重新執(zhí)行需要由業(yè)務(wù)保證冪等，也就是不會多扣一瓶水；

本地消息隊列是BASE理論，是最終一致模型，適用于對一致性要求不高的。實現(xiàn)這個模型時需要注意重試的冪等。

MQ事務(wù)

在RocketMQ中實現(xiàn)了分布式事務(wù)，實際上其實是對本地消息表的一個封裝，將本地消息表移動到了MQ內(nèi)部，下面簡單介紹一下MQ事務(wù)

基本流程如下:
第一階段Prepared消息，會拿到消息的地址。
第二階段執(zhí)行本地事務(wù)。
第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。消息接受者就能使用這個消息。

如果確認(rèn)消息失敗，在RocketMq Broker中提供了定時掃描沒有更新狀態(tài)的消息，如果有消息沒有得到確認(rèn)，會向消息發(fā)送者發(fā)送消息，來判斷是否提交，在rocketmq中是以listener的形式給發(fā)送者，用來處理。

如果消費超時，則需要一直重試，消息接收端需要保證冪等。如果消息消費失敗，這個就需要人工進(jìn)行處理，因為這個概率較低，如果為了這種小概率時間而設(shè)計這個復(fù)雜的流程反而得不償失

Saga

Saga是30年前一篇數(shù)據(jù)庫倫理提到的一個概念。其核心思想是將長事務(wù)拆分為多個本地短事務(wù)，由Saga事務(wù)協(xié)調(diào)器協(xié)調(diào)，如果正常結(jié)束那就正常完成，如果某個步驟失敗，則根據(jù)相反順序一次調(diào)用補償操作。

每個Saga由一系列sub-transaction Ti 組成 每個Ti 都有對應(yīng)的補償動作Ci，補償動作用于撤銷Ti造成的結(jié)果,這里的每個T，都是一個本地事務(wù)。可以看到，和TCC相比，Saga沒有“預(yù)留 try”動作，它的Ti就是直接提交到庫。

Saga的執(zhí)行順序有兩種：
T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1，其中0 < j < n Saga定義了兩種恢復(fù)策略：

向后恢復(fù)，即上面提到的第二種執(zhí)行順序，其中j是發(fā)生錯誤的sub-transaction，這種做法的效果是撤銷掉之前所有成功的sub-transation，使得整個Saga的執(zhí)行結(jié)果撤銷。
向前恢復(fù)，適用于必須要成功的場景，執(zhí)行順序是類似于這樣的：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn，其中j是發(fā)生錯誤的sub-transaction。該情況下不需要Ci。

這里要注意的是，在saga模式中不能保證隔離性，因為沒有鎖住資源，其他事務(wù)依然可以覆蓋或者影響當(dāng)前事務(wù)。

還是拿100元買一瓶水的例子來說，這里定義

T1=扣100元 T2=給用戶加一瓶水 T3=減庫存一瓶水

C1=加100元 C2=給用戶減一瓶水 C3=給庫存加一瓶水

我們一次進(jìn)行T1,T2，T3如果發(fā)生問題，就執(zhí)行發(fā)生問題的C操作的反向。
上面說到的隔離性的問題會出現(xiàn)在，如果執(zhí)行到T3這個時候需要執(zhí)行回滾，但是這個用戶已經(jīng)把水喝了(另外一個事務(wù))，回滾的時候就會發(fā)現(xiàn)，無法給用戶減一瓶水了。這就是事務(wù)之間沒有隔離性的問題

可以看見saga模式?jīng)]有隔離性的影響還是較大，可以參照華為的解決方案:從業(yè)務(wù)層面入手加入一 Session 以及鎖的機(jī)制來保證能夠串行化操作資源。也可以在業(yè)務(wù)層面通過預(yù)先凍結(jié)資金的方式隔離這部分資源， 最后在業(yè)務(wù)操作的過程中可以通過及時讀取當(dāng)前狀態(tài)的方式獲取到最新的更新。

以上就是分布式事務(wù)的解決方案有哪些，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

本文標(biāo)題：分布式事務(wù)的解決方案有哪些
瀏覽路徑：http://www.rwnh.cn/article26/jdgpcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、外貿(mào)建站、自適應(yīng)網(wǎng)站、移動網(wǎng)站建設(shè)、網(wǎng)站建設(shè)、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)