大家好，我是老三，上次發(fā)文的時(shí)候還是上次發(fā)文的時(shí)候，這篇文章分享分布式事務(wù)，看完要是你們不懂，那一定是不明白。

從本地事務(wù)到分布式事務(wù)

事務(wù)大家應(yīng)該都知道，事務(wù)將一組操作納入到一個(gè)不可分割的執(zhí)行單元，這個(gè)執(zhí)行單元里的操作都成功時(shí)才能提交成功。

簡(jiǎn)單地說，事務(wù)提供一種要么不做，要么全做機(jī)制。

ACID

我們先簡(jiǎn)單了解一下事務(wù)的四大特性：

A 原子性(Atomicity)

一個(gè)事務(wù)(transaction)中的所有操作，要么全部完成，要么全部不完成，不會(huì)出現(xiàn)部分成功部分失敗的情況。。

C 一致性(Consistency)

事務(wù)的一致性指的是在一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫(kù)都必須處于一致性狀態(tài)。如果事務(wù)成功地完成，那么系統(tǒng)中所有變化將正確地應(yīng)用，系統(tǒng)處于有效狀態(tài)。如果在事務(wù)中出現(xiàn)錯(cuò)誤，那么系統(tǒng)中的所有變化將自動(dòng)地回滾，系統(tǒng)返回到原始狀態(tài)。

I 隔離性(Isolation)

指的是在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí)，每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間。由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離。事務(wù)查看數(shù)據(jù)更新時(shí)，數(shù)據(jù)所處的狀態(tài)要么是另一事務(wù)修改它之前的狀態(tài)，要么是另一事務(wù)修改它之后的狀態(tài)，事務(wù)不會(huì)查看到中間狀態(tài)的數(shù)據(jù)。

D 持久性(Durability)

指的是只要事務(wù)成功結(jié)束，它對(duì)數(shù)據(jù)庫(kù)所做的更新就必須永久保存下來。即使發(fā)生系統(tǒng)崩潰，重新啟動(dòng)數(shù)據(jù)庫(kù)系統(tǒng)后，數(shù)據(jù)庫(kù)還能恢復(fù)到事務(wù)成功結(jié)束時(shí)的狀態(tài)。

單體事務(wù)

在單體架構(gòu)時(shí)代，所有的業(yè)務(wù)只用一個(gè)數(shù)據(jù)庫(kù)。

單體架構(gòu)時(shí)代事務(wù)的是實(shí)現(xiàn)很簡(jiǎn)單，我們操作的是同一個(gè)數(shù)據(jù)庫(kù)，利用數(shù)據(jù)庫(kù)本身提供的事務(wù)機(jī)制支持就可以了。

例如我們比較熟悉的MySQL數(shù)據(jù)庫(kù)：

事務(wù)的隔離性是通過數(shù)據(jù)庫(kù)鎖的機(jī)制實(shí)現(xiàn)的。
事務(wù)的一致性由undo log來保證：undo log是邏輯日志，記錄了事務(wù)的insert、update、deltete操作，回滾的時(shí)候做相反的delete、update、insert操作來恢復(fù)數(shù)據(jù)。
事務(wù)的原子性和一持久性由redo log來保證：redolog被稱作重做日志，是物理日志，事務(wù)提交的時(shí)候，必須先將事務(wù)的所有日志寫入redo log持久化，到事務(wù)的提交操作才算完成。

詳細(xì)了解建議閱讀《MySQL技術(shù)內(nèi)幕 ?InnoDB存儲(chǔ)引擎》7.2節(jié)。

分布式事務(wù)

隨著業(yè)務(wù)發(fā)展，單體架構(gòu)頂不住了，慢慢進(jìn)入分布式時(shí)代——SOA或者粒度更細(xì)的微服務(wù)。

當(dāng)然伴隨而來的就是分庫(kù)分表。

我們可能會(huì)根據(jù)業(yè)務(wù)服務(wù)拆分的方式，對(duì)應(yīng)地垂直拆分大庫(kù)，例如原始大庫(kù)拆分成訂單庫(kù)、商品庫(kù)、支付庫(kù)。
同時(shí)由于業(yè)務(wù)數(shù)據(jù)可能會(huì)高速增加，很快就成了億級(jí)，我們不得不又水平分庫(kù)，來減輕單個(gè)數(shù)據(jù)庫(kù)的壓力。

