一、詳解分布式事務(wù)基礎(chǔ)概念

1. 什么是CAP理論，為什么不能同時(shí)滿足CP或者AP

回答這個(gè)問(wèn)題我們優(yōu)先需要了解CAP的3個(gè)概念:

• C(Consistency):一致性,每次讀取到的數(shù)據(jù)都是實(shí)時(shí)最新的數(shù)據(jù)。
• A(Availability)：可用性,每次發(fā)起調(diào)用都可以得到非錯(cuò)誤的正常響應(yīng)。
• P（Partition tolerance）：分區(qū)容錯(cuò)性，即分布式系統(tǒng)遇到某節(jié)點(diǎn)或者網(wǎng)絡(luò)分區(qū)故障的時(shí)候，系統(tǒng)仍然能夠?qū)ν馓峁┮恢滦曰蛘呖捎眯缘姆?wù)。

回答這個(gè)問(wèn)題，為什么CAP不能同時(shí)滿足，這里我們給出這樣一個(gè)場(chǎng)景，有一個(gè)訂單服務(wù)的集群，提供系統(tǒng)訂單的業(yè)務(wù)操作，因?yàn)闃I(yè)務(wù)體量原因采用分布式集群，各自一份庫(kù)源，服務(wù)之間會(huì)不斷進(jìn)行數(shù)據(jù)的同步：

以這套集群架構(gòu)為例可以看到，P是必須可以且必須滿足的條件，即環(huán)境因?yàn)楣?jié)點(diǎn)下線或者網(wǎng)絡(luò)波動(dòng)后網(wǎng)絡(luò)節(jié)點(diǎn)分區(qū)故障后系統(tǒng)依然可以對(duì)外提供服務(wù)：

我們可以通過(guò)反證法來(lái)印證C一致性或者A可用性是否可以同時(shí)存在，假設(shè)我們的系統(tǒng)是CP即一致性和分區(qū)容錯(cuò)性都符合，這意味著即使集群環(huán)境因?yàn)槟硞€(gè)節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)波動(dòng)后依然可以對(duì)外提供正確的服務(wù)，但他們必須通過(guò)分布式協(xié)議將節(jié)點(diǎn)間數(shù)據(jù)同步后保證一致性才能對(duì)外提供服務(wù)，這意味著服務(wù)節(jié)點(diǎn)數(shù)據(jù)沒(méi)有完全同步期間，系統(tǒng)不可以對(duì)外提供服務(wù)(因?yàn)閿?shù)據(jù)不一致)：

同理假設(shè)分布式系統(tǒng)是AP那么，假設(shè)集群某節(jié)點(diǎn)網(wǎng)絡(luò)波動(dòng)通信出現(xiàn)故障，服務(wù)依然可以實(shí)時(shí)的對(duì)外提供服務(wù)，那么因?yàn)楣?jié)點(diǎn)間沒(méi)有及時(shí)的同步就無(wú)法保證一致性，也就收達(dá)不到C一致性的要求。

2. 什么是分布式BASE理論

BASE是CAP理論的一種延伸，BASE理論也可以按照以下幾個(gè)概念組合：

• B（Basically Available）：基本可用，即不要求分布式場(chǎng)景在出現(xiàn)故障之后，允許損失部分可用性，只要保證分布式系統(tǒng)服務(wù)基本核心可用即可。
• S(Soft State)：軟狀態(tài)，允許分布式系統(tǒng)執(zhí)行過(guò)程中數(shù)據(jù)存在中間狀態(tài)，例如：初始化、處理中、已完成，有了軟狀態(tài)才能保證分布式系統(tǒng)失敗后不斷重試，保證數(shù)據(jù)最終處理完成。
• E(Eventual Consistency)：最終一致性,即分布式系統(tǒng)所有的副本在一段時(shí)間后都會(huì)達(dá)到一致?tīng)顟B(tài)，舉個(gè)簡(jiǎn)單例子在傳統(tǒng)事務(wù)情況下，用戶下單的流程是創(chuàng)建訂單、用戶扣款、庫(kù)存扣減3個(gè)步驟，在傳統(tǒng)的強(qiáng)一致性的情況下，這三個(gè)步驟在單位時(shí)間內(nèi)用戶要么看到?jīng)]創(chuàng)建訂單、沒(méi)扣款、沒(méi)扣減庫(kù)存，要么看到創(chuàng)建訂單、用戶扣款、庫(kù)存扣減：

