頂級 top 分布式事務(wù)方案的選擇

• XA/二階段提交
• 3PC
• TCC
• Saga
• 可靠消息最終一致性
• 最大努力通知方案
• 總結(jié)

XA/二階段提交

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

所謂的 XA 方案，即：兩階段提交，有一個事務(wù)管理器 的概念，負(fù)責(zé)協(xié)調(diào)多個數(shù)據(jù)庫（資源管理器）的事務(wù)，事務(wù)管理器先問各個數(shù)據(jù)庫準(zhǔn)備好了嗎？如果每個數(shù)據(jù)庫都回 ok，那就正式提交事務(wù)，在各個數(shù)據(jù)庫上執(zhí)行操作；如果任何其中一個數(shù)據(jù)庫回答不 ok，那么就回滾事務(wù)。這種分布式事務(wù)方案，比較適合單塊應(yīng)用里，跨多個庫的分布式事務(wù)，而且因為嚴(yán)重依賴于數(shù)據(jù)庫層面來搞定復(fù)雜的事務(wù)，效率很低，不適合高并發(fā)的場景。

JTA

JTA只是Java實現(xiàn)XA事務(wù)的一個規(guī)范，全稱Java``事務(wù)規(guī)范JTA（Java Transaction API) ，我們?nèi)粘Ｊ褂玫?code style="margin-right: 2px;margin-left: 2px;padding: 2px 4px;border-radius: 4px;background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;color: rgb(255, 100, 65);">@Transactional。都可以叫JTA事務(wù)管理。實際上，JTA是基于XA架構(gòu)上建模的，對于Spring來說，可以使用如JBoss之類的應(yīng)用服務(wù)器提供的JTA事務(wù)管理器；可以以使用Atomikos、Bitronix等庫提供的JTA事務(wù)管理器。Spring都有封裝，開箱即用。

鏈?zhǔn)?/h4>

對于Spring，還有個鏈?zhǔn)绞聞?wù)管理，就是聲明一個ChainedTransactionManager 將所有的數(shù)據(jù)源事務(wù)按順序放到該對象中，則事務(wù)會按相反的順序來執(zhí)行事務(wù)。事務(wù)依次提交后提交的事務(wù)若出錯不能回滾。

1.start message transaction
2.receive message
3.start database transaction
4.update database
5.commit database transaction
6.commit message transaction   ##當(dāng)這一步出現(xiàn)錯誤時，上面的因為已經(jīng)commit，所以不會rollback

和JTA比起來，更輕量，但只能單機用。

參考

這個方案，很少用，一般來說某個系統(tǒng)內(nèi)部如果出現(xiàn)跨多個庫 的這么一個操作，是不合規(guī) 的。我可以給大家介紹一下， 現(xiàn)在微服務(wù)，一個大的系統(tǒng)分成幾十個甚至幾百個服務(wù)。一般來說，我們的規(guī)定和規(guī)范，是要求每個服務(wù)只能操作自己對應(yīng)的一個數(shù)據(jù)庫 。如果你要操作別的服務(wù)對應(yīng)的庫，不允許直連別的服務(wù)的庫，違反微服務(wù)架構(gòu)的規(guī)范，你隨便交叉胡亂訪問，幾百個服務(wù)的話，全體亂套，這樣的一套服務(wù)是沒法管理的，沒法治理的，可能會出現(xiàn)數(shù)據(jù)被別人改錯，自己的庫被別人寫掛等情況。如果你要操作別人的服務(wù)的庫，你必須是通過調(diào)用別的服務(wù)的接口 來實現(xiàn)，絕對不允許交叉訪問別人的數(shù)據(jù)庫。

問題

• 同步阻塞問題 ：二階段提交算法在執(zhí)行過程中，所有參與節(jié)點都是事務(wù)阻塞型的。也就是說，當(dāng)本地資源管理器占有臨界資源時，其他資源管理器如果要訪問同一臨界資源，會處于阻塞狀態(tài)。
• 單點故障問題： 基于 XA 的二階段提交算法類似于集中式算法，一旦事務(wù)管理器發(fā)生故障，整個系統(tǒng)都處于停滯狀態(tài)。尤其是在提交階段，一旦事務(wù)管理器發(fā)生故障，資源管理器會由于等待管理器的消息，而一直鎖定事務(wù)資源，導(dǎo)致整個系統(tǒng)被阻塞。
• 數(shù)據(jù)不一致問題： 在提交階段，當(dāng)協(xié)調(diào)者向參與者發(fā)送 DoCommit 請求之后，如果發(fā)生了局部網(wǎng)絡(luò)異常，或者在發(fā)送提交請求的過程中協(xié)調(diào)者發(fā)生了故障，就會導(dǎo)致只有一部分參與者接收到了提交請求并執(zhí)行提交操作，但其他未接到提交請求的那部分參與者則無法執(zhí)行事務(wù)提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的問題。

