這篇文章主要講解了“數(shù)據(jù)庫(kù)分布式事務(wù)產(chǎn)生的原因”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“數(shù)據(jù)庫(kù)分布式事務(wù)產(chǎn)生的原因”吧！

目前創(chuàng)新互聯(lián)已為上千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計(jì)、札達(dá)網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶(hù)導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶(hù)和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。

數(shù)據(jù)庫(kù)分布式事務(wù)

分布式事務(wù)

分布式事務(wù)就是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上。以上是百度百科的解釋?zhuān)?jiǎn)單的說(shuō)，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務(wù)器上，且屬于不同的應(yīng)用，分布式事務(wù)需要保證這些小操作要么全部成功，要么全部失敗。本質(zhì)上來(lái)說(shuō)，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性。

事務(wù)的ACID特性

• A原子性: 在整個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不做，沒(méi)有中間狀態(tài)。對(duì)于事務(wù)在執(zhí)行中發(fā)生錯(cuò)誤，所有的操作都會(huì)被回滾，整個(gè)事務(wù)就像從沒(méi)被執(zhí)行過(guò)一樣。

• C一致性:事務(wù)的執(zhí)行必須保證系統(tǒng)的一致性，就拿轉(zhuǎn)賬為例，A有500元，B有300元，如果在一個(gè)事務(wù)里A成功轉(zhuǎn)給B50元，那么不管并發(fā)多少，不管發(fā)生什么，只要事務(wù)執(zhí)行成功了，那么最后A賬戶(hù)一定是450元，B賬戶(hù)一定是350元。

• I隔離性:所謂的隔離性就是說(shuō)，事務(wù)與事務(wù)之間不會(huì)互相影響，一個(gè)事務(wù)的中間狀態(tài)不會(huì)被其他事務(wù)感知。

• D持久性:所謂的持久性，就是說(shuō)一單事務(wù)完成了，那么事務(wù)對(duì)數(shù)據(jù)所做的變更就完全保存在了數(shù)據(jù)庫(kù)中，即使發(fā)生停電，系統(tǒng)宕機(jī)也是如此。

分布式理論

當(dāng)我們的單個(gè)數(shù)據(jù)庫(kù)的性能產(chǎn)生瓶頸的時(shí)候，我們可能會(huì)對(duì)數(shù)據(jù)庫(kù)進(jìn)行分區(qū)，這里所說(shuō)的分區(qū)指的是物理分區(qū)，分區(qū)之后可能不同的庫(kù)就處于不同的服務(wù)器上了，這個(gè)時(shí)候單個(gè)數(shù)據(jù)庫(kù)的ACID已經(jīng)不能適應(yīng)這種情況了，而在這種ACID的集群環(huán)境下，再想保證集群的ACID幾乎是很難達(dá)到，或者即使能達(dá)到那么效率和性能會(huì)大幅下降，最為關(guān)鍵的是再很難擴(kuò)展新的分區(qū)了，這個(gè)時(shí)候如果再追求集群的ACID會(huì)導(dǎo)致我們的系統(tǒng)變得很差，這時(shí)我們就需要引入一個(gè)新的理論原則來(lái)適應(yīng)這種集群的情況，就是 CAP 原則或者叫CAP定理，那么CAP定理指的是什么呢？

CAP定理

CAP定理是由加州大學(xué)伯克利分校Eric Brewer教授提出來(lái)的，他指出WEB服務(wù)無(wú)法同時(shí)滿(mǎn)足一下3個(gè)屬性：

一致性(Consistency) ： 客戶(hù)端知道一系列的操作都會(huì)同時(shí)發(fā)生(生效)
可用性(Availability) ： 每個(gè)操作都必須以可預(yù)期的響應(yīng)結(jié)束
分區(qū)容錯(cuò)性(Partition tolerance) ： 即使出現(xiàn)單個(gè)組件無(wú)法可用,操作依然可以完成
具體地講在分布式系統(tǒng)中，在任何數(shù)據(jù)庫(kù)設(shè)計(jì)中，一個(gè)Web應(yīng)用至多只能同時(shí)支持上面的兩個(gè)屬性。顯然，任何橫向擴(kuò)展策略都要依賴(lài)于數(shù)據(jù)分區(qū)。因此，設(shè)計(jì)人員必須在一致性與可用性之間做出選擇。