而分布式環(huán)境因?yàn)槭聞?wù)發(fā)布在不同系統(tǒng)之間，為了保證執(zhí)行性能而犧牲操作的原子性，這意味著操作的過(guò)程中可能出現(xiàn)臟讀，即軟狀態(tài)，例如創(chuàng)建了訂單、扣減了用戶余額、但是查看庫(kù)存還沒(méi)有完成扣減，但是在過(guò)一段時(shí)間后，這幾個(gè)操作都會(huì)完成，這就是最終一致性。

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

傳統(tǒng)事務(wù)即MySQL事務(wù)處于單個(gè)庫(kù)源中，通過(guò)數(shù)據(jù)庫(kù)自帶的事務(wù)即可保證ACID，當(dāng)系統(tǒng)庫(kù)表處于分布式節(jié)點(diǎn)的情況下，需要利用XA協(xié)議、TCC事務(wù)、最大努力通知、可靠性消息隊(duì)列等方式協(xié)同多個(gè)節(jié)點(diǎn)完成分布式事務(wù)ACID。

二、分布式事務(wù)的幾種方案

1. XA協(xié)議下的2PC和3PC

解決分布式事務(wù)本質(zhì)上就是要將分布在不同硬件資源上的事務(wù)參與者、支持事務(wù)的服務(wù)器、事務(wù)資源管理器以及資源服務(wù)器進(jìn)行統(tǒng)一協(xié)調(diào)管理。 我們先來(lái)說(shuō)說(shuō)基于XA協(xié)議的分布式事務(wù)解決方案，整體上是有事務(wù)協(xié)調(diào)者和本地資源管理器構(gòu)成，對(duì)應(yīng)的實(shí)現(xiàn)方式分為2PC和3PC。

我們先來(lái)說(shuō)說(shuō)2PC解決方案，也就是所謂的2階段提交，它分為2個(gè)階段：

• 一階段詢問(wèn)各個(gè)分支事務(wù)是否準(zhǔn)備好，此時(shí)分支事務(wù)(假設(shè)是MySQL)就會(huì)準(zhǔn)備好相應(yīng)的redo和undo日志，然后告知事務(wù)協(xié)調(diào)者準(zhǔn)備完成。
• 二階段事務(wù)協(xié)調(diào)者會(huì)基于各個(gè)分支事務(wù)準(zhǔn)備結(jié)果進(jìn)行進(jìn)一步全局操作，假設(shè)所有分支事務(wù)都準(zhǔn)備成功那么就通知所有分支事務(wù)提交，反之若有單個(gè)事務(wù)準(zhǔn)備失敗則通知所有事務(wù)回滾。

2PC嚴(yán)格的遵守了事務(wù)的ACID的四大原則，同時(shí)也相應(yīng)的導(dǎo)致事務(wù)執(zhí)行期間會(huì)出現(xiàn)數(shù)據(jù)會(huì)被鎖定(這也就是我們常說(shuō)的剛性事務(wù))，所以在并發(fā)場(chǎng)景之下性能表現(xiàn)會(huì)差一些。

同時(shí)，2PC在二階段若因?yàn)榫W(wǎng)絡(luò)抖動(dòng)等某些原因，可能會(huì)導(dǎo)致某些分支事務(wù)無(wú)法被提交而導(dǎo)致數(shù)據(jù)長(zhǎng)時(shí)間被鎖定，導(dǎo)致業(yè)務(wù)夯住，進(jìn)而還會(huì)導(dǎo)致一些數(shù)據(jù)不一致的問(wèn)題：

基于上述的二階段死鎖問(wèn)題就有了3PC的解決方案，與2PC步驟不同的是它有三階段，一階段是預(yù)提交階段，它會(huì)先詢問(wèn)各個(gè)分支事務(wù)是否具備事務(wù)提交操作的條件，明確都具備之后通知分支事務(wù)進(jìn)行prepare準(zhǔn)備這一步的2PC的一階段一致，都是準(zhǔn)備undo和redo日志，成功后再進(jìn)入三階段全局事務(wù)提交：