3PC

三階段提交協(xié)議（Three-phase commit protocol，3PC），是對二階段提交（2PC）的改進。為了解決兩階段提交的同步阻塞和數(shù)據(jù)不一致問題，三階段提交引入了超時機制和準(zhǔn)備階段 。

• 同時在協(xié)調(diào)者和參與者中引入超時機制。如果協(xié)調(diào)者或參與者在規(guī)定的時間內(nèi)沒有接收到來自其他節(jié)點的響應(yīng)，就會根據(jù)當(dāng)前的狀態(tài)選擇提交或者終止整個事務(wù)。
• 在第一階段和第二階段中間引入了一個準(zhǔn)備階段，也就是在提交階段之前，加入了一個預(yù)提交階段。在預(yù)提交階段排除一些不一致的情況，保證在最后提交之前各參與節(jié)點的狀態(tài)是一致的。

也就是說，除了引入超時機制之外，3PC 把 2PC 的提交階段一分為二，這樣三階段提交協(xié)議就有 CanCommit、PreCommit、DoCommit 三個階段。

canCommit

precommit

• 如果所有參與者回復(fù)的都是“Yes”，那么協(xié)調(diào)者就會執(zhí)行事務(wù)的預(yù)執(zhí)行：
• 發(fā)送預(yù)提交請求。 協(xié)調(diào)者向參與者發(fā)送 PreCommit 請求，進入預(yù)提交階段。
• 事務(wù)預(yù)提交 。參與者接收到 PreCommit 請求后執(zhí)行事務(wù)操作，并將 Undo 和 Redo 信息記錄到事務(wù)日志中。
• 響應(yīng)反饋 。如果參與者成功執(zhí)行了事務(wù)操作，則返回 ACK 響應(yīng)，同時開始等待最終指令。
• 假如任何一個參與者向協(xié)調(diào)者發(fā)送了“No”消息，或者等待超時之后，協(xié)調(diào)者都沒有收到參與者的響應(yīng)，就執(zhí)行中斷事務(wù)的操作：
• 發(fā)送中斷請求 。協(xié)調(diào)者向所有參與者發(fā)送“Abort”消息。
• 終斷事務(wù) 。參與者收到“Abort”消息之后，或超時后仍未收到協(xié)調(diào)者的消息，執(zhí)行事務(wù)的終斷操作。

doCommit

DoCmmit 階段進行真正的事務(wù)提交，根據(jù) PreCommit 階段協(xié)調(diào)者發(fā)送的消息，進入執(zhí)行提交階段或事務(wù)中斷階段。

• 執(zhí)行提交階段：
• 發(fā)送提交請求。協(xié)調(diào)者接收到所有參與者發(fā)送的 Ack 響應(yīng)，從預(yù)提交狀態(tài)進入到提交狀態(tài)，并向所有參與者發(fā)送 DoCommit 消息。
• 事務(wù)提交。參與者接收到 DoCommit 消息之后，正式提交事務(wù)。完成事務(wù)提交之后，釋放所有鎖住的資源。
• 響應(yīng)反饋。參與者提交完事務(wù)之后，向協(xié)調(diào)者發(fā)送 Ack 響應(yīng)。
• 完成事務(wù)。協(xié)調(diào)者接收到所有參與者的 Ack 響應(yīng)之后，完成事務(wù)。
• 事務(wù)中斷階段：
• 發(fā)送中斷請求。協(xié)調(diào)者向所有參與者發(fā)送 Abort 請求。
• 事務(wù)回滾。參與者接收到 Abort 消息之后，利用其在 PreCommit 階段記錄的 Undo 信息執(zhí)行事務(wù)的回滾操作，并釋放所有鎖住的資源。
• 反饋結(jié)果。參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息。

)

TCC

TCC 的全稱是：Try 、 Confirm 、 Cancel 。