這個(gè)定理在迄今為止的分布式系統(tǒng)中都是適用的！ 為什么這么說(shuō)呢？

這個(gè)時(shí)候有同學(xué)可能會(huì)把數(shù)據(jù)庫(kù)的2PC（兩階段提交）搬出來(lái)說(shuō)話(huà)了。OK，我們就來(lái)看一下數(shù)據(jù)庫(kù)的兩階段提交。
對(duì)數(shù)據(jù)庫(kù)分布式事務(wù)有了解的同學(xué)一定知道數(shù)據(jù)庫(kù)支持的2PC，又叫做 XA Transactions。

MySQL從5.5版本開(kāi)始支持，SQL Server 2005 開(kāi)始支持，Oracle 7 開(kāi)始支持。

其中，XA 是一個(gè)兩階段提交協(xié)議，該協(xié)議分為以下兩個(gè)階段：

第一階段：事務(wù)協(xié)調(diào)器要求每個(gè)涉及到事務(wù)的數(shù)據(jù)庫(kù)預(yù)提交(precommit)此操作，并反映是否可以提交.
第二階段：事務(wù)協(xié)調(diào)器要求每個(gè)數(shù)據(jù)庫(kù)提交數(shù)據(jù)。
其中，如果有任何一個(gè)數(shù)據(jù)庫(kù)否決此次提交，那么所有數(shù)據(jù)庫(kù)都會(huì)被要求回滾它們?cè)诖耸聞?wù)中的那部分信息。這樣做的缺陷是什么呢? 咋看之下我們可以在數(shù)據(jù)庫(kù)分區(qū)之間獲得一致性。

如果CAP 定理是對(duì)的，那么它一定會(huì)影響到可用性。

如果說(shuō)系統(tǒng)的可用性代表的是執(zhí)行某項(xiàng)操作相關(guān)所有組件的可用性的和。那么在兩階段提交的過(guò)程中，可用性就代表了涉及到的每一個(gè)數(shù)據(jù)庫(kù)中可用性的和。我們假設(shè)兩階段提交的過(guò)程中每一個(gè)數(shù)據(jù)庫(kù)都具有99.9%的可用性，那么如果兩階段提交涉及到兩個(gè)數(shù)據(jù)庫(kù)，這個(gè)結(jié)果就是99.8%。根據(jù)系統(tǒng)可用性計(jì)算公式，假設(shè)每個(gè)月43200分鐘，99.9%的可用性就是43157分鐘, 99.8%的可用性就是43114分鐘，相當(dāng)于每個(gè)月的宕機(jī)時(shí)間增加了43分鐘。

以上，可以驗(yàn)證出來(lái)，CAP定理從理論上來(lái)講是正確的，CAP我們先看到這里，等會(huì)再接著說(shuō)。

BASE理論

在分布式系統(tǒng)中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實(shí)現(xiàn)高可用性呢？ 前人已經(jīng)給我們提出來(lái)了另外一個(gè)理論，就是BASE理論，它是用來(lái)對(duì)CAP定理進(jìn)行進(jìn)一步擴(kuò)充的。BASE理論指的是：

Basically Available（基本可用）
Soft state（軟狀態(tài)）
Eventually consistent（最終一致性）

BASE理論是對(duì)CAP中的一致性和可用性進(jìn)行一個(gè)權(quán)衡的結(jié)果，理論的核心思想就是：我們無(wú)法做到強(qiáng)一致，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性（Eventual consistency）。

有了以上理論之后，我們來(lái)看一下分布式事務(wù)的問(wèn)題。

分布式事務(wù)的產(chǎn)生的原因

數(shù)據(jù)庫(kù)分庫(kù)分表

