分布式事物總體有兩類方案：
①剛性方案，全局事物（標(biāo)準(zhǔn)的分布式事物）如二階段提交協(xié)議。
【盡量保證了數(shù)據(jù)的強一致，適合對數(shù)據(jù)強一致要求很高的關(guān)鍵領(lǐng)域。實現(xiàn)復(fù)雜，犧牲了可用性，對性能影響較大，不適合高并發(fā)高性能場景】
②柔性方案：
1）可靠消息最終一致性（異步確保型）
2）TCC （Try-Confirm-Cancel）（補償型）
3）最大努力通知（非可靠消息，定期校對）
4）純補償型
以下是柔性方案中的幾個實現(xiàn)：
如果使用RocketMQ，在本地應(yīng)用的邏輯代碼里（橘黃色字體）可以不用這樣寫。如果是ActiveMQ、RabbitMQ 和 Kafka需要分三個階段①預(yù)發(fā)送消息②業(yè)務(wù)邏輯③確認(rèn)發(fā)送消息。
RocketMQ事物消息：
第一階段Prepared消息，會拿到消息的地址。
第二階段執(zhí)行本地事務(wù)。
第三階段通過第一階段拿到的地址去訪問消息，并修改狀態(tài)。
也就是說在業(yè)務(wù)方法內(nèi)要想消息隊列提交兩次請求，一次發(fā)送消息和一次確認(rèn)消息。如果確認(rèn)消息發(fā)送失敗了RocketMQ會定期掃描消息集群中的事務(wù)消息，這時候發(fā)現(xiàn)了Prepared消息，它會向消息發(fā)送者確認(rèn)，所以生產(chǎn)方需要實現(xiàn)一個check接口，RocketMQ會根據(jù)發(fā)送端設(shè)置的策略來決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息。這樣就保證了消息發(fā)送與本地事務(wù)同時成功或同時失敗。