可以看出3PC本質(zhì)上是想通過(guò)一階段的詢問(wèn)操作視圖避免2PC的死鎖問(wèn)題，雖然一定程度上可以避免死鎖問(wèn)題，但在一階段明確正常后，三階段還是可以存在commit的失敗問(wèn)題，并且為了保證事務(wù)最終一致性各個(gè)節(jié)點(diǎn)又增加了一次網(wǎng)絡(luò)IO和系統(tǒng)實(shí)現(xiàn)的復(fù)雜度，似乎是有點(diǎn)得不償失。

2. AT模式(自動(dòng)提交模式)

關(guān)于AT模式基本概念和實(shí)踐可以參考筆者這篇文章：《一步一步教你：用 Docker Compose 完成 Seata 的整合部署》

3. TCC模式

TCC也就是try-confirm-cancel的縮寫(xiě)，是一種業(yè)務(wù)入侵性較強(qiáng)的解決方案，可以保證資源的隔離，且性能表現(xiàn)較好，我們以一個(gè)下單業(yè)務(wù)來(lái)講解一下TCC的大體執(zhí)行流程。 整體來(lái)說(shuō)用戶針對(duì)單個(gè)商品的下單流程為：

• 創(chuàng)建訂單。
• 檢查用戶額度是否足夠，若足夠則扣款。
• 扣減庫(kù)存。

在分布式事務(wù)的場(chǎng)景下，3個(gè)操作是分布式在不同節(jié)點(diǎn)上的，所以為保證數(shù)據(jù)的最終一致性，執(zhí)行步驟為：

• 事務(wù)管理器告知每個(gè)事務(wù)執(zhí)行try操作，訂單服務(wù)創(chuàng)建預(yù)訂單，將狀態(tài)設(shè)置為預(yù)下單狀態(tài)，用戶服務(wù)鎖定部分額度存入凍結(jié)資源表，庫(kù)存服務(wù)同理，鎖定數(shù)量庫(kù)存到凍結(jié)表。
• 若上述的try服務(wù)都執(zhí)行成功，則將訂單設(shè)置為已下單，另外兩個(gè)服務(wù)都基凍結(jié)數(shù)據(jù)進(jìn)行扣減這也就是confirm操作，若單個(gè)事務(wù)失敗則全局回滾，則將凍結(jié)表數(shù)據(jù)清除(也就是cancel操作)，一切回到初始的樣子。

需要注意的是因?yàn)榫W(wǎng)絡(luò)波動(dòng)的原因，活動(dòng)管理器對(duì)應(yīng)的confirm或者cancel通知沒(méi)有收到分支事務(wù)的確認(rèn)操作時(shí)可能會(huì)重復(fù)發(fā)送，這也就可能導(dǎo)致confirm或者cancel會(huì)重復(fù)執(zhí)行，所以我們的業(yè)務(wù)上要盡可能保證冪等：

TCC相較于XA來(lái)說(shuō)它只需要保證最終一致性，所以是存在中間狀態(tài)，不會(huì)存在數(shù)據(jù)鎖，所以性能表現(xiàn)會(huì)相對(duì)出色一些，但是它卻存在如下幾個(gè)問(wèn)題:

• 業(yè)務(wù)侵入性較強(qiáng)，相較于XA這種業(yè)務(wù)層無(wú)感知的實(shí)現(xiàn)，TCC很明顯會(huì)讓開(kāi)發(fā)者感覺(jué)到二階段過(guò)程，整個(gè)分布式事務(wù)的數(shù)據(jù)管理都需要交由開(kāi)發(fā)實(shí)現(xiàn)，整體考慮的維度較多，實(shí)現(xiàn)相對(duì)復(fù)雜。
• 空回滾問(wèn)題：假設(shè)我們try操作因?yàn)榫W(wǎng)絡(luò)波動(dòng)導(dǎo)致分支事務(wù)延遲執(zhí)行，而事務(wù)管理器卻通知我們的事務(wù)進(jìn)行回滾，此時(shí)我們的分支事務(wù)就回滾不到任何東西，也就收事務(wù)空回滾：