不管是怎么分庫(kù)的，最后的結(jié)果就是我們一個(gè)操作可能要橫跨多個(gè)數(shù)據(jù)庫(kù)。

數(shù)據(jù)庫(kù)本身的事務(wù)機(jī)制只能保證它自己這個(gè)庫(kù)的事務(wù)，但是沒法保證到其它的庫(kù)。我們要保證跨多個(gè)庫(kù)的操作還具備事務(wù)的特性，就不得不上分布式事務(wù)了。

在前面分布式必備理論基礎(chǔ)：CAP和BASE ?里，講了分布式的理論基礎(chǔ)——CAP和BASE，這里就不再多講。

我們只需要知道，BASE理論是對(duì)CAP中AP的一個(gè)延申，在沒法保證強(qiáng)一致性的前提下，盡可能達(dá)到最終的一致性。

我們的分布式事務(wù)通常也做不到本地事務(wù)那么強(qiáng)的一致性，一般都是對(duì)一致性(Consistency)適當(dāng)做了一些放寬，只需要達(dá)到最終的一致性。

分布式事務(wù)解決方案

XA /2PC兩階段提交

XA

XA是一個(gè)分布式事務(wù)協(xié)議，由Tuxedo提出。

在這個(gè)協(xié)議里，有三個(gè)角色：

AP（Application）：應(yīng)用系統(tǒng)（服務(wù)）
TM（Transaction Manager）：事務(wù)管理器（全局事務(wù)管理）
RM（Resource Manager）：資源管理器（數(shù)據(jù)庫(kù)）

XA規(guī)范主要定義了事務(wù)管理器（Transaction ?Manager）和資源管理器（Resource Manager）之間的接口。

XA協(xié)議采用兩階段提交方式來管理分布式事務(wù)。XA接口提供資源管理器與事務(wù)管理器之間進(jìn)行通信的標(biāo)準(zhǔn)接口。

2PC 兩階段提交

兩階段提交的思路可以概括為：參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情況決定各參與者是否要提交操作還是中止操作。

兩階段提交的兩個(gè)階段：第一階段：準(zhǔn)備階段，第二階段：提交階段

準(zhǔn)備階段 Prepares

協(xié)調(diào)者向所有參與者詢問是否可以執(zhí)行提交操作，所有參與者執(zhí)行事務(wù)，將結(jié)果返回給協(xié)調(diào)者。

提交階段 commit

如果第一階段中所有參與者都返回yes響應(yīng)，協(xié)調(diào)者向所有參與者發(fā)出提交請(qǐng)求，所有參與者提交事務(wù)
如果第一階段中有一個(gè)或者多個(gè)參與者返回no響應(yīng)，協(xié)調(diào)者向所有參與者發(fā)出回滾請(qǐng)求，所有參與者進(jìn)行回滾操作

兩階段提交優(yōu)點(diǎn)：盡量保證了數(shù)據(jù)的強(qiáng)一致，但不是100%一致

兩階段提交同樣有一些缺點(diǎn)：

單點(diǎn)故障
由于協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障，參與者會(huì)一直阻塞，尤其是在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。
同步阻塞
它是一個(gè)強(qiáng)一致性的同步阻塞協(xié)議，也就是所謂剛性事務(wù)，事務(wù)執(zhí)?過程中需要將所需資源全部鎖定，會(huì)比較影響性能。
數(shù)據(jù)不一致
在第二階段中，當(dāng)協(xié)調(diào)者向參與者發(fā)送提交事務(wù)請(qǐng)求之后，由于網(wǎng)絡(luò)抖動(dòng)，如果第二階段只有部分參與者收到提交請(qǐng)求，那么就會(huì)導(dǎo)致數(shù)據(jù)不一致。

3PC 三階段提交

