分布式事務(wù)的解決方案有哪些

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

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

事務(wù)，即將一個(gè)活動涉及的所有操作作為一個(gè)不可分割的執(zhí)行單元，提供一種“要么一個(gè)都不執(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、一個(gè)服務(wù)操作一個(gè)數(shù)據(jù)庫

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

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

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

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

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

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

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

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

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

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

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

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

基礎(chǔ)

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

ACID

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

• A：原子性（Atomicity)

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

• C:一致性（Consistency)

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

• I:隔離型（Isolation)

指的是在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí)，每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間。由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離。事務(wù)查看數(shù)據(jù)更新時(shí)，數(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é)束時(shí)的狀態(tài)。

CAP

CAP

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

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

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

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

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

CA without P

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

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

CP without A

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

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

AP wihtout C

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

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

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

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

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

對于AP來說，放棄一致性(這里說的一致性是強(qiáng)一致性)，追求分區(qū)容錯(cuò)性和可用性，這是很多分布式系統(tǒng)設(shè)計(jì)時(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)故障時(shí)，允許損失部分可用功能，保證核心功能可用。

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

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

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

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

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

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

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

2PC

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

準(zhǔn)備階段

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

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

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

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

提交階段

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

提交通過

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

提交通過

提交回滾

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

提交回滾

2PC缺點(diǎn)

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

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

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

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

TCC

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

TCC模式需要事務(wù)參與者根據(jù)自己的業(yè)務(wù)場景實(shí)現(xiàn) Try、Confirm 和 Cancel 三個(gè)操作接口；事務(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操作失敗也會一直重試，因此也需要滿足冪等性。

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

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

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

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

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

TCC過程示例

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

本地消息表

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

本地消息表

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

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

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

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

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

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

MQ事務(wù)

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

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

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

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

Saga

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

每個(gè)Saga由一系列sub-transaction Ti 組成 每個(gè)Ti 都有對應(yīng)的補(bǔ)償動作Ci，補(bǔ)償動作用于撤銷Ti造成的結(jié)果,這里的每個(gè)T，都是一個(gè)本地事務(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ā)生錯(cuò)誤的sub-transaction，這種做法的效果是撤銷掉之前所有成功的sub-transation，使得整個(gè)Saga的執(zhí)行結(jié)果撤銷。
向前恢復(fù)，適用于必須要成功的場景，執(zhí)行順序是類似于這樣的：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn，其中j是發(fā)生錯(cuò)誤的sub-transaction。該情況下不需要Ci。

這里要注意的是，在saga模式中不能保證隔離性，因?yàn)闆]有鎖住資源，其他事務(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這個(gè)時(shí)候需要執(zhí)行回滾，但是這個(gè)用戶已經(jīng)把水喝了(另外一個(gè)事務(wù))，回滾的時(shí)候就會發(fā)現(xiàn)，無法給用戶減一瓶水了。這就是事務(wù)之間沒有隔離性的問題

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

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

本文標(biāo)題：分布式事務(wù)的解決方案有哪些
瀏覽路徑：http://bm7419.com/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)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)