• 空懸掛問(wèn)題：基于上述場(chǎng)景，此時(shí)懸掛的try的操作開(kāi)始執(zhí)行，可是業(yè)務(wù)上我們明明已經(jīng)回滾，而這份try的數(shù)據(jù)卻落到庫(kù)中，導(dǎo)致部分?jǐn)?shù)據(jù)被鎖定，業(yè)務(wù)上出現(xiàn)不一致問(wèn)題。

4. saga模式

saga：也比較易于理解，就目前seata的官方文檔的說(shuō)法，它的特點(diǎn)是：

• 是一種長(zhǎng)事務(wù)，適用于長(zhǎng)、多的業(yè)務(wù)流程。
• 一種基于補(bǔ)償實(shí)現(xiàn)的事務(wù)。
• 一階段本地提交、無(wú)鎖性能表現(xiàn)好。

就目前seata的實(shí)現(xiàn)來(lái)說(shuō)，它是一種基于狀態(tài)機(jī)引擎實(shí)現(xiàn)，不過(guò)整體思路也是大差不差：

• 順序執(zhí)行每個(gè)事務(wù)，注意這里的每個(gè)事務(wù)都有相應(yīng)的補(bǔ)償方法，一個(gè)事務(wù)執(zhí)行完成走到下一個(gè)事務(wù)。
• 順序執(zhí)行過(guò)程中，如果某個(gè)事務(wù)執(zhí)行失敗，則基于這個(gè)事務(wù)往回走反向執(zhí)行補(bǔ)償方法將數(shù)據(jù)回滾：

5. 本地消息表

本地消息表也是解決分布式事務(wù)的一種有效手段，整體思路是通過(guò)本地消息表維護(hù)其他事務(wù)需要消費(fèi)的信息，通過(guò)定時(shí)掃描將消息投遞到消息隊(duì)列，讓其他事務(wù)完成消息消費(fèi)從而保證業(yè)務(wù)最終一致性。

這里我們以下單業(yè)務(wù)為例講解一下大體流程：

• 訂單服務(wù)基于本地?cái)?shù)據(jù)庫(kù)原子性將訂單信息和消息(狀態(tài)為待消費(fèi))寫(xiě)入到本地?cái)?shù)據(jù)庫(kù)中。
• 業(yè)務(wù)定時(shí)掃表將數(shù)據(jù)寫(xiě)入消息隊(duì)列。
• 庫(kù)存服務(wù)從消息隊(duì)列中獲取消息完成庫(kù)存扣減。
• 庫(kù)存服務(wù)通知訂單服務(wù)扣減完成，消息可以更新為已完成了。

整體來(lái)說(shuō)本地消息表實(shí)現(xiàn)比較簡(jiǎn)單但需要考慮一下問(wèn)題：

• 定時(shí)掃表的延遲。
• 本地消息表建議和MQ進(jìn)行重試次數(shù)等工作的協(xié)調(diào)維護(hù)，便于追蹤問(wèn)題。
• 因?yàn)檠舆t導(dǎo)致消息消費(fèi)滿。
• 避免消息重復(fù)消費(fèi)，消費(fèi)者可能需要考慮冪等操作。
• 消費(fèi)完成后的通知操作可能會(huì)失敗，同樣可以借助消息隊(duì)列完成這一點(diǎn)。

6. 最大努力通知

最大努力通知模型整體邏輯與前者大體一致，只不過(guò)在細(xì)節(jié)上有所區(qū)別：

• 分支事務(wù)-1執(zhí)行本地事務(wù)操作，完成后通過(guò)RPC、HTTP、MQ同步或者異步發(fā)送消息告知其它事務(wù)執(zhí)行自己的邏輯以保證業(yè)務(wù)的最終一致性。
• 對(duì)于消息發(fā)送這個(gè)過(guò)程，發(fā)送方會(huì)盡自己最大的努力去交付消息，但不可避免某些情況下消息可能無(wú)法送達(dá)。
• 如果接收方長(zhǎng)時(shí)間沒(méi)有收到消息，則接收方可以主動(dòng)詢問(wèn)發(fā)送消息的詳情。
• 基于消息內(nèi)容，接收方完成本地事務(wù)操作，實(shí)現(xiàn)業(yè)務(wù)最終一致性。

