1. 引言

大家好，我是小?，一個(gè)漂泊江湖多年的 985 非科班程序員，曾混跡于國(guó)企、互聯(lián)網(wǎng)大廠和創(chuàng)業(yè)公司的后臺(tái)開發(fā)攻城獅。

今天，小?將帶大家探討分布式事務(wù)里的“八奇技”，幫助大家在實(shí)際的分布式系統(tǒng)中更好地運(yùn)用事務(wù)。

2. 分布式事務(wù)常見的解決分案

分布式事務(wù)是在分布式系統(tǒng)中，跨越多個(gè)計(jì)算機(jī)節(jié)點(diǎn)或數(shù)據(jù)存儲(chǔ)系統(tǒng)進(jìn)行的事務(wù)，在這種環(huán)境下保證事務(wù)的ACID（原子性、一致性、隔離性、持久性）屬性是一大挑戰(zhàn)。

對(duì)此，業(yè)界有以下 8 種常見的解決方案，俗稱 “八奇技”。

奇技1）2PC

二階段提交協(xié)議（Two-phase commit protocol），簡(jiǎn)稱 2PC。兩階段提交是一種強(qiáng)一致性事務(wù)協(xié)議，它分為準(zhǔn)備階段和提交階段。

圖片

在準(zhǔn)備階段，協(xié)調(diào)者節(jié)點(diǎn)詢問所有參與者是否準(zhǔn)備好提交事務(wù)，如果所有參與者都答應(yīng)準(zhǔn)備好了，那么在提交階段，協(xié)調(diào)者會(huì)通知所有參與者提交事務(wù)。

如果有任何一個(gè)參與者在準(zhǔn)備階段沒有準(zhǔn)備好，那么協(xié)調(diào)者會(huì)通知所有參與者回滾事務(wù)。

有熟悉 MySQL 的同學(xué)可能馬上想到了，MySQL 的事務(wù)提交就是通過幾種日志來實(shí)現(xiàn)二階段提交的。

不了解MySQL執(zhí)行流程的可以看我之前寫的這篇文章：一張圖看懂SQL執(zhí)行流程

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

1. 原子性保證：2PC 協(xié)議可以保證所有參與者要么全部提交成功，要么全部失敗回滾，從而實(shí)現(xiàn)跨多個(gè)分布式節(jié)點(diǎn)的事務(wù)的原子性。
2. 簡(jiǎn)單直觀：2PC 的設(shè)計(jì)思路簡(jiǎn)單，邏輯清晰，容易理解，這使得它在很多傳統(tǒng)的數(shù)據(jù)庫和分布式系統(tǒng)中得到了廣泛的應(yīng)用，比如 MySQL 從 5.5 版本開始支持。

缺點(diǎn)

1. 同步阻塞：在 2PC 的第一階段，所有參與者在響應(yīng)協(xié)調(diào)者的準(zhǔn)備請(qǐng)求后，必須等待最終的提交或回滾指令。這期間，所有參與者都處于阻塞狀態(tài)，無法進(jìn)行其他操作，導(dǎo)致資源鎖定時(shí)間較長(zhǎng)，在高并發(fā)場(chǎng)景下很明顯不太適用。
2. 單點(diǎn)故障：如果協(xié)調(diào)者在第二階段崩潰，參與者可能會(huì)無限期地等待指令，因?yàn)樗鼈儾恢缿?yīng)該提交還是回滾。這使得整個(gè)系統(tǒng)容易受到單點(diǎn)故障的影響。
3. 數(shù)據(jù)不一致：如果在第二階段中協(xié)調(diào)者向某些參與者發(fā)送了提交指令，而其他參與者因?yàn)榫W(wǎng)絡(luò)問題沒有收到指令，那么這些沒有收到指令的參與者可能會(huì)選擇回滾，導(dǎo)致數(shù)據(jù)不一致。
4. 復(fù)雜的恢復(fù)機(jī)制：當(dāng)系統(tǒng)崩潰后，恢復(fù)過程非常復(fù)雜，所有參與者必須保持足夠的信息以便在系統(tǒng)恢復(fù)后能夠繼續(xù)完成 2PC 協(xié)議。

奇技2）3PC

