我們都是架構(gòu)師！ XA/二階段提交 基 于XA協(xié)議的二階段提交 所 謂的 XA 方案，即： 兩階段提交，有一個(gè) 事務(wù)管理器 的概念，負(fù)責(zé)協(xié)調(diào)多個(gè)數(shù)據(jù)庫（資源管理器）的事務(wù)，事務(wù)管理器先問各個(gè)數(shù)據(jù)庫準(zhǔn)備好了嗎？ 如果每個(gè)數(shù)據(jù)庫都回 ok，那就正式提交事務(wù)，在各個(gè)數(shù)據(jù)庫上執(zhí)行操作； 如果任何其中一個(gè)數(shù)據(jù)庫回答不 ok，那么就回滾事務(wù)。
這種分布式事務(wù)方案，比較適合單塊應(yīng)用里，跨多個(gè)庫的分布式事務(wù)，而且因?yàn)閲?yán)重依賴于數(shù)據(jù)庫層面來搞定復(fù)雜的事務(wù)，效率很低，不適合高并發(fā)的場景。
JTA JTA只是Java實(shí)現(xiàn)XA事務(wù)的一個(gè)規(guī)范，全稱 Java事務(wù)規(guī)范JTA（Java Transaction API) ，我們?nèi)粘Ｊ褂玫?/span>@Transactional。都可以叫JTA事務(wù)管理。 實(shí)際上，JTA是基于XA架構(gòu)上建模的，
對(duì)于Spring來說，可以使用如JBoss之類的應(yīng)用服務(wù)器提供的JTA事務(wù)管理器；可以以使用Atomikos、Bitronix等庫提供的JTA事務(wù)管理器。Spring都有封裝，開箱即用。 鏈?zhǔn)?/h4>對(duì)于Spring，還有個(gè)鏈?zhǔn)绞聞?wù)管理，就是聲明一個(gè)ChainedTransactionManager 將所有的數(shù)據(jù)源事務(wù)按順序放到該對(duì)象中，則事務(wù)會(huì)按相反的順序來執(zhí)行事務(wù)。 事務(wù)依次提交后提交的事務(wù)若出錯(cuò)不能回滾。 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)錯(cuò)誤時(shí)，上面的因?yàn)橐呀?jīng)commit ，所以不會(huì)rollback
參考 這個(gè)方案，很少用，一般來說某個(gè)系統(tǒng)內(nèi)部如果出現(xiàn)跨多個(gè)庫 的這么一個(gè)操作，是不合規(guī) 的。我可以給大家介紹一下， 現(xiàn)在微服務(wù)，一個(gè)大的系統(tǒng)分成幾十個(gè)甚至幾百個(gè)服務(wù)。一般來說，我們的規(guī)定和規(guī)范，是要求每個(gè)服務(wù)只能操作自己對(duì)應(yīng)的一個(gè)數(shù)據(jù)庫 。調(diào)用別的服務(wù)的接口 來實(shí)現(xiàn)，絕對(duì)不允許交叉訪問別人的數(shù)據(jù)庫。 問題 二階段提交算法在執(zhí)行過程中，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。 也就是說，當(dāng)本地資源管理器占有臨界資源時(shí)，其他資源管理器如果要訪問同一臨界資源，會(huì)處于阻塞狀態(tài)。 單點(diǎn)故障問題： 基于 XA 的二階段提交算法類似于集中式算法，一旦事務(wù)管理器發(fā)生故障，整個(gè)系統(tǒng)都處于停滯狀態(tài)。尤其是在提交階段，一旦事務(wù)管理器發(fā)生故障，資源管理器會(huì)由于等待管理器的消息，而一直鎖定事務(wù)資源，導(dǎo)致整個(gè)系統(tǒng)被阻塞。 數(shù)據(jù)不一致問題： 在提交階段，當(dāng)協(xié)調(diào)者向參與者發(fā)送 DoCommit 請求之后，如果發(fā)生了局部網(wǎng)絡(luò)異常，或者在發(fā)送提交請求的過程中協(xié)調(diào)者發(fā)生了故障，就會(huì)導(dǎo)致只有一部分參與者接收到了提交請求并執(zhí)行提交操作，但其他未接到提交請求的那部分參與者則無法執(zhí)行事務(wù)提交。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的問題。 3PC 三階段提交協(xié)議（Three-phase commit protocol，3PC），是對(duì)二階段提交（2PC）的改進(jìn)。為了解決兩階段提交的同步阻塞和數(shù)據(jù)不一致問題，三階段提交引入了超時(shí)機(jī)制和準(zhǔn)備階段 。 同時(shí)在協(xié)調(diào)者和參與者中引入超時(shí)機(jī)制。 如果協(xié)調(diào)者或參與者在規(guī)定的時(shí)間內(nèi)沒有接收到來自其他節(jié)點(diǎn)的響應(yīng)，就會(huì)根據(jù)當(dāng)前的狀態(tài)選擇提交或者終止整個(gè)事務(wù)。 在第一階段和第二階段中間引入了一個(gè)準(zhǔn)備階段，也就是在提交階段之前，加入了一個(gè)預(yù)提交階段。 在預(yù)提交階段排除一些不一致的情況，保證在最后提交之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。 也就是說，除了引入超時(shí)機(jī)制之外，3PC 把 2PC 的提交階段一分為二，這樣三階段提交協(xié)議就有 CanCommit、PreCommit、DoCommit 三個(gè)階段。 canCommit
precommit
doCommit DoCmmit 階段進(jìn)行真正的事務(wù)提交，根據(jù) PreCommit 階段協(xié)調(diào)者發(fā)送的消息，進(jìn)入執(zhí)行提交階段或事務(wù)中斷階段。
執(zhí)行提交階段：
發(fā)送提交請求。
協(xié)調(diào)者接收到所有參與者發(fā)送的 Ack 響應(yīng)，從預(yù)提交狀態(tài)進(jìn)入到提交狀態(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 階段：
這個(gè)階段說的是對(duì)各個(gè)服務(wù)的資源做檢測以及對(duì)資源進(jìn)行鎖定或者預(yù)留 。
Confirm 階段：
這個(gè)階段說的是在各個(gè)服務(wù)中執(zhí)行實(shí)際的操作 。
Cancel 階段：
如果任何一個(gè)服務(wù)的業(yè)務(wù)方法執(zhí)行出錯(cuò)，那么這里就需要進(jìn)行補(bǔ)償 ，就是執(zhí)行已經(jīng)執(zhí)行成功的業(yè)務(wù)邏輯的回滾操作。
這種方案說實(shí)話幾乎很少人使用。因?yàn)檫@個(gè)事務(wù)回滾 實(shí)際上是嚴(yán)重依賴于你自己寫代碼來回滾和補(bǔ)償 了，會(huì)造成補(bǔ)償代碼巨大，非常之惡心。等于一個(gè)借口拆成三個(gè)。錢 相關(guān)的，支付 、交易 ，會(huì)用 TCC，嚴(yán)格保證分布式事務(wù)要么全部成功，要么全部自動(dòng)回滾，嚴(yán)格保證資金正確。
Sega 金融核心等業(yè)務(wù)可能會(huì)選擇 TCC 方案，以追求強(qiáng)一致性和更高的并發(fā)量，而對(duì)于更多的金融核心以下的業(yè)務(wù)系統(tǒng) 往往會(huì)選擇補(bǔ)償事務(wù)，補(bǔ)償事務(wù)處理在 30 多年前就提出了 Saga 理論，隨著微服務(wù)的發(fā)展，近些年才逐步受到大家的關(guān)注。目前業(yè)界比較公認(rèn)的是采用 Saga 作為長事務(wù)的解決方案。
基本原理 業(yè)務(wù)流程中每個(gè)參與者都提交本地事務(wù)，若某一個(gè)參與者失敗，則補(bǔ)償前面已經(jīng)成功的參與者。下圖左側(cè)是正常的事務(wù)流程，當(dāng)執(zhí)行到 T3 時(shí)發(fā)生了錯(cuò)誤，則開始執(zhí)行右邊的事務(wù)補(bǔ)償流程，反向執(zhí)行 T3、T2、T1 的補(bǔ)償服務(wù) C3、C2、C1，將 T3、T2、T1 已經(jīng)修改的數(shù)據(jù)補(bǔ)償?shù)簟?/p>
使用場景 對(duì)于一致性要求高、短流程、并發(fā)高 的場景，如：金融核心系統(tǒng)，會(huì)優(yōu)先考慮 TCC 方案。而在另外一些場景下，我們并不需要這么強(qiáng)的一致性，只需要保證最終一致性即可。所以 Saga 模式的適用場景是：
優(yōu)勢 缺點(diǎn) 可靠消息最終一致性 流程 A 系統(tǒng)先發(fā)送一個(gè) prepared 消息到 mq，如果這個(gè) prepared 消息發(fā)送失敗那么就直接取消操作別執(zhí)行了；
如果這個(gè)消息發(fā)送成功過了，那么接著執(zhí)行本地事務(wù)，如果成功就告訴 mq 發(fā)送確認(rèn)消息，如果失敗就告訴 mq 回滾消息；
如果發(fā)送了確認(rèn)消息，那么此時(shí) B 系統(tǒng)會(huì)接收到確認(rèn)消息，然后執(zhí)行本地的事務(wù)；
mq 會(huì)自動(dòng)定時(shí)輪詢 所有 prepared 消息回調(diào)你的接口，問你，這個(gè)消息是不是本地事務(wù)處理失敗了，所有沒發(fā)送確認(rèn)的消息，是繼續(xù)重試還是回滾？
一般來說這里你就可以查下數(shù)據(jù)庫看之前本地事務(wù)是否執(zhí)行，如果回滾了，那么這里也回滾吧。
這個(gè)就是避免可能本地事務(wù)執(zhí)行成功了，而確認(rèn)消息卻發(fā)送失敗了。
這個(gè)方案里，要是系統(tǒng) B 的事務(wù)失敗了咋辦？
重試咯，自動(dòng)不斷重試直到成功，如果實(shí)在是不行，要么就是針對(duì)重要的資金類業(yè)務(wù)進(jìn)行回滾，比如 B 系統(tǒng)本地回滾后，想辦法通知系統(tǒng) A 也回滾；
或者是發(fā)送報(bào)警由人工來手工回滾和補(bǔ)償。
這個(gè)還是比較合適的，目前國內(nèi)互聯(lián)網(wǎng)公司大都是這么玩兒的，要不你就用 RocketMQ 支持的，要不你就自己基于類似 ActiveMQ？
RabbitMQ？
自己封裝一套類似的邏輯出來，總之思路就是這樣子的。
下單為例 以下單為例
訂單系統(tǒng)把訂單消息發(fā)給消息中間件，消息狀態(tài)標(biāo)記為“待確認(rèn)”。
消息中間件收到消息后，進(jìn)行消息持久化操作，即在消息存儲(chǔ)系統(tǒng)中新增一條狀態(tài)為“待發(fā)送”的消息。
消息中間件返回消息持久化結(jié)果（成功 / 失敗），訂單系統(tǒng)根據(jù)返回結(jié)果判斷如何進(jìn)行業(yè)務(wù)操作。
失敗，放棄訂單，結(jié)束（必要時(shí)向上層返回失敗結(jié)果）；
成功，則創(chuàng)建訂單。
訂單操作完成后，把操作結(jié)果（成功 / 失敗）發(fā)送給消息中間件。
消息中間件收到業(yè)務(wù)操作結(jié)果后，根據(jù)結(jié)果進(jìn)行處理：
失敗，刪除消息存儲(chǔ)中的消息，結(jié)束；
成功，則更新消息存儲(chǔ)中的消息狀態(tài)為“待發(fā)送（可發(fā)送）”，并執(zhí)行消息投遞。
如果消息狀態(tài)為“可發(fā)送”，則 MQ 會(huì)將消息發(fā)送給支付系統(tǒng)，表示已經(jīng)創(chuàng)建好訂單，需要對(duì)訂單進(jìn)行支付。
支付系統(tǒng)也按照上述方式進(jìn)行訂單支付操作。
訂單系統(tǒng)支付完成后，會(huì)將支付消息返回給消息中間件，中間件將消息傳送給訂單系統(tǒng)。
訂單系統(tǒng)再調(diào)用庫存系統(tǒng)，進(jìn)行出貨操作。
最大努力通知方案 這個(gè)方案的大致意思就是：
系統(tǒng) A 本地事務(wù)執(zhí)行完之后，發(fā)送個(gè)消息到 MQ；
這里會(huì)有個(gè)專門消費(fèi) MQ 的最大努力通知服務(wù) ，這個(gè)服務(wù)會(huì)消費(fèi) MQ 然后寫入數(shù)據(jù)庫中記錄下來，或者是放入個(gè)內(nèi)存隊(duì)列也可以，接著調(diào)用系統(tǒng) B 的接口；
要是系統(tǒng) B 執(zhí)行成功就 ok 了；
要是系統(tǒng) B 執(zhí)行失敗了，那么最大努力通知服務(wù)就定時(shí)嘗試重新調(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)故障的時(shí)候，允許損失一部分功能的可用性。
比如，某些電商 618 大促的時(shí)候，會(huì)對(duì)一些非核心鏈路的功能進(jìn)行降級(jí)處理。
柔性狀態(tài)：
在柔性事務(wù)中，允許系統(tǒng)存在中間狀態(tài)，且這個(gè)中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。
比如，數(shù)據(jù)庫讀寫分離，寫庫同步到讀庫（主庫同步到從庫）會(huì)有一個(gè)延時(shí)，其實(shí)就是一種柔性狀態(tài)。
最終一致性：
事務(wù)在操作過程中可能會(huì)由于同步延遲等問題導(dǎo)致不一致，但最終狀態(tài)下，數(shù)據(jù)都是一致的。
可見，BASE 理論為了支持大型分布式系統(tǒng)，通過犧牲強(qiáng)一致性，保證最終一致性，來獲得高可用性，是對(duì) ACID 原則的弱化。具體到今天的三種分布式事務(wù)實(shí)現(xiàn)方式，二階段提交、三階段提交方法，遵循的是 ACID 原則，而消息最終一致性方案遵循的就是 BASE 理論。