與本地消息事務(wù)不同的是，本地消息消息需要發(fā)送方去保證消息發(fā)送的可靠性以保證消費(fèi)方能夠正確消費(fèi)，以實(shí)現(xiàn)業(yè)務(wù)的最終一致性。

而最大努力通知模型則是要求發(fā)送方盡自己的最大的努力去交付(甚至消息是可以重復(fù)發(fā)送的)，并不能保證消息一定能夠送達(dá)，所以它允許接收方去主動(dòng)找發(fā)送方查詢消息，也就是說(shuō)消息的可靠性可能依賴于接收方：

由此，最大努力交付模型的場(chǎng)景，需要考慮的問(wèn)題可能會(huì)更多：

• 消息丟失：最大努力通知模型不保證消息送達(dá)，即使發(fā)送方發(fā)送多次也無(wú)法消除該風(fēng)險(xiǎn)。
• 消息冪等
• 數(shù)據(jù)不一致：因?yàn)橄⑼ㄖ豢煽炕蛘呦⑾M(fèi)失敗等情況導(dǎo)致數(shù)據(jù)不一致。
• 主動(dòng)詢問(wèn)等系列操作帶來(lái)的性能開(kāi)銷(xiāo)
• 消息表高性能保證：即索引和表結(jié)構(gòu)設(shè)計(jì)，是否需要結(jié)合業(yè)務(wù)維度進(jìn)行分庫(kù)分表等
• 補(bǔ)償復(fù)雜性：針對(duì)接受、發(fā)送、消費(fèi)等多個(gè)維度的失敗都需要結(jié)合問(wèn)題的場(chǎng)景針對(duì)性的措施阻斷并完成補(bǔ)償，這會(huì)增加系統(tǒng)的復(fù)雜性。
• 不適合關(guān)鍵業(yè)務(wù)。

7. 基于事務(wù)消息的分布式事務(wù)

《深度解析：基于 RocketMQ 實(shí)現(xiàn)分布式事務(wù)的技術(shù)實(shí)踐與原理探究》

三、分布式事務(wù)常見(jiàn)問(wèn)題

1. 有了2階段提交為什么還需要3階段提交

2PC和3PC在上文中都已經(jīng)做了詳盡的介紹了，我們?cè)谶@里也針對(duì)該問(wèn)題進(jìn)行相應(yīng)的補(bǔ)充，2PC是XA分布式事務(wù)中的一個(gè)重要解決方案，通過(guò)TC一階段通知各個(gè)分支事務(wù)做好準(zhǔn)備(生成undo.log和redo.log)然后根據(jù)各個(gè)分支事務(wù)的提交情況決定二階段是全局提交還是回滾，只有明確所有事務(wù)預(yù)成功后再進(jìn)行事務(wù)提交。

2PC在特定場(chǎng)景下可能無(wú)法保證最終一致性，明確一階段準(zhǔn)備成功后某個(gè)分支事務(wù)沒(méi)有收到提交通知或者提交失敗，所以就有了3PC，3PC本質(zhì)上就是基于2PC基礎(chǔ)上先執(zhí)行的預(yù)提交明確一下各個(gè)分支事務(wù)是否可以正常執(zhí)行再?zèng)Q定是否進(jìn)行后續(xù)的分支事務(wù)準(zhǔn)備和提交工作，由此在一定程度上避免同步阻塞、單點(diǎn)故障、數(shù)據(jù)不一致等問(wèn)題。

2. 什么是TCC，和2PC有什么區(qū)別

關(guān)于TCC上文也已經(jīng)提到過(guò)，它是一種相對(duì)而言業(yè)務(wù)侵入性較強(qiáng)的分布式事務(wù)解決方案，通過(guò)手動(dòng)編寫(xiě)try-confirm-cancel實(shí)現(xiàn)每個(gè)事務(wù)資源預(yù)留、confirm提交、rollback回滾邏輯，通過(guò)在try階段進(jìn)行資源預(yù)留，其他節(jié)點(diǎn)同理，只有所有分布式節(jié)點(diǎn)的try邏輯都成功之后統(tǒng)一進(jìn)行confirm操作，如果有一個(gè)失敗的統(tǒng)一cancel。

