1、本地消息表

    以訂單成功之后扣減庫存為例，通過記錄一條扣減庫存的記錄和發(fā)送一條消息來保證兩個(gè)服務(wù)之間數(shù)據(jù)的最終一致性。

（1）優(yōu)點(diǎn)：實(shí)現(xiàn)邏輯簡單，開發(fā)量小

（2）缺點(diǎn)：與業(yè)務(wù)強(qiáng)耦合；占用業(yè)務(wù)系統(tǒng)資源；業(yè)務(wù)使用場景有限

2、RocketMQ事務(wù)消息

    以訂單下單成功之后增加積分為例，通過RocketMQ事務(wù)消息實(shí)現(xiàn)數(shù)據(jù)的最終一致性

（1）優(yōu)點(diǎn)：中間件已經(jīng)實(shí)現(xiàn)了事務(wù)邏輯，無需增加額外的配置開發(fā)

（2）缺點(diǎn)：實(shí)時(shí)性不可以保證；業(yè)務(wù)最終一定要成功；事務(wù)消息部分代碼未開源

3、seata的AT模式

    AT模式是對(duì)分布式事務(wù)理論的二階段提交協(xié)議的改進(jìn)，此模式的代碼侵入性?。ㄖ恍鑼?dǎo)入jar）、操作方便，由于事務(wù)協(xié)調(diào)器（TC）會(huì)持久化分支事務(wù)的狀態(tài)，事務(wù)的分支id在事務(wù)執(zhí)行成功會(huì)被標(biāo)記成為已經(jīng)成功的狀態(tài)，其他沒有標(biāo)記成功的分支事務(wù)會(huì)TC的定時(shí)器繼續(xù)通知。保證了所有分支的事務(wù)最終的一致性。

    AT模式的缺點(diǎn)：只適用與關(guān)系性的數(shù)據(jù)庫（如A服務(wù)Mysql和B服務(wù)redis/es之間的事務(wù)就不支持）

4、seata的TCC模式

    由于AT模式存在一些業(yè)務(wù)場景不適用，所以出現(xiàn)了seata-TCC模式，下圖是官方的TCC模式工作原理圖：

    官方給的原理圖比較抽象，我們通過下單的案例分析TCC模式的工作原理：

（1）try階段

（2）confirm階段

（3）cancel階段

TCC模式下的幾種異常處理

（1）TCC異常處理-空回滾

    訂單服務(wù)調(diào)用積分服務(wù)的時(shí)候，由于網(wǎng)絡(luò)抖動(dòng)的原因沒請(qǐng)求成功，TC就會(huì)通知服務(wù)執(zhí)行回滾操作。但是積分服務(wù)沒有執(zhí)行try就直接執(zhí)行cancel，導(dǎo)致業(yè)務(wù)中用戶的積分增加這就是空回滾。

    處理方案：增加一個(gè)日志表來記錄是否執(zhí)行try方法，如果沒有執(zhí)行try，那么cancel也不執(zhí)行

（2）TCC異常處理-冪等性

二階段的方法被多次的調(diào)用（二階段會(huì)有定時(shí)器不斷的重試）這就是存在冪等性問題。

    處理方案：積分服務(wù)的業(yè)務(wù)上需要做冪等（如使用狀態(tài)機(jī)來處理）

（3）TCC異常處理-防懸掛

    服務(wù)做完try資源被預(yù)留出來，但是TC通知積分cancel空回滾且立即執(zhí)行完成（假設(shè)cancel比try先執(zhí)行完），整個(gè)事務(wù)就結(jié)束了。實(shí)際業(yè)務(wù)要給用戶增加了積分就無法回滾。

    處理方案：在日志表中增加cancel、try的記錄，如果try存在記錄，那么cancel操作就先失敗等待下次執(zhí)行。

以上就是常見的分布式事務(wù)的解決方案，希望對(duì)大家有幫助。