三階段提交（3PC）是二階段提交（2PC）的一種改進(jìn)版本，為解決兩階段提交協(xié)議的單點(diǎn)故障和同步阻塞問題。上邊提到兩階段提交，當(dāng)協(xié)調(diào)者崩潰時(shí)，參與者不能做出最后的選擇，就會(huì)一直保持阻塞鎖定資源。

2PC 中只有協(xié)調(diào)者有超時(shí)機(jī)制，3PC 在協(xié)調(diào)者和參與者中都引入了超時(shí)機(jī)制，協(xié)調(diào)者出現(xiàn)故障后，參與者就不會(huì)一直阻塞。而且在第一階段和第二階段中又插入了一個(gè)預(yù)提交階段，保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

三階段提交的三個(gè)階段：CanCommit，PreCommit，DoCommit三個(gè)階段

準(zhǔn)備階段 CanCommit

協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

預(yù)提交階段 PreCommit

協(xié)調(diào)者根據(jù)參與者在準(zhǔn)備階段的響應(yīng)判斷是否執(zhí)行事務(wù)還是中斷事務(wù)

如果所有參與者都返回Yes，則執(zhí)行事務(wù)
如果參與者有一個(gè)或多個(gè)參與者返回No或者超時(shí)，則中斷事務(wù)

參與者執(zhí)行完操作之后返回ACK響應(yīng)，同時(shí)開始等待最終指令。

提交階段 DoCommit

協(xié)調(diào)者根據(jù)參與者在準(zhǔn)備階段的響應(yīng)判斷是否執(zhí)行事務(wù)還是中斷事務(wù)

如果所有參與者都返回正確的ACK響應(yīng)，則提交事務(wù)
如果參與者有一個(gè)或多個(gè)參與者收到錯(cuò)誤的ACK響應(yīng)或者超時(shí)，則中斷事務(wù)
如果參與者無法及時(shí)接收到來自協(xié)調(diào)者的提交或者中斷事務(wù)請(qǐng)求時(shí)，在等待超時(shí)之后，會(huì)繼續(xù)進(jìn)行事務(wù)提交

協(xié)調(diào)者收到所有參與者的ACK響應(yīng)，完成事務(wù)。

可以看出，三階段提交解決的只是兩階段提交中單體故障和同步阻塞的問題，因?yàn)榧尤肓顺瑫r(shí)機(jī)制，這里的超時(shí)的機(jī)制作用于 預(yù)提交階段 和 提交階段。如果等待 預(yù)提交請(qǐng)求 超時(shí)，參與者直接回到準(zhǔn)備階段之前。如果等到提交請(qǐng)求超時(shí)，那參與者就會(huì)提交事務(wù)了。

無論是2PC還是3PC都不能保證分布式系統(tǒng)中的數(shù)據(jù)100%一致

TCC補(bǔ)償事務(wù)

TCC ?Try-Confirm-Cancel 的簡(jiǎn)稱，是兩階段提交的一個(gè)變種，針對(duì)每個(gè)操作，都需要有一個(gè)其對(duì)應(yīng)的確認(rèn)和取消操作，當(dāng)操作成功時(shí)調(diào)用確認(rèn)操作，當(dāng)操作失敗時(shí)調(diào)用取消操作，類似于二階段提交，只不過是這里的提交和回滾是針對(duì)業(yè)務(wù)上的，所以基于TCC實(shí)現(xiàn)的分布式事務(wù)也可以看做是對(duì)業(yè)務(wù)的一種補(bǔ)償機(jī)制。

TCC的三階段：

Try 階段：對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留
Confirm 階段：對(duì)業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功
Cancel 階段：在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放

在Try階段，是對(duì)業(yè)務(wù)系統(tǒng)進(jìn)行檢查及資源預(yù)覽，比如訂單和庫(kù)存操作，需要檢查庫(kù)存剩余數(shù)量是否夠用，并進(jìn)行預(yù)留，預(yù)留操作的話就是新建一個(gè)可用庫(kù)存數(shù)量字段，Try階段操作是對(duì)這個(gè)可用庫(kù)存數(shù)量進(jìn)行操作。

例如下單減庫(kù)存的操作：

執(zhí)行流程：