當(dāng)數(shù)據(jù)庫(kù)單表一年產(chǎn)生的數(shù)據(jù)超過(guò)1000W，那么就要考慮分庫(kù)分表，具體分庫(kù)分表的原理在此不做解釋?zhuān)院笥锌赵敿?xì)說(shuō)，簡(jiǎn)單的說(shuō)就是原來(lái)的一個(gè)數(shù)據(jù)庫(kù)變成了多個(gè)數(shù)據(jù)庫(kù)。這時(shí)候，如果一個(gè)操作既訪(fǎng)問(wèn)01庫(kù)，又訪(fǎng)問(wèn)02庫(kù)，而且要保證數(shù)據(jù)的一致性，那么就要用到分布式事務(wù)。

應(yīng)用SOA化

所謂的SOA化，就是業(yè)務(wù)的服務(wù)化。比如原來(lái)單機(jī)支撐了整個(gè)電商網(wǎng)站，現(xiàn)在對(duì)整個(gè)網(wǎng)站進(jìn)行拆解，分離出了訂單中心、用戶(hù)中心、庫(kù)存中心。對(duì)于訂單中心，有專(zhuān)門(mén)的數(shù)據(jù)庫(kù)存儲(chǔ)訂單信息，用戶(hù)中心也有專(zhuān)門(mén)的數(shù)據(jù)庫(kù)存儲(chǔ)用戶(hù)信息，庫(kù)存中心也會(huì)有專(zhuān)門(mén)的數(shù)據(jù)庫(kù)存儲(chǔ)庫(kù)存信息。這時(shí)候如果要同時(shí)對(duì)訂單和庫(kù)存進(jìn)行操作，那么就會(huì)涉及到訂單數(shù)據(jù)庫(kù)和庫(kù)存數(shù)據(jù)庫(kù)，為了保證數(shù)據(jù)一致性，就需要用到分布式事務(wù)。

以上兩種情況表象不同，但是本質(zhì)相同，都是因?yàn)橐僮鞯臄?shù)據(jù)庫(kù)變多了！

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

• 基于XA協(xié)議的兩階段提交

XA是一個(gè)分布式事務(wù)協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫(kù)實(shí)現(xiàn)，比如Oracle、DB2這些商業(yè)數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交和回滾。XA實(shí)現(xiàn)分布式事務(wù)的原理如下：

總的來(lái)說(shuō)，XA協(xié)議比較簡(jiǎn)單，而且一旦商業(yè)數(shù)據(jù)庫(kù)實(shí)現(xiàn)了XA協(xié)議，使用分布式事務(wù)的成本也比較低。但是，XA也有致命的缺點(diǎn)，那就是性能不理想，特別是在交易下單鏈路，往往并發(fā)量很高，XA無(wú)法滿(mǎn)足高并發(fā)場(chǎng)景。XA目前在商業(yè)數(shù)據(jù)庫(kù)支持的比較理想，在mysql數(shù)據(jù)庫(kù)中支持的不太理想，mysql的XA實(shí)現(xiàn)，沒(méi)有記錄prepare階段日志，主備切換回導(dǎo)致主庫(kù)與備庫(kù)數(shù)據(jù)不一致。許多NOSQL也沒(méi)有支持XA，這讓XA的應(yīng)用場(chǎng)景變得非常狹隘。

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)： 盡量保證了數(shù)據(jù)的強(qiáng)一致，適合對(duì)數(shù)據(jù)強(qiáng)一致要求很高的關(guān)鍵領(lǐng)域。（其實(shí)也不能100%保證強(qiáng)一致）
缺點(diǎn)： 實(shí)現(xiàn)復(fù)雜，犧牲了可用性，對(duì)性能影響較大，不適合高并發(fā)高性能場(chǎng)景。

• 消息事務(wù)+最終一致性

所謂的消息事務(wù)就是基于消息中間件的兩階段提交，本質(zhì)上是對(duì)消息中間件的一種特殊利用，它是將本地事務(wù)和發(fā)消息放在了一個(gè)分布式事務(wù)里，保證要么本地操作成功成功并且對(duì)外發(fā)消息成功，要么兩者都失敗，開(kāi)源的RocketMQ就支持這一特性，具體原理如下：