• Try 階段：這個階段說的是對各個服務(wù)的資源做檢測以及對資源進行鎖定或者預(yù)留 。
• Confirm 階段：這個階段說的是在各個服務(wù)中執(zhí)行實際的操作 。
• Cancel 階段：如果任何一個服務(wù)的業(yè)務(wù)方法執(zhí)行出錯，那么這里就需要進行補償 ，就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務(wù)邏輯的回滾操作。

這種方案說實話幾乎很少人使用。因為這個事務(wù)回滾 實際上是嚴(yán)重依賴于你自己寫代碼來回滾和補償 了，會造成補償代碼巨大，非常之惡心。等于一個借口拆成三個。一般來說跟錢 相關(guān)的，支付 、交易 ，會用 TCC，嚴(yán)格保證分布式事務(wù)要么全部成功，要么全部自動回滾，嚴(yán)格保證資金正確。而且最好是各個業(yè)務(wù)執(zhí)行的時間都比較短。

Saga

金融核心等業(yè)務(wù)可能會選擇 TCC 方案，以追求強一致性和更高的并發(fā)量，而對于更多的金融核心以下的業(yè)務(wù)系統(tǒng) 往往會選擇補償事務(wù)，補償事務(wù)處理在 30 多年前就提出了 Saga 理論，隨著微服務(wù)的發(fā)展，近些年才逐步受到大家的關(guān)注。目前業(yè)界比較公認(rèn)的是采用 Saga 作為長事務(wù)的解決方案。

基本原理

業(yè)務(wù)流程中每個參與者都提交本地事務(wù)，若某一個參與者失敗，則補償前面已經(jīng)成功的參與者。下圖左側(cè)是正常的事務(wù)流程，當(dāng)執(zhí)行到 T3 時發(fā)生了錯誤，則開始執(zhí)行右邊的事務(wù)補償流程，反向執(zhí)行 T3、T2、T1 的補償服務(wù) C3、C2、C1，將 T3、T2、T1 已經(jīng)修改的數(shù)據(jù)補償?shù)簟?/p>

使用場景

對于一致性要求高、短流程、并發(fā)高 的場景，如：金融核心系統(tǒng)，會優(yōu)先考慮 TCC 方案。而在另外一些場景下，我們并不需要這么強的一致性，只需要保證最終一致性即可。比如 很多金融核心以上的業(yè)務(wù)（渠道層、產(chǎn)品層、系統(tǒng)集成層），這些系統(tǒng)的特點是最終一致即可、流程多、流程長、還可能要調(diào)用其它公司的服務(wù)。這種情況如果選擇 TCC 方案開發(fā)的話，一來成本高，二來無法要求其它公司的服務(wù)也遵循 TCC 模式。同時流程長，事務(wù)邊界太長，加鎖時間長，也會影響并發(fā)性能。所以 Saga 模式的適用場景是：

• 業(yè)務(wù)流程長、業(yè)務(wù)流程多；
• 參與者包含其它公司或遺留系統(tǒng)服務(wù)，無法提供 TCC 模式要求的三個接口。

優(yōu)勢

• 一階段提交本地事務(wù)，無鎖，高性能；
• 參與者可異步執(zhí)行，高吞吐；
• 補償服務(wù)易于實現(xiàn)，因為一個更新操作的反向操作是比較容易理解的。

缺點

• 不保證事務(wù)的隔離性。

可靠消息最終一致性

流程

1. A 系統(tǒng)先發(fā)送一個 prepared 消息到 mq，如果這個 prepared 消息發(fā)送失敗那么就直接取消操作別執(zhí)行了；
2. 如果這個消息發(fā)送成功過了，那么接著執(zhí)行本地事務(wù)，如果成功就告訴 mq 發(fā)送確認(rèn)消息，如果失敗就告訴 mq 回滾消息；
3. 如果發(fā)送了確認(rèn)消息，那么此時 B 系統(tǒng)會接收到確認(rèn)消息，然后執(zhí)行本地的事務(wù)；
4. mq 會自動定時輪詢 所有 prepared 消息回調(diào)你的接口，問你，這個消息是不是本地事務(wù)處理失敗了，所有沒發(fā)送確認(rèn)的消息，是繼續(xù)重試還是回滾？一般來說這里你就可以查下數(shù)據(jù)庫看之前本地事務(wù)是否執(zhí)行，如果回滾了，那么這里也回滾吧。這個就是避免可能本地事務(wù)執(zhí)行成功了，而確認(rèn)消息卻發(fā)送失敗了。
5. 這個方案里，要是系統(tǒng) B 的事務(wù)失敗了咋辦？重試咯，自動不斷重試直到成功，如果實在是不行，要么就是針對重要的資金類業(yè)務(wù)進行回滾，比如 B 系統(tǒng)本地回滾后，想辦法通知系統(tǒng) A 也回滾；或者是發(fā)送報警由人工來手工回滾和補償。
6. 這個還是比較合適的，目前國內(nèi)互聯(lián)網(wǎng)公司大都是這么玩兒的，要不你就用 RocketMQ 支持的，要不你就自己基于類似 ActiveMQ？RabbitMQ？自己封裝一套類似的邏輯出來，總之思路就是這樣子的。

