微信公眾號(hào)：moon聊技術(shù)
本文約5300字，完整閱讀大概會(huì)花費(fèi)你「13分鐘」左右的時(shí)間
[如果你覺得文章對(duì)你有幫助，歡迎關(guān)注，點(diǎn)贊，轉(zhuǎn)發(fā)]

什么是分布式事務(wù)

分布式事務(wù)是指事務(wù)的參與者、支持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器「分別位于不同的分布式系統(tǒng)的不同節(jié)點(diǎn)之上」。

一個(gè)大的操作由N多的小的操作共同完成。而這些小的操作又分布在不同的服務(wù)上。針對(duì)于這些操作，「要么全部成功執(zhí)行，要么全部不執(zhí)行」。

為什么會(huì)有分布式事務(wù)？

舉個(gè)例子：

轉(zhuǎn)賬是最經(jīng)典的分布式事務(wù)場(chǎng)景，假設(shè)用戶 A 使用銀行 app 發(fā)起一筆跨行轉(zhuǎn)賬給用戶 B，銀行系統(tǒng)首先扣掉用戶 A 的錢，然后增加用戶 B 賬戶中的余額。

如果其中某個(gè)步驟失敗，此時(shí)就有可能會(huì)出現(xiàn) 2 種「異?！?/strong>情況：

• 1.用戶 A 的賬戶扣款成功，用戶 B 賬戶余額增加失敗
  
• 2.用戶 A 賬戶扣款失敗，用戶 B 賬戶余額增加成功。

對(duì)于銀行系統(tǒng)來(lái)說(shuō)，以上 2 種情況都是「不允許發(fā)生」，此時(shí)就需要事務(wù)來(lái)保證轉(zhuǎn)賬操作的成功。

在「單體應(yīng)用」中，我們只需要貼上@Transactional注解就可以開啟事務(wù)來(lái)保證整個(gè)操作的「原子性」。

但是看似以上簡(jiǎn)單的操作，在實(shí)際的應(yīng)用架構(gòu)中，不可能是單體的服務(wù)，我們會(huì)把這一系列操作交給「N個(gè)服務(wù)」去完成，也就是拆分成為「分布式微服務(wù)架構(gòu)」。

比如下訂單服務(wù)，扣庫(kù)存服務(wù)等等，必須要「保證不同服務(wù)狀態(tài)結(jié)果的一致性」，于是就出現(xiàn)了分布式事務(wù)。

分布式理論

CAP定理

在一個(gè)分布式系統(tǒng)中，以下三點(diǎn)特性無(wú)法同時(shí)滿足，「魚與熊掌不可兼得」

一致性（C）：
在分布式系統(tǒng)中的所有數(shù)據(jù)備份，「在同一時(shí)刻是否擁有同樣的值」。（等同于所有節(jié)點(diǎn)訪問(wèn)同一份最新的數(shù)據(jù)副本）

可用性（A）：
在集群中一部分節(jié)點(diǎn)「故障」后，集群整體「是否還能響應(yīng)」客戶端的讀寫請(qǐng)求。（對(duì)數(shù)據(jù)更新具備高可用性）

分區(qū)容錯(cuò)性（P）：
即使出現(xiàn)「單個(gè)組件無(wú)法可用,操作依然可以完成」。

具體地講在分布式系統(tǒng)中，在任何數(shù)據(jù)庫(kù)設(shè)計(jì)中，一個(gè)Web應(yīng)用「至多只能同時(shí)支持上面的兩個(gè)屬性」。顯然，任何橫向擴(kuò)展策略都要依賴于數(shù)據(jù)分區(qū)。因此，設(shè)計(jì)人員必須在一致性與可用性之間做出選擇。

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）。

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

兩階段提交（2PC）

熟悉mysql的同學(xué)對(duì)兩階段提交應(yīng)該頗為熟悉，mysql的事務(wù)就是通過(guò)「日志系統(tǒng)」來(lái)完成兩階段提交的。