1、A系統(tǒng)向消息中間件發(fā)送一條預(yù)備消息
2、消息中間件保存預(yù)備消息并返回成功
3、A執(zhí)行本地事務(wù)
4、A發(fā)送提交消息給消息中間件

通過(guò)以上4步完成了一個(gè)消息事務(wù)。對(duì)于以上的4個(gè)步驟，每個(gè)步驟都可能產(chǎn)生錯(cuò)誤，下面一一分析：

• 步驟一出錯(cuò)，則整個(gè)事務(wù)失敗，不會(huì)執(zhí)行A的本地操作

• 步驟二出錯(cuò)，則整個(gè)事務(wù)失敗，不會(huì)執(zhí)行A的本地操作

• 步驟三出錯(cuò)，這時(shí)候需要回滾預(yù)備消息，怎么回滾？答案是A系統(tǒng)實(shí)現(xiàn)一個(gè)消息中間件的回調(diào)接口，消息中間件會(huì)去不斷執(zhí)行回調(diào)接口，檢查A事務(wù)執(zhí)行是否執(zhí)行成功，如果失敗則回滾預(yù)備消息

• 步驟四出錯(cuò)，這時(shí)候A的本地事務(wù)是成功的，那么消息中間件要回滾A嗎？答案是不需要，其實(shí)通過(guò)回調(diào)接口，消息中間件能夠檢查到A執(zhí)行成功了，這時(shí)候其實(shí)不需要A發(fā)提交消息了，消息中間件可以自己對(duì)消息進(jìn)行提交，從而完成整個(gè)消息事務(wù)

基于消息中間件的兩階段提交往往用在高并發(fā)場(chǎng)景下，將一個(gè)分布式事務(wù)拆成一個(gè)消息事務(wù)（A系統(tǒng)的本地操作+發(fā)消息）+B系統(tǒng)的本地操作，其中B系統(tǒng)的操作由消息驅(qū)動(dòng)，只要消息事務(wù)成功，那么A操作一定成功，消息也一定發(fā)出來(lái)了，這時(shí)候B會(huì)收到消息去執(zhí)行本地操作，如果本地操作失敗，消息會(huì)重投，直到B操作成功，這樣就變相地實(shí)現(xiàn)了A與B的分布式事務(wù)。原理如下：

雖然上面的方案能夠完成A和B的操作，但是A和B并不是嚴(yán)格一致的，而是最終一致的，我們?cè)谶@里犧牲了一致性，換來(lái)了性能的大幅度提升。當(dāng)然，這種玩法也是有風(fēng)險(xiǎn)的，如果B一直執(zhí)行不成功，那么一致性會(huì)被破壞，具體要不要玩，還是得看業(yè)務(wù)能夠承擔(dān)多少風(fēng)險(xiǎn)。

本地消息表（異步確保）

本地消息表這種實(shí)現(xiàn)方式應(yīng)該是業(yè)界使用最多的，其核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理，這種思路是來(lái)源于ebay。我們可以從下面的流程圖中看出其中的一些細(xì)節(jié)：

基本思路就是：

消息生產(chǎn)方，需要額外建一個(gè)消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務(wù)數(shù)據(jù)要在一個(gè)事務(wù)里提交，也就是說(shuō)他們要在一個(gè)數(shù)據(jù)庫(kù)里面。然后消息會(huì)經(jīng)過(guò)MQ發(fā)送到消息的消費(fèi)方。如果消息發(fā)送失敗，會(huì)進(jìn)行重試發(fā)送。

消息消費(fèi)方，需要處理這個(gè)消息，并完成自己的業(yè)務(wù)邏輯。此時(shí)如果本地事務(wù)處理成功，表明已經(jīng)處理成功了，如果處理失敗，那么就會(huì)重試執(zhí)行。如果是業(yè)務(wù)上面的失敗，可以給生產(chǎn)方發(fā)送一個(gè)業(yè)務(wù)補(bǔ)償消息，通知生產(chǎn)方進(jìn)行回滾等操作。