三階段提交協(xié)議（Three-phase commit protocol），簡(jiǎn)稱 3PC。三階段提交（3PC）是兩階段提交（2PC）的改進(jìn)版本，它旨在減少在協(xié)調(diào)者和參與者之間的阻塞時(shí)間，同時(shí)增加系統(tǒng)在某些故障情況下的容錯(cuò)能力，以下是 3PC 的三個(gè)階段：

1. CanCommit 階段

協(xié)調(diào)者行動(dòng): 發(fā)送 CanCommit 請(qǐng)求到所有參與者，并等待回應(yīng)。

參與者行動(dòng): 如果參與者可以提交事務(wù)，它就返回 Yes，并進(jìn)入預(yù)備狀態(tài)；如果不能提交，則返回 No。

2. PreCommit 階段

• 協(xié)調(diào)者行動(dòng): 如果所有參與者回答 Yes，協(xié)調(diào)者發(fā)送 PreCommit 請(qǐng)求給所有參與者，并進(jìn)入 Prepared 階段；如果有任何參與者回答 No，或者等待超時(shí)，協(xié)調(diào)者發(fā)送 abort 請(qǐng)求。

• 參與者行動(dòng): 在收到 PreCommit 請(qǐng)求后，參與者會(huì)執(zhí)行事務(wù)操作，寫入日志，但不提交，然后響應(yīng) ACK，并等待最終指令。如果參與者在這個(gè)階段超時(shí)沒有收到協(xié)調(diào)者的消息，它將中止事務(wù)。

3. DoCommit 階段

• 協(xié)調(diào)者行動(dòng): 一旦協(xié)調(diào)者收到所有參與者的 ACK，它會(huì)進(jìn)入 DoCommit 階段，發(fā)送 commit 請(qǐng)求給所有參與者。

• 參與者行動(dòng): 參與者在收到 commit 請(qǐng)求后，提交事務(wù)，釋放所有事務(wù)鎖定的資源，并向協(xié)調(diào)者發(fā)送完成消息。

與 2PC 相比，3PC 在 PreCommit 階段引入了超時(shí)機(jī)制，允許參與者在沒有接收到協(xié)調(diào)者的最終指令時(shí)自行決定中止事務(wù)，這減少了協(xié)調(diào)者成為單點(diǎn)故障的可能性。

實(shí)際業(yè)務(wù)場(chǎng)景

3PC通常用于需要較高可靠性的分布式系統(tǒng)中，尤其是在那些不能接受長(zhǎng)時(shí)間鎖定資源的場(chǎng)景。例如：

1. 分布式數(shù)據(jù)庫系統(tǒng)：分布式數(shù)據(jù)庫可能使用 3PC 來確?？缍鄠€(gè)數(shù)據(jù)中心的事務(wù)一致性。例如，一個(gè)全球性的銀行可能需要在不同國(guó)家的分支機(jī)構(gòu)之間處理賬戶轉(zhuǎn)賬，這時(shí)3PC可以減少在網(wǎng)絡(luò)延遲或某個(gè)分支機(jī)構(gòu)失去響應(yīng)時(shí)的影響。
2. 電信網(wǎng)絡(luò)：在電信運(yùn)營(yíng)商的計(jì)費(fèi)系統(tǒng)中，可能會(huì)使用 3PC 來同步跨多個(gè)服務(wù)點(diǎn)的賬單信息，這些系統(tǒng)通常要求高可用性和快速響應(yīng)，因此不能長(zhǎng)時(shí)間阻塞。
3. 大型分布式系統(tǒng)：對(duì)于需要跨多個(gè)服務(wù)和組件協(xié)調(diào)工作的大型分布式系統(tǒng)，比如云計(jì)算平臺(tái)，3PC可以在保持事務(wù)一致性的同時(shí)，減少參與者等待協(xié)調(diào)者指令的時(shí)間。

使用 3PC 的考慮因素

雖然 3PC 提供了比 2PC 更好的容錯(cuò)性和減少了阻塞的時(shí)間，但它仍然有一些缺點(diǎn)：

• 復(fù)雜性：3PC 比 2PC 更復(fù)雜，需要更多的消息交換和更多的狀態(tài)管理。
• 性能開銷：3PC 引入了額外的階段和網(wǎng)絡(luò)通信，可能會(huì)導(dǎo)致更大的性能開銷。
• 極端情況：即使是 3PC，在某些極端的網(wǎng)絡(luò)分區(qū)或多點(diǎn)故障情況下也可能無法保證事務(wù)的正確性。