Try階段：訂單系統(tǒng)將當(dāng)前訂單狀態(tài)設(shè)置為支付中，庫(kù)存系統(tǒng)校驗(yàn)當(dāng)前剩余庫(kù)存數(shù)量是否大于1，然后將可用庫(kù)存數(shù)量設(shè)置為庫(kù)存剩余數(shù)量-1，
如果Try階段執(zhí)行成功，執(zhí)行Confirm 階段，將訂單狀態(tài)修改為支付成功，庫(kù)存剩余數(shù)量修改為可用庫(kù)存數(shù)量
如果Try階段執(zhí)行失敗，執(zhí)行Cancel 階段，將訂單狀態(tài)修改為支付失敗，可用庫(kù)存數(shù)量修改為庫(kù)存剩余數(shù)量

TCC 不存在資源阻塞的問題，因?yàn)槊總€(gè)方法都直接進(jìn)行事務(wù)的提交，一旦出現(xiàn)異常通過則 Cancel 來進(jìn)行回滾補(bǔ)償，這也就是常說的補(bǔ)償性事務(wù)。

但是，使用TCC，原本一個(gè)方法，現(xiàn)在卻需要三個(gè)方法來支持，可以看到 TCC 對(duì)業(yè)務(wù)的侵入性很強(qiáng)，而且這種模式并不能很好地被復(fù)用，會(huì)導(dǎo)致開發(fā)量激增。還要考慮到網(wǎng)絡(luò)波動(dòng)等原因，為保證請(qǐng)求一定送達(dá)都會(huì)有重試機(jī)制，所以還需要考慮接口的冪等性。

本地消息表

本地消息表的核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理。

例如，可以在訂單庫(kù)新增一個(gè)消息表，將新增訂單和新增消息放到一個(gè)事務(wù)里完成，然后通過輪詢的方式去查詢消息表，將消息推送到MQ，庫(kù)存系統(tǒng)去消費(fèi)MQ。

執(zhí)行流程：

訂單服務(wù)，添加一條訂單和一條消息，在一個(gè)事務(wù)里提交
訂單服務(wù)，使用定時(shí)任務(wù)輪詢查詢狀態(tài)為未同步的消息表，發(fā)送到MQ，如果發(fā)送失敗，就重試發(fā)送
庫(kù)存服務(wù)，接收MQ消息，修改庫(kù)存表，需要保證冪等操作
如果修改成功，調(diào)用rpc接口修改訂單系統(tǒng)消息表的狀態(tài)為已完成或者直接刪除這條消息
如果修改失敗，可以不做處理，等待重試

訂單服務(wù)中的消息有可能由于業(yè)務(wù)問題會(huì)一直重復(fù)發(fā)送，所以為了避免這種情況可以記錄一下發(fā)送次數(shù)，當(dāng)達(dá)到次數(shù)限制之后報(bào)警，人工接入處理；庫(kù)存服務(wù)需要保證冪等，避免同一條消息被多次消費(fèi)造成數(shù)據(jù)不一致。

本地消息表這種方案實(shí)現(xiàn)了最終一致性，需要在業(yè)務(wù)系統(tǒng)里增加消息表，業(yè)務(wù)邏輯中多一次插入的DB操作，所以性能會(huì)有損耗，而且最終一致性的間隔主要由定時(shí)任務(wù)的間隔時(shí)間決定。

MQ消息事務(wù)

消息事務(wù)的原理是將兩個(gè)事務(wù)通過消息中間件進(jìn)行異步解耦。

訂單服務(wù)執(zhí)行自己的本地事務(wù)，并發(fā)送MQ消息，庫(kù)存服務(wù)接收消息，執(zhí)行自己的本地事務(wù)，乍一看，好像跟本地消息表的實(shí)現(xiàn)方案類似，只是省去了對(duì)本地消息表的操作和輪詢發(fā)送MQ的操作，但實(shí)際上兩種方案的實(shí)現(xiàn)是不一樣的。

消息事務(wù)一定要保證業(yè)務(wù)操作與消息發(fā)送的一致性，如果業(yè)務(wù)操作成功，這條消息也一定投遞成功。

執(zhí)行流程：