生產(chǎn)方和消費(fèi)方定時(shí)掃描本地消息表，把還沒(méi)處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動(dòng)對(duì)賬補(bǔ)賬邏輯，這種方案還是非常實(shí)用的。

這種方案遵循BASE理論，采用的是最終一致性，筆者認(rèn)為是這幾種方案里面比較適合實(shí)際業(yè)務(wù)場(chǎng)景的，即不會(huì)出現(xiàn)像2PC那樣復(fù)雜的實(shí)現(xiàn)(當(dāng)調(diào)用鏈很長(zhǎng)的時(shí)候，2PC的可用性是非常低的)，也不會(huì)像TCC那樣可能出現(xiàn)確認(rèn)或者回滾不了的情況。

優(yōu)點(diǎn)： 一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。

缺點(diǎn)： 消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中，如果沒(méi)有封裝好的解決方案，會(huì)有很多雜活需要處理。

MQ 事務(wù)消息

有一些第三方的MQ是支持事務(wù)消息的，比如RocketMQ，他們支持事務(wù)消息的方式也是類(lèi)似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務(wù)消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中間件為例，其思路大致為：

第一階段Prepared消息，會(huì)拿到消息的地址。
第二階段執(zhí)行本地事務(wù)，第三階段通過(guò)第一階段拿到的地址去訪(fǎng)問(wèn)消息，并修改狀態(tài)。

也就是說(shuō)在業(yè)務(wù)方法內(nèi)要想消息隊(duì)列提交兩次請(qǐng)求，一次發(fā)送消息和一次確認(rèn)消息。如果確認(rèn)消息發(fā)送失敗了RocketMQ會(huì)定期掃描消息集群中的事務(wù)消息，這時(shí)候發(fā)現(xiàn)了Prepared消息，它會(huì)向消息發(fā)送者確認(rèn)，所以生產(chǎn)方需要實(shí)現(xiàn)一個(gè)check接口，RocketMQ會(huì)根據(jù)發(fā)送端設(shè)置的策略來(lái)決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息。這樣就保證了消息發(fā)送與本地事務(wù)同時(shí)成功或同時(shí)失敗。

優(yōu)點(diǎn)： 實(shí)現(xiàn)了最終一致性，不需要依賴(lài)本地?cái)?shù)據(jù)庫(kù)事務(wù)。

缺點(diǎn)： 實(shí)現(xiàn)難度大，主流MQ不支持，沒(méi)有.NET客戶(hù)端，RocketMQ事務(wù)消息部分代碼也未開(kāi)源。

• TCC編程模式

所謂的TCC編程模式，也是兩階段提交的一個(gè)變種。TCC提供了一個(gè)編程框架，將整個(gè)業(yè)務(wù)邏輯分為三塊：Try、Confirm和Cancel三個(gè)操作。以在線(xiàn)下單為例，Try階段會(huì)去扣庫(kù)存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進(jìn)入Cancel階段，會(huì)去恢復(fù)庫(kù)存?？傊琓CC就是通過(guò)代碼人為實(shí)現(xiàn)了兩階段提交，不同的業(yè)務(wù)場(chǎng)景所寫(xiě)的代碼都不一樣，復(fù)雜度也不一樣，因此，這種模式并不能很好地被復(fù)用。

TCC 采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷(xiāo)）操作。它分為三個(gè)階段：

1. Try 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留

2. Confirm 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開(kāi)始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。

3. Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。

舉個(gè)例子，假入 Bob 要向 Smith 轉(zhuǎn)賬，思路大概是：
我們有一個(gè)本地方法，里面依次調(diào)用
1、首先在 Try 階段，要先調(diào)用遠(yuǎn)程接口把 Smith 和 Bob 的錢(qián)給凍結(jié)起來(lái)。
2、在 Confirm 階段，執(zhí)行遠(yuǎn)程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進(jìn)行解凍。
3、如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠(yuǎn)程凍結(jié)接口對(duì)應(yīng)的解凍方法 (Cancel)。

優(yōu)缺點(diǎn)