兩階段協(xié)議可以用于單機(jī)集中式系統(tǒng)，由事務(wù)管理器協(xié)調(diào)多個(gè)資源管理器；也可以用于分布式系統(tǒng)，「由一個(gè)全局的事務(wù)管理器協(xié)調(diào)各個(gè)子系統(tǒng)的局部事務(wù)管理器完成兩階段提交」。

這個(gè)協(xié)議有「兩個(gè)角色」，

A節(jié)點(diǎn)是事務(wù)的協(xié)調(diào)者，B和C是事務(wù)的參與者。

事務(wù)的提交分成兩個(gè)階段

第一個(gè)階段是「投票階段」

• 1.協(xié)調(diào)者首先將命令「寫入日志」
• 2. 「發(fā)一個(gè)prepare命令」給B和C節(jié)點(diǎn)這兩個(gè)參與者
• 3.B和C收到消息后，根據(jù)自己的實(shí)際情況，「判斷自己的實(shí)際情況是否可以提交」
• 4.將處理結(jié)果「記錄到日志」系統(tǒng)
• 5.將結(jié)果「返回」給協(xié)調(diào)者

第二個(gè)階段是「決定階段」

當(dāng)A節(jié)點(diǎn)收到B和C參與者所有的確認(rèn)消息后

• 「判斷」所有協(xié)調(diào)者「是否都可以提交」
• 如果可以則「寫入日志」并且發(fā)起commit命令
• 有一個(gè)不可以則「寫入日志」并且發(fā)起abort命令
• 參與者收到協(xié)調(diào)者發(fā)起的命令，「執(zhí)行命令」
• 將執(zhí)行命令及結(jié)果「寫入日志」
• 「返回結(jié)果」給協(xié)調(diào)者

可能會(huì)存在哪些問(wèn)題？

• 「單點(diǎn)故障」：一旦事務(wù)管理器出現(xiàn)故障，整個(gè)系統(tǒng)不可用

• 「數(shù)據(jù)不一致」：在階段二，如果事務(wù)管理器只發(fā)送了部分 commit 消息，此時(shí)網(wǎng)絡(luò)發(fā)生異常，那么只有部分參與者接收到 commit 消息，也就是說(shuō)只有部分參與者提交了事務(wù)，使得系統(tǒng)數(shù)據(jù)不一致。

• 「響應(yīng)時(shí)間較長(zhǎng)」：整個(gè)消息鏈路是串行的，要等待響應(yīng)結(jié)果，不適合高并發(fā)的場(chǎng)景

• 「不確定性」：當(dāng)事務(wù)管理器發(fā)送 commit 之后，并且此時(shí)只有一個(gè)參與者收到了 commit，那么當(dāng)該參與者與事務(wù)管理器同時(shí)宕機(jī)之后，重新選舉的事務(wù)管理器無(wú)法確定該條消息是否提交成功。

三階段提交（3PC）

三階段提交又稱3PC，相對(duì)于2PC來(lái)說(shuō)增加了CanCommit階段和超時(shí)機(jī)制。如果段時(shí)間內(nèi)沒(méi)有收到協(xié)調(diào)者的commit請(qǐng)求，那么就會(huì)自動(dòng)進(jìn)行commit，解決了2PC單點(diǎn)故障的問(wèn)題。

但是性能問(wèn)題和不一致問(wèn)題仍然沒(méi)有根本解決。下面我們還是一起看下三階段流程的是什么樣的？

• 第一階段：「CanCommit階段」這個(gè)階段所做的事很簡(jiǎn)單，就是協(xié)調(diào)者詢問(wèn)事務(wù)參與者，你是否有能力完成此次事務(wù)。

• 如果都返回yes，則進(jìn)入第二階段
• 有一個(gè)返回no或等待響應(yīng)超時(shí)，則中斷事務(wù)，并向所有參與者發(fā)送abort請(qǐng)求