發(fā)送prepare消息到消息中間件
發(fā)送成功后，執(zhí)行本地事務(wù)
如果事務(wù)執(zhí)行成功，則commit，消息中間件將消息下發(fā)至消費(fèi)端
如果事務(wù)執(zhí)行失敗，則回滾，消息中間件將這條prepare消息刪除
消費(fèi)端接收到消息進(jìn)行消費(fèi)，如果消費(fèi)失敗，則不斷重試

消息事務(wù)依賴于消息中間件的事務(wù)消息，例如我們熟悉的RocketMQ就支持事務(wù)消息（半消息），也就是只有收到發(fā)送方確定才會(huì)正常投遞的消息。

這種方案也是實(shí)現(xiàn)了最終一致性，對(duì)比本地消息表實(shí)現(xiàn)方案，不需要再建消息表，對(duì)性能的損耗和業(yè)務(wù)的入侵更小。

最大努力通知

最大努力通知相比實(shí)現(xiàn)會(huì)簡(jiǎn)單一些，適用于一些最終一致性要求較低的業(yè)務(wù)，比如支付通知，短信通知這種業(yè)務(wù)。

以支付通知為例，業(yè)務(wù)系統(tǒng)調(diào)用支付平臺(tái)進(jìn)行支付，支付平臺(tái)進(jìn)行支付，進(jìn)行操作支付之后支付平臺(tái)會(huì)去同步通知業(yè)務(wù)系統(tǒng)支付操作是否成功，如果不成功，會(huì)一直異步重試，但是會(huì)有一個(gè)最大通知次數(shù)，如果超過這個(gè)次數(shù)后還是通知失敗，就不再通知，業(yè)務(wù)系統(tǒng)自行調(diào)用支付平臺(tái)提供一個(gè)查詢接口，供業(yè)務(wù)系統(tǒng)進(jìn)行查詢支付操作是否成功

執(zhí)行流程：

業(yè)務(wù)系統(tǒng)調(diào)用支付平臺(tái)支付接口，并在本地進(jìn)行記錄，支付狀態(tài)為支付中
支付平臺(tái)進(jìn)行支付操作之后，無論成功還是失敗，同步給業(yè)務(wù)系統(tǒng)一個(gè)結(jié)果通知
如果通知一直失敗則根據(jù)重試規(guī)則異步進(jìn)行重試，達(dá)到最大通知次數(shù)后，不再通知
支付平臺(tái)提供查詢訂單支付操作結(jié)果接口
業(yè)務(wù)系統(tǒng)根據(jù)一定業(yè)務(wù)規(guī)則去支付平臺(tái)查詢支付結(jié)果

Saga事務(wù)

Saga事務(wù)，核心思想是將長(zhǎng)事務(wù)拆分為多個(gè)本地短事務(wù)，由Saga事務(wù)協(xié)調(diào)器協(xié)調(diào)，如果正常結(jié)束那就正常完成，如果某個(gè)步驟失敗，則根據(jù)相反順序一次調(diào)用補(bǔ)償操作。

和本地事務(wù)undo log有點(diǎn)像，出問題了，逆向操作來挽救。

Sega簡(jiǎn)介：

Saga = Long Live Transaction (LLT，長(zhǎng)活事務(wù))
LLT = T1 + T2 + T3 + ... + Ti（Ti為本地短事務(wù)）
每個(gè)本地事務(wù)Ti 有對(duì)應(yīng)的補(bǔ)償 Ci

Sega的執(zhí)行順序：

正常情況：T1 T2 T3 ... Tn
異常情況：T1 T2 T3 C3 C2 C1

Saga兩種恢復(fù)策略

向后恢復(fù)，如果任意本地子事務(wù)失敗，補(bǔ)償已完成的事務(wù)。如異常情況的執(zhí)行順序T1 T2 Ti Ci C2 C1.
向前恢復(fù)，即重試失敗的事務(wù)，假設(shè)最后每個(gè)子事務(wù)都會(huì)成功。執(zhí)行順序：T1, T2, ..., Tj(失敗), Tj(重試),..., Tn。