因此，在實(shí)際應(yīng)用中，需要權(quán)衡 3PC 帶來的好處與其復(fù)雜性和性能開銷之間的關(guān)系，確保它適合特定的業(yè)務(wù)場(chǎng)景和系統(tǒng)需求。

在某些情況下，其他的事務(wù)模型，如最大努力通知等最終一致性模型，可能會(huì)是更合適的選擇。

奇技3）TCC

TCC（Try-Confirm-Cancel）是一種應(yīng)用層的分布式事務(wù)解決方案，它將事務(wù)分為三個(gè)步驟：嘗試（Try）、確認(rèn)（Confirm）和取消（Cancel）：

• 在 Try 階段，會(huì)預(yù)留必要的業(yè)務(wù)資源；
• 在 Confirm 階段，如果所有相關(guān)的業(yè)務(wù)操作都成功了，則正式執(zhí)行業(yè)務(wù)操作；
• 如果有操作失敗，則在 Cancel 階段執(zhí)行補(bǔ)償操作，回滾之前的預(yù)留資源。

圖片

假設(shè)我們買一張從深圳到北京的火車票，票價(jià)為 360 元，TCC 分為這三個(gè)步驟：

• Try：檢查錢包的錢是否大于等于 360，并鎖住資源（360 元和這張車票）；
• Cancel：如果有一個(gè)資源鎖定失敗，則進(jìn)行 cancel 釋放資源，這個(gè)過程中無論 cancel 還是其它操作失敗都進(jìn)行重試 cancel，所以需要保證冪等性；
• Confirm：如果資源鎖定都成功，則進(jìn)行 confirm，資源交換，這個(gè)過程中無論 confirm 還是其它操作失敗都進(jìn)行重試 confirm，都需保證冪等性。

優(yōu)勢(shì)

TCC 的出現(xiàn)解決二階段提交的幾個(gè)缺點(diǎn)：

1. 單點(diǎn)故障問題：引入了多個(gè)業(yè)務(wù)活動(dòng)管理器，集群下高可用；
2. 數(shù)據(jù)不一致問題：引入超時(shí)補(bǔ)償機(jī)制，由業(yè)務(wù)活動(dòng)管理器來控制一致性；
3. 同步阻塞問題：引入超時(shí)補(bǔ)償機(jī)制，不會(huì)鎖定同步，將資源轉(zhuǎn)換為業(yè)務(wù)邏輯形式，粒度更小。

奇技4）分布式補(bǔ)償事務(wù)（Saga）

Saga 是一種長(zhǎng)事務(wù)的解決方案，它將一個(gè)大的分布式事務(wù)拆分成多個(gè)較小的本地事務(wù)，這些本地事務(wù)通過異步消息傳遞串聯(lián)起來。

每個(gè)本地事務(wù)執(zhí)行成功后，會(huì)發(fā)送消息觸發(fā)下一個(gè)事務(wù)的執(zhí)行。如果某個(gè)本地事務(wù)失敗，Saga 會(huì)執(zhí)行一系列補(bǔ)償操作（回滾之前的操作）來保持?jǐn)?shù)據(jù)的一致性。

假設(shè)有一個(gè)旅游網(wǎng)站，用戶可以通過它預(yù)訂機(jī)票、酒店和租車服務(wù)。每個(gè)預(yù)訂步驟都可以視為一個(gè) Saga 中的小事務(wù)：

1. 用戶預(yù)訂機(jī)票。
2. 用戶預(yù)訂酒店。
3. 用戶預(yù)訂租車服務(wù)。

如果用戶成功完成了所有預(yù)訂步驟，那么整個(gè)旅行預(yù)訂就完成了。但如果在預(yù)訂租車服務(wù)時(shí)失敗了，那么 Saga 會(huì)開始執(zhí)行補(bǔ)償操作：

1. 取消酒店預(yù)訂。
2. 取消機(jī)票預(yù)訂。

通過這種方式，Saga 確保了用戶不會(huì)因?yàn)椴糠址?wù)預(yù)訂失敗而損失金錢或留下未處理的預(yù)訂。

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