相較于XA協(xié)議的2PC而言，它有著如下幾個(gè)不同點(diǎn)：

• XA的2PC是強(qiáng)一致性協(xié)議，操作期間會(huì)持有資源的鎖，它可以一定程度上避免臟讀問(wèn)題，TCC是最終一致性協(xié)議。
• XA的2PC執(zhí)行期間存在數(shù)據(jù)鎖的情況，而TCC則是通過(guò)邏輯層面實(shí)現(xiàn)資源預(yù)留，也就是所謂的補(bǔ)償型事務(wù)，它不會(huì)鎖數(shù)據(jù)，性能表現(xiàn)更加出色。
• XA的2PC對(duì)于用戶而言整個(gè)二階段是無(wú)感知的，而TCC可以讓開(kāi)發(fā)明確的感受到各個(gè)階段的執(zhí)行，業(yè)務(wù)侵入性較強(qiáng)。
• 在實(shí)現(xiàn)層面上，TCC需要用戶自行實(shí)現(xiàn)資源預(yù)留、提交和補(bǔ)償邏輯相較于2PC實(shí)現(xiàn)更復(fù)雜，而且在功能層面還需要考慮到空懸掛和空回滾的問(wèn)題，實(shí)現(xiàn)成本相較于2PC更高一些。

3. 什么是柔性事務(wù)

柔性事務(wù)是業(yè)內(nèi)解決分布式事務(wù)的常用解決方案，與之相反的就是以MySQL的innodb存儲(chǔ)引擎為例的剛性事務(wù)，它要求數(shù)據(jù)實(shí)時(shí)的ACID，而柔性事務(wù)則是基于BASE理論即保證性能只要保證事務(wù)最終一致性，對(duì)于ACID原則，它也是的支撐程度為：

• 原子性：遵循。
• 一致性：為保證性能有些解決方案會(huì)做出妥協(xié)，例如AT模式，它只能保證最終一致性。
• 隔離性：分布式事務(wù)中間處理過(guò)程在安全的情況下允許看到。
• 持久性：遵循。

4. 如何基于本地消息表實(shí)現(xiàn)分布式事務(wù)

大體步驟為：

• 執(zhí)行本地事務(wù)。
• 事務(wù)執(zhí)行成功后創(chuàng)建消息到消息表
• 其他節(jié)點(diǎn)同步輪詢消息表消費(fèi)消息
• 失敗后不斷處理
• 完成后更新消息狀態(tài)。

5. 什么是最大努力通知？

與本地消息表不同，最大努力通知不保證消息交付到消費(fèi)者手里，完成本地事務(wù)后會(huì)創(chuàng)建消息到消息表中，然后通過(guò)接口、消息隊(duì)列等形式通知消費(fèi)者消費(fèi)，但是不保證消費(fèi)者可以準(zhǔn)確收到消息，需要消費(fèi)者主動(dòng)去確認(rèn)，這就可能考慮到以下幾個(gè)問(wèn)題：

• 冪等
• 一致性
• 可靠性

6. 最大努力通知、事務(wù)消息、本地消息表三者區(qū)別

最大努力通知它所對(duì)應(yīng)的消息發(fā)送方放不保證消息可靠性，允許接收方進(jìn)行主動(dòng)會(huì)查等操作，在發(fā)送方層面實(shí)現(xiàn)比較簡(jiǎn)單，也就是消息沒(méi)有成功發(fā)送的地方做個(gè)重試機(jī)制就好了，總的來(lái)說(shuō)它是一種最終一致性的解決方案，仍然是存在數(shù)據(jù)不一致和消息重復(fù)消費(fèi)的問(wèn)題。

再來(lái)說(shuō)說(shuō)事務(wù)消息，它要求發(fā)送方保證消息發(fā)送的可靠性，但是這套方案實(shí)現(xiàn)上業(yè)務(wù)的侵入性比較強(qiáng)，它要求我們的發(fā)送方需要做到如下幾點(diǎn)：