舉個(gè)例子，假設(shè)用戶下訂單，花50塊錢購(gòu)買了10瓶可樂，則有這么一些短事務(wù)和回滾操作：

T1=下訂單 ?=> T2=用戶扣50塊錢 => T3=用戶加10瓶可樂= > T4=庫(kù)存減10瓶可樂

C1=取消訂單 => C2= 給用戶加50塊錢 => C3 =用戶減10朵玫瑰 = > C4=庫(kù)存加10朵玫瑰

Seata

看了這么些事務(wù)的方案，介紹了相關(guān)的原理，但是這些原理怎么落地呢？各種各樣的坑怎么處理呢？

—— 人生苦短，我用開源。

阿里巴巴開源了一套開源分布式事務(wù)解決方案——Seata。Seata可能并不稱之為完美，但對(duì)代碼入侵性非常小，基本環(huán)境搭建完成的話，使用的時(shí)候在只需要方法上添加一個(gè)注解@GlobalTransactional就可以開啟全局事務(wù)。

Seata 也是從兩段提交演變而來的一種分布式事務(wù)解決方案，提供了 AT、TCC、SAGA 和 XA 等事務(wù)模式，我們來看一下AT模式。

Seata 中主要有這么幾種角色：

TC（Transaction Coordinator）：事務(wù)協(xié)調(diào)者。管理全局的分支事務(wù)的狀態(tài)，用于全局性事務(wù)的提交和回滾。

TM（Transaction Manager）：事務(wù)管理者。用于開啟、提交或回滾事務(wù)。

RM（Resource Manager）：資源管理器。用于分支事務(wù)上的資源管理，向 TC 注冊(cè)分支事務(wù)，上報(bào)分支事務(wù)的狀態(tài)，接收 TC 的命令來提交或者回滾分支事務(wù)。

我們看一下Seata大概的一個(gè)工作流程：

執(zhí)行流程：

服務(wù)A中的 TM 向 TC 申請(qǐng)開啟一個(gè)全局事務(wù)，TC 就會(huì)創(chuàng)建一個(gè)全局事務(wù)并返回一個(gè)唯一的 XID
服務(wù)A中的 RM 向 TC 注冊(cè)分支事務(wù)，然后將這個(gè)分支事務(wù)納入 XID 對(duì)應(yīng)的全局事務(wù)管轄中
服務(wù)A開始執(zhí)行分支事務(wù)
服務(wù)A開始遠(yuǎn)程調(diào)用B服務(wù)，此時(shí) XID 會(huì)根據(jù)調(diào)用鏈傳播
服務(wù)B中的 RM 也向 TC 注冊(cè)分支事務(wù)，然后將這個(gè)分支事務(wù)納入 XID 對(duì)應(yīng)的全局事務(wù)管轄中
服務(wù)B開始執(zhí)行分支事務(wù)
全局事務(wù)調(diào)用處理結(jié)束后，TM 會(huì)根據(jù)有誤異常情況，向 TC 發(fā)起全局事務(wù)的提交或回滾
TC 協(xié)調(diào)其管轄之下的所有分支事務(wù)，決定是提交還是回滾

關(guān)于Seata的使用，和更詳細(xì)的原理，這里挖個(gè)坑，以后有時(shí)間再細(xì)講。

總結(jié)

上邊簡(jiǎn)單介紹了 2PC、3PC、TCC、本地消息表、最大努力通知、MQ、Sega、Seata 這8種分布式事務(wù)解決方案，但不管我們選哪一種方案，我們可以看到真要落地要考慮的點(diǎn)都很多，一個(gè)不慎，可能踩坑。

即使是看起來很省心的Seata，我之前的項(xiàng)目花了不少w買了它的商業(yè)化版本GTS，但是支持方仍然列出了一些“禁忌”，像長(zhǎng)事務(wù)、大量數(shù)據(jù)、熱點(diǎn)數(shù)據(jù)、異步調(diào)用等等，都可能會(huì)出現(xiàn)問題。

所以在項(xiàng)目中應(yīng)用分布式事務(wù)要謹(jǐn)慎再謹(jǐn)慎，除非真的有一致性要求比較強(qiáng)的場(chǎng)景，能不用就盡量不用。