1. 靈活性：Saga 允許每個(gè)小事務(wù)獨(dú)立管理，提高了系統(tǒng)的靈活性。
2. 減少資源鎖定：由于 Saga 不需要在事務(wù)執(zhí)行過程中持續(xù)占用資源，因此可以減少長(zhǎng)時(shí)間的資源鎖定，提高系統(tǒng)的并發(fā)能力。
3. 容錯(cuò)性：Saga 通過定義補(bǔ)償操作來處理失敗，增強(qiáng)了系統(tǒng)的容錯(cuò)能力。
4. 適用于微服務(wù)架構(gòu)：在微服務(wù)架構(gòu)中，Saga 可以跨服務(wù)邊界管理事務(wù)，每個(gè)服務(wù)獨(dú)立處理自己的事務(wù)和補(bǔ)償邏輯。

缺點(diǎn)

1. 復(fù)雜性：實(shí)現(xiàn) Saga 需要定義每個(gè)小事務(wù)的補(bǔ)償操作，這可能會(huì)增加系統(tǒng)的復(fù)雜性。
2. 數(shù)據(jù)一致性：Saga 不能提供 2PC 那樣的即時(shí)一致性保證，它只能保證最終一致性，這在某些業(yè)務(wù)場(chǎng)景中可能是不夠的。
3. 補(bǔ)償操作的難度：在某些情況下，補(bǔ)償操作可能很難實(shí)現(xiàn)，尤其是當(dāng)事務(wù)有副作用時(shí)（比如發(fā)送了一個(gè)不可撤銷的通知）。
4. 測(cè)試和調(diào)試：由于 Saga 涉及多個(gè)服務(wù)和補(bǔ)償邏輯，測(cè)試和調(diào)試可能會(huì)更加困難。

在選擇使用 Saga 模式時(shí)，需要仔細(xì)考慮業(yè)務(wù)場(chǎng)景是否適合最終一致性，以及是否能夠有效地實(shí)現(xiàn)和管理補(bǔ)償邏輯。對(duì)于那些需要高度一致性保證的場(chǎng)景，可能需要考慮其他事務(wù)管理機(jī)制。

奇技5）分布式鎖

在某些情況下，可以使用分布式鎖來確保多個(gè)分布式節(jié)點(diǎn)不會(huì)同時(shí)操作同一資源。這可以通過 Redis、ZooKeeper 等分布式協(xié)調(diào)服務(wù)來實(shí)現(xiàn)。

不知道分布式鎖或者不了解如何實(shí)現(xiàn)的，可以看這篇文章：說出來你可能不信，分布式鎖竟然這么簡(jiǎn)單...

• 項(xiàng)目/公司: 使用 Redis、ZooKeeper 等實(shí)現(xiàn)分布式鎖的系統(tǒng)。
• 實(shí)用場(chǎng)景: 在電商秒殺活動(dòng)中，防止超賣現(xiàn)象，確保同一時(shí)間只有一個(gè)請(qǐng)求能夠?qū)齑鏀?shù)量進(jìn)行修改。
• 推薦場(chǎng)景: 當(dāng)需要協(xié)調(diào)多個(gè)節(jié)點(diǎn)對(duì)共享資源進(jìn)行訪問控制時(shí)，分布式鎖是一個(gè)有效的解決方案。

奇技6）本地消息表

圖片

本地消息表是一種確保分布式事務(wù)最終一致性的方法。它的工作原理是：

1. 在執(zhí)行本地事務(wù)的同時(shí)，將需要異步執(zhí)行的遠(yuǎn)程服務(wù)調(diào)用相關(guān)信息存儲(chǔ)在同一個(gè)本地?cái)?shù)據(jù)庫的消息表中。
2. 本地事務(wù)和消息表的寫入操作在同一個(gè)數(shù)據(jù)庫事務(wù)中完成，這樣可以保證要么都成功，要么都失敗，從而保證了數(shù)據(jù)的一致性。
3. 本地事務(wù)提交后，一個(gè)獨(dú)立的消息發(fā)布程序會(huì)定期掃描消息表，對(duì)于未處理的消息，發(fā)布到消息隊(duì)列或直接調(diào)用遠(yuǎn)程服務(wù)。
4. 遠(yuǎn)程服務(wù)處理完成后，消息會(huì)被標(biāo)記為已處理，從而確保每條消息只被處理一次。