• 發(fā)送的消息必須是half消息，即必須MQ回復(fù)ack之后才能才能消息發(fā)送成功。
• 在接收方明確ACK后，發(fā)送方必須執(zhí)行本地事務(wù)并提交執(zhí)行成功發(fā)送消息的通知，如果接收方長(zhǎng)時(shí)間沒(méi)有收到該確認(rèn)信號(hào)需要發(fā)送方提供一個(gè)回查接口詢問(wèn)該情況。
• 接收方需要保證消息消費(fèi)的冪等判斷以避免消息重復(fù)消費(fèi)。

總的來(lái)說(shuō)，MQ這套事務(wù)消息方案業(yè)務(wù)入侵性較強(qiáng)，實(shí)現(xiàn)相對(duì)復(fù)雜一些，但是整體可靠性相較于前者會(huì)高一些。

本地消息表相較于上述來(lái)說(shuō)做了較好的折中，業(yè)務(wù)入侵性不算很高，做好消息表設(shè)計(jì)然后定時(shí)掃表準(zhǔn)確投遞到MQ中，然后提供一個(gè)消費(fèi)者完成消費(fèi)后的通知接口即可。 它也是同樣要求發(fā)送方保證消息可靠性，但針對(duì)消息表的維度我們還是需要做好表結(jié)構(gòu)設(shè)計(jì)和索引調(diào)優(yōu)，并要的情況下需要考慮一下分庫(kù)分表，所以在明確MQ不支持事務(wù)消息的情況下，我們可以考慮用這套方案。

7. TCC的空回滾和懸掛問(wèn)題和解決方案

空懸掛和空回滾問(wèn)題上文中都已經(jīng)做了詳細(xì)的介紹，大體來(lái)說(shuō)就是全局事務(wù)協(xié)調(diào)者執(zhí)行confirm/cancel操作時(shí)沒(méi)有感知到try操作的狀態(tài)，導(dǎo)致時(shí)許錯(cuò)誤出現(xiàn)的不一致問(wèn)題，對(duì)應(yīng)的我們可以在這幾個(gè)階段執(zhí)行期間通過(guò)一張表(如下tcc_transaction_status)維護(hù)各個(gè)分布式事務(wù)的狀態(tài)。

CREATE TABLE tcc_transaction_status (
tx_id varchar(128) NOT NULL COMMENT '事務(wù)id', 
state int(1) DEFAULT NULL COMMENT'事務(wù)狀態(tài)，0:try，1:confirm，2:cancel' ,
PRIMARY KEY(tx_id) u
)

有了這張表，遇到空回滾時(shí)我們也能夠記錄當(dāng)前回滾狀態(tài)標(biāo)識(shí)回滾，后續(xù)即使出現(xiàn)懸掛的try邏輯也能基于此表感知到回滾則不執(zhí)行：

8. TCC中，Confirm或者Cancel失敗了如何解決

• 可以將需要執(zhí)行的邏輯封裝成消息投遞到MQ等工具進(jìn)行重試，并設(shè)置重試上限避免無(wú)線重試。
• 監(jiān)控模塊告警。
• 人工結(jié)合業(yè)務(wù)數(shù)據(jù)進(jìn)行人工干預(yù)補(bǔ)償。

9. TCC是強(qiáng)一致性還是最終一致性

在理想情況下，分布式節(jié)點(diǎn)能夠正確執(zhí)行try、confirm/cancel邏輯，系統(tǒng)看到的數(shù)據(jù)只有以下3種情況：

• 分布式事務(wù)執(zhí)行前。
• 資源預(yù)留后的事務(wù)數(shù)據(jù)(和1看到的一樣，只不過(guò)其他業(yè)務(wù)進(jìn)行資源預(yù)留時(shí)可能會(huì)失敗)
• 所有事務(wù)一并confirm/cancel后的結(jié)果。

所以按照理想情況的維度考慮，它是可以認(rèn)為是強(qiáng)一致性。但是由于網(wǎng)絡(luò)波動(dòng)或者延遲或者執(zhí)行失敗等原因，TCC并不能做到各個(gè)節(jié)點(diǎn)操作上的一致性，所以一般情況下我們認(rèn)為T(mén)CC是最終一致性。