下單為例

以下單為例

1. 訂單系統(tǒng)把訂單消息發(fā)給消息中間件，消息狀態(tài)標(biāo)記為“待確認(rèn)”。
2. 消息中間件收到消息后，進行消息持久化操作，即在消息存儲系統(tǒng)中新增一條狀態(tài)為“待發(fā)送”的消息。
3. 消息中間件返回消息持久化結(jié)果（成功 / 失?。唵蜗到y(tǒng)根據(jù)返回結(jié)果判斷如何進行業(yè)務(wù)操作。失敗，放棄訂單，結(jié)束（必要時向上層返回失敗結(jié)果）；成功，則創(chuàng)建訂單。
4. 訂單操作完成后，把操作結(jié)果（成功 / 失敗）發(fā)送給消息中間件。
5. 消息中間件收到業(yè)務(wù)操作結(jié)果后，根據(jù)結(jié)果進行處理：失敗，刪除消息存儲中的消息，結(jié)束；成功，則更新消息存儲中的消息狀態(tài)為“待發(fā)送（可發(fā)送）”，并執(zhí)行消息投遞。
6. 如果消息狀態(tài)為“可發(fā)送”，則 MQ 會將消息發(fā)送給支付系統(tǒng)，表示已經(jīng)創(chuàng)建好訂單，需要對訂單進行支付。支付系統(tǒng)也按照上述方式進行訂單支付操作。
7. 訂單系統(tǒng)支付完成后，會將支付消息返回給消息中間件，中間件將消息傳送給訂單系統(tǒng)。訂單系統(tǒng)再調(diào)用庫存系統(tǒng)，進行出貨操作。

最大努力通知方案

這個方案的大致意思就是：

1. 系統(tǒng) A 本地事務(wù)執(zhí)行完之后，發(fā)送個消息到 MQ；
2. 這里會有個專門消費 MQ 的最大努力通知服務(wù) ，這個服務(wù)會消費 MQ 然后寫入數(shù)據(jù)庫中記錄下來，或者是放入個內(nèi)存隊列也可以，接著調(diào)用系統(tǒng) B 的接口；
3. 要是系統(tǒng) B 執(zhí)行成功就 ok 了；要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時嘗試重新調(diào)用系統(tǒng) B，反復(fù) N 次，最后還是不行就放棄。

總結(jié)

一般來說，最嚴(yán)格的就是TCC。其他常用的是基于消息的最終一致性。

ACID

Base理論

BASE 理論包括基本可用（Basically Available）、柔性狀態(tài)（Soft State）和最終一致性（Eventual Consistency）。

• 基本可用：分布式系統(tǒng)出現(xiàn)故障的時候，允許損失一部分功能的可用性。比如，某些電商 618 大促的時候，會對一些非核心鏈路的功能進行降級處理。
• 柔性狀態(tài)：在柔性事務(wù)中，允許系統(tǒng)存在中間狀態(tài)，且這個中間狀態(tài)不會影響系統(tǒng)整體可用性。比如，數(shù)據(jù)庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會有一個延時，其實就是一種柔性狀態(tài)。
• 最終一致性：事務(wù)在操作過程中可能會由于同步延遲等問題導(dǎo)致不一致，但最終狀態(tài)下，數(shù)據(jù)都是一致的。

可見，BASE 理論為了支持大型分布式系統(tǒng)，通過犧牲強一致性，保證最終一致性，來獲得高可用性，是對 ACID 原則的弱化。具體到今天的三種分布式事務(wù)實現(xiàn)方式，二階段提交、三階段提交方法，遵循的是 ACID 原則，而消息最終一致性方案遵循的就是 BASE 理論。

長按二維碼，掃掃關(guān)注哦