優(yōu)點(diǎn)： 跟2PC比起來(lái)，實(shí)現(xiàn)以及流程相對(duì)簡(jiǎn)單了一些，但數(shù)據(jù)的一致性比2PC也要差一些
缺點(diǎn)： 缺點(diǎn)還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫(xiě)很多補(bǔ)償?shù)拇a，在一些場(chǎng)景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。

總結(jié)

分布式事務(wù)，本質(zhì)上是對(duì)多個(gè)數(shù)據(jù)庫(kù)的事務(wù)進(jìn)行統(tǒng)一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務(wù)，部分控制就是各種變種的兩階段提交，包括上面提到的消息事務(wù)+最終一致性、TCC模式，而完全控制就是完全實(shí)現(xiàn)兩階段提交。部分控制的好處是并發(fā)量和性能很好，缺點(diǎn)是數(shù)據(jù)一致性減弱了，完全控制則是犧牲了性能，保障了一致性，具體用哪種方式，最終還是取決于業(yè)務(wù)場(chǎng)景。作為技術(shù)人員，一定不能忘了技術(shù)是為業(yè)務(wù)服務(wù)的，不要為了技術(shù)而技術(shù)，針對(duì)不同業(yè)務(wù)進(jìn)行技術(shù)選型也是一種很重要的能力！

總結(jié)下解決方案：

一、結(jié)合MQ消息中間件實(shí)現(xiàn)的可靠消息最終一致性
二、TCC補(bǔ)償性事務(wù)解決方案
三、最大努力通知型方案

• 第一種方案：可靠消息最終一致性，需要業(yè)務(wù)系統(tǒng)結(jié)合MQ消息中間件實(shí)現(xiàn)，在實(shí)現(xiàn)過(guò)程中需要保證消息的成功發(fā)送及成功消費(fèi)。即需要通過(guò)業(yè)務(wù)系統(tǒng)控制MQ的消息狀態(tài)

• 第二種方案：TCC事務(wù)補(bǔ)償型，分為三個(gè)階段TRYING-CONFIRMING-CANCELING。每個(gè)階段做不同的處理。

• TRYING 階段主要是對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行檢測(cè)及資源預(yù)留

• CONFIRMING 階段是做業(yè)務(wù)提交，通過(guò)TRYING階段執(zhí)行成功后，再執(zhí)行該階段。默認(rèn)如果TRYING階段執(zhí)行成功，CONFIRMING就一定能成功。

• CANCELING 階段是回對(duì)業(yè)務(wù)做回滾，在TRYING階段中，如果存在分支事務(wù)TRYING失敗，則需要調(diào)用CANCELING將已預(yù)留的資源進(jìn)行釋放。
  以上所有的操作需要滿(mǎn)足冪等性，冪等性的實(shí)現(xiàn)方式可以是：
  1、通過(guò)唯一鍵值做處理，即每次調(diào)用的時(shí)候傳入唯一鍵值，通過(guò)唯一鍵值判斷業(yè)務(wù)是否被操作，如果已被操作，則不再重復(fù)操作
  2、通過(guò)狀態(tài)機(jī)處理，給業(yè)務(wù)數(shù)據(jù)設(shè)置狀態(tài)，通過(guò)業(yè)務(wù)狀態(tài)判斷是否需要重復(fù)執(zhí)行

• 第三種方案：最大努力通知型（按規(guī)律進(jìn)行通知，不保證數(shù)據(jù)一定能通知成功，但會(huì)提供可查詢(xún)操作接口進(jìn)行核對(duì)）這種方案主要用在與第三方系統(tǒng)通訊時(shí)，比如：調(diào)用微信或支付寶支付后的支付結(jié)果通知。這種方案也是結(jié)合MQ進(jìn)行實(shí)現(xiàn)，例如：通過(guò)MQ發(fā)送http請(qǐng)求，設(shè)置最大通知次數(shù)。達(dá)到通知次數(shù)后即不再通知。

感謝各位的閱讀，以上就是“數(shù)據(jù)庫(kù)分布式事務(wù)產(chǎn)生的原因”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)數(shù)據(jù)庫(kù)分布式事務(wù)產(chǎn)生的原因這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！