• 第二階段：「PreCommit階段」此時(shí)協(xié)調(diào)者會(huì)向所有的參與者發(fā)送PreCommit請(qǐng)求，參與者收到后開始執(zhí)行事務(wù)操作，并將Undo和Redo信息記錄到事務(wù)日志中。參與者執(zhí)行完事務(wù)操作后（此時(shí)屬于未提交事務(wù)的狀態(tài)），就會(huì)向協(xié)調(diào)者反饋“Ack”表示我已經(jīng)準(zhǔn)備好提交了，并等待協(xié)調(diào)者的下一步指令。

• 第三階段：「DoCommit階段」在階段二中如果所有的參與者節(jié)點(diǎn)都可以進(jìn)行PreCommit提交，那么協(xié)調(diào)者就會(huì)從“預(yù)提交狀態(tài)”轉(zhuǎn)變?yōu)椤疤峤粻顟B(tài)”。然后向所有的參與者節(jié)點(diǎn)發(fā)送"doCommit"請(qǐng)求，參與者節(jié)點(diǎn)在收到提交請(qǐng)求后就會(huì)各自執(zhí)行事務(wù)提交操作，并向協(xié)調(diào)者節(jié)點(diǎn)反饋“Ack”消息，協(xié)調(diào)者收到所有參與者的Ack消息后完成事務(wù)。相反，如果有一個(gè)參與者節(jié)點(diǎn)未完成PreCommit的反饋或者反饋超時(shí)，那么協(xié)調(diào)者都會(huì)向所有的參與者節(jié)點(diǎn)發(fā)送abort請(qǐng)求，從而中斷事務(wù)。

補(bǔ)償事務(wù)（TCC）

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

「Try,Confirm,Cancel」

• Try階段主要是對(duì)「業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留」，其主要分為兩個(gè)階段
• Confirm 階段主要是對(duì)「業(yè)務(wù)系統(tǒng)做確認(rèn)提交」，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。
• Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，「預(yù)留資源釋放」。

比如下一個(gè)訂單減一個(gè)庫(kù)存：

執(zhí)行流程：

• Try階段：訂單系統(tǒng)將當(dāng)前訂單狀態(tài)設(shè)置為支付中，庫(kù)存系統(tǒng)校驗(yàn)當(dāng)前剩余庫(kù)存數(shù)量是否大于1，然后將可用庫(kù)存數(shù)量設(shè)置為庫(kù)存剩余數(shù)量-1，
• 如果Try階段「執(zhí)行成功」，執(zhí)行Confirm階段，將訂單狀態(tài)修改為支付成功，庫(kù)存剩余數(shù)量修改為可用庫(kù)存數(shù)量
• 如果Try階段「執(zhí)行失敗」，執(zhí)行Cancel階段，將訂單狀態(tài)修改為支付失敗，可用庫(kù)存數(shù)量修改為庫(kù)存剩余數(shù)量

TCC 事務(wù)機(jī)制相比于上面介紹的2PC，解決了其幾個(gè)缺點(diǎn)：

• 1.「解決了協(xié)調(diào)者單點(diǎn)」，由主業(yè)務(wù)方發(fā)起并完成這個(gè)業(yè)務(wù)活動(dòng)。業(yè)務(wù)活動(dòng)管理器也變成多點(diǎn)，引入集群。
• 2.「同步阻塞」：引入超時(shí)，超時(shí)后進(jìn)行補(bǔ)償，并且不會(huì)鎖定整個(gè)資源，將資源轉(zhuǎn)換為業(yè)務(wù)邏輯形式，粒度變小。
• 3.「數(shù)據(jù)一致性」，有了補(bǔ)償機(jī)制之后，由業(yè)務(wù)活動(dòng)管理器控制一致性

總之，TCC 就是通過(guò)代碼人為實(shí)現(xiàn)了兩階段提交，不同的業(yè)務(wù)場(chǎng)景所寫的代碼都不一樣，并且很大程度的「增加」了業(yè)務(wù)代碼的「復(fù)雜度」，因此，這種模式并不能很好地被復(fù)用。

本地消息表