10. seata的四種事務(wù)模式的適用場(chǎng)景

• XA:不考慮性能的強(qiáng)一致性
• AT：不支持ACID或?qū)π阅苡幸蟮姆植际绞聞?wù)
• TCC：對(duì)性能有較高要求，且業(yè)務(wù)場(chǎng)景比較單一的的場(chǎng)景。
• SAGA：適用于業(yè)務(wù)流程長(zhǎng)、多的分布式事務(wù)場(chǎng)景。

11. Seata的AT模式和XA有什么區(qū)別

AT是軟狀態(tài)的，存在臟讀情況，但是可以保證最終一致性不會(huì)出現(xiàn)行鎖，可以保證最終一致性。 XA是強(qiáng)一致性的所以在事務(wù)執(zhí)行期間，查詢操作會(huì)被鎖住，性能表現(xiàn)差，可以保證強(qiáng)一致性，依賴于數(shù)據(jù)的ACID。

12. 什么是事務(wù)消息，為什么需要事務(wù)消息

我們假設(shè)不采用MQ的half消息，用消息隊(duì)列落地分布式事務(wù)時(shí)，對(duì)應(yīng)過(guò)程為：

• 分支事務(wù)執(zhí)行自己的SQL操作。
• 執(zhí)行成功后將消息投遞到消息隊(duì)列讓分支事務(wù)2執(zhí)行。
• 分支事務(wù)2消費(fèi)消息成功，實(shí)現(xiàn)數(shù)據(jù)最終一致性。

基于該方案，讀者可以看看是否可以解決該問(wèn)題：

• 分支事務(wù)-1投遞消息到MQ，長(zhǎng)時(shí)間沒(méi)有收到MQ回復(fù)(但是MQ收到了)，分支事務(wù)-1回滾，分支事務(wù)-2執(zhí)行成功，數(shù)據(jù)不一致問(wèn)題。
• 分支事務(wù)-1提交消息，但是消息隊(duì)列因?yàn)槟承┰虺霈F(xiàn)消息丟失，導(dǎo)致分支事務(wù)-2未能執(zhí)行本地事務(wù)，出現(xiàn)數(shù)據(jù)不一致怎么辦？

于是就有了事務(wù)消息，我們不妨基于事務(wù)消息的維度看看它是如何解決上述問(wèn)題的：

• 針對(duì)問(wèn)題1，事務(wù)消息在發(fā)送half階段明確要求消息隊(duì)列回復(fù)ACK后才執(zhí)行本地事務(wù)，而不是非事務(wù)消息模式的先執(zhí)行事務(wù)再提交消息。
• 針對(duì)問(wèn)題2，即使commit消息丟失，分支事務(wù)也提供回查接口告知本地事務(wù)狀態(tài)，讓MQ將half消息發(fā)送出去。

13. seata AT模式存在什么問(wèn)題

盡管seata的AT模式用lock_table解決了臟寫(xiě)問(wèn)題，但它還是存在非seata管控范圍的臟讀問(wèn)題，我們都知道seata的AT模式是最終一致性的，這這意味著的一階段提交期間，當(dāng)前分支事務(wù)的數(shù)據(jù)并不是最終結(jié)果，以下單結(jié)果為例，我們的下單流程為：

• 訂單服務(wù)創(chuàng)建訂單。
• 賬戶服務(wù)扣款。
• 庫(kù)存服務(wù)發(fā)貨。

假如一階段庫(kù)存服務(wù)完成一階段事務(wù)準(zhǔn)備，此時(shí)我們其他非seata管控的事務(wù)查到的用戶余額由1000變?yōu)?00，假設(shè)此時(shí)我們的業(yè)務(wù)需要基于這個(gè)數(shù)值進(jìn)行全額轉(zhuǎn)賬執(zhí)行的操作是：

• 將當(dāng)前用戶額度變?yōu)?
• 其他用戶變?yōu)?00

結(jié)果完成該操作后，seata因?yàn)槠渌种聞?wù)失敗導(dǎo)致數(shù)據(jù)回滾，結(jié)果當(dāng)前用戶余額變?yōu)?000，這就是嚴(yán)重的臟讀導(dǎo)致的問(wèn)題：