本地消息表是 ebay 公司提出的事務(wù)解決方案，它的核心原理是將需要分布式處理的任務(wù)通過消息日志的方式來異步執(zhí)行。消息日志可以存儲(chǔ)到本地文件、數(shù)據(jù)庫或消息隊(duì)列，再通過業(yè)務(wù)規(guī)則或人工發(fā)起重試。

本地消息表基于 BASE 理論，實(shí)現(xiàn)數(shù)據(jù)的最終一致性，實(shí)現(xiàn)過程中需要注意冪等性原則。

奇技7）可靠消息最終一致性

通過可靠消息服務(wù)保證消息的可靠傳輸，并在消息消費(fèi)者那里進(jìn)行本地事務(wù)處理，從而實(shí)現(xiàn)最終一致性，所以又被稱作消息事務(wù)。如果消息處理失敗，可以重試或者進(jìn)行人工干預(yù)。

執(zhí)行流程：

• 發(fā)送 prepare 消息到消息中間件
• 發(fā)送成功后，執(zhí)行本地事務(wù)

如果事務(wù)執(zhí)行成功，則 commit，消息中間件將消息下發(fā)至消費(fèi)端

如果事務(wù)執(zhí)行失敗，則回滾，消息中間件將這條 prepare 消息刪除

• 消費(fèi)端接收到消息進(jìn)行消費(fèi)，如果消費(fèi)失敗，則不斷重試

這種方案也是實(shí)現(xiàn)了「最終一致性」，和本地消息表類似，但是對(duì)比本地消息表實(shí)現(xiàn)方案，消息事務(wù)不需要再建消息表，而是將消息中間件的機(jī)制去做的，「不再依賴本地?cái)?shù)據(jù)庫事務(wù)」了。

所以這種方案更適用于高并發(fā)的場(chǎng)景，目前市面上實(shí)現(xiàn)該方案的「只有阿里的 RocketMQ」。

奇技8）最大努力通知原則

最大努力通知也是一種基于消息的分布式事務(wù)解決方案，但它不保證 100% 的消息傳遞成功。它的工作原理是：

1. 在本地事務(wù)執(zhí)行成功后，系統(tǒng)會(huì)嘗試通知其他的參與者或服務(wù)。
2. 通知操作會(huì)盡最大努力去執(zhí)行，但如果失敗，系統(tǒng)不會(huì)無限重試。
3. 該方案通常結(jié)合人工干預(yù)，例如，如果通知失敗，系統(tǒng)可能會(huì)記錄日志、發(fā)送報(bào)警、或者提供管理界面供操作人員手動(dòng)處理。

本地消息表，或者通過 MQ 對(duì)事務(wù)進(jìn)行通知都可以算作最大努力。

本地消息表通過后臺(tái)定時(shí)任務(wù)去異步保證數(shù)據(jù)的一致性，就是一種最大努力通知的思想：代表系統(tǒng)各模塊之間已經(jīng)最大程度地保證事務(wù)的最終一致性了。

3. 小結(jié)

在選擇分布式事務(wù)解決方案時(shí)，需要根據(jù)業(yè)務(wù)需求、系統(tǒng)復(fù)雜度、性能要求等因素進(jìn)行權(quán)衡。

例如，對(duì)于業(yè)務(wù)場(chǎng)景要求數(shù)據(jù)的一致性非常高，且可以接受一定程度的性能損失時(shí)，2PC 或者 3PC 是很好的選擇。

對(duì)于復(fù)雜業(yè)務(wù)流程中的分布式事務(wù)，需要在業(yè)務(wù)層進(jìn)行更細(xì)粒度控制時(shí)，TCC 是一個(gè)好的選擇。比如，用戶在電商平臺(tái)下單購(gòu)買商品，涉及到庫存、賬戶余額、積分等多個(gè)服務(wù)的數(shù)據(jù)變更。

而對(duì)于可容忍短時(shí)間內(nèi)數(shù)據(jù)不一致的業(yè)務(wù)，則可以考慮最終一致性相關(guān)的解決方案，如：本地消息表、消息事務(wù)及最大努力通知方案等等。

因此，當(dāng)我們探討分布式事務(wù)時(shí)，不僅要把握好用戶痛點(diǎn)和實(shí)際需求，還要結(jié)合每個(gè)分布式事務(wù)解決方案的特點(diǎn)，才能把 “八奇技” 用到出神入化之境。