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

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

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

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

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

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

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

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

2. 什么是分布式BASE理論

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

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

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

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

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

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

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

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

我們先來說說2PC解決方案，也就是所謂的2階段提交，它分為2個階段：

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

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

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

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

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

2. AT模式(自動提交模式)

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

3. TCC模式

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

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

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

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

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

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

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

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

4. saga模式

saga：也比較易于理解，就目前seata的官方文檔的說法，它的特點是：

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

就目前seata的實現(xiàn)來說，它是一種基于狀態(tài)機引擎實現(xiàn)，不過整體思路也是大差不差：

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

5. 本地消息表

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

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

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

整體來說本地消息表實現(xiàn)比較簡單但需要考慮一下問題：

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

6. 最大努力通知

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

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

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

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

由此，最大努力交付模型的場景，需要考慮的問題可能會更多：

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

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

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

三、分布式事務(wù)常見問題

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

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

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

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

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

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

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

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

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

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

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

大體步驟為：

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

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

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

• 冪等
• 一致性
• 可靠性

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

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

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

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

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

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

7. TCC的空回滾和懸掛問題和解決方案

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

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

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

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

9. TCC是強一致性還是最終一致性

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

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

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

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

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

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

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

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

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

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

基于該方案，讀者可以看看是否可以解決該問題：

• 分支事務(wù)-1投遞消息到MQ，長時間沒有收到MQ回復(fù)(但是MQ收到了)，分支事務(wù)-1回滾，分支事務(wù)-2執(zhí)行成功，數(shù)據(jù)不一致問題。
• 分支事務(wù)-1提交消息，但是消息隊列因為某些原因出現(xiàn)消息丟失，導(dǎo)致分支事務(wù)-2未能執(zhí)行本地事務(wù)，出現(xiàn)數(shù)據(jù)不一致怎么辦？

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

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

13. seata AT模式存在什么問題

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

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

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

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

結(jié)果完成該操作后，seata因為其他分支事務(wù)失敗導(dǎo)致數(shù)據(jù)回滾，結(jié)果當(dāng)前用戶余額變?yōu)?000，這就是嚴重的臟讀導(dǎo)致的問題：