舉個栗子，如rabbitmq
1.先說mq。我們使用者乙個下訂單乙個事務，在orderprovider的service裡通過feign遠端呼叫：
@autowired
private rabbittemplate templete;
public void startkill(long id, string money,string count)
(到這裡我已經完全跟著seata的思路走了?)
這裡說下為什麼用mq:
1.解耦。
現在有 service a / service b，三者構成某分布式事務。
如果用 rpc，a / b 彼此是不是得知道對方（哪怕用註冊中心不也有個呼叫過程）？用訊息佇列的話，彼此壓根不需要知道對方，只需要跟訊息佇列打交道就可以了。
你硬要用 rpc 也行，那這時候又多倆 service c / service d 出來呢？你回過頭還得去改 a / b 的**嗎？都你自己寫的你說你費點兒勁，那也行；如果是兩個不同 team 在幹活呢？人家憑啥加班幫你改，自己的任務不做了嗎？
2.mq的作用就是解耦、非同步、削峰，實現分布式事務的最終一致性，是柔性事務。
不考慮併發，直接rpc或http就需要考慮分布式事務如何保證，當然也有對應的分布式事務框架可以補。
兩種實現沒有優劣之分，針對不同場景使用不同的方式，只不過mq在高併發中比較常見。
3.當accountprovider的減餘額操作超時或失敗了。通過orderprovider的trycatch
具體步驟沒有我沒有去實現，可能寫著寫著會發現不太對=。=(太懶了，等有時間再補)
seata專門用分布式事務的，官方文件說的更清楚：
seata分布式事務
分布式事務使用，組長有話說 1 跨服務呼叫的 兩邊都有改資料或新增資料的 都要加上本地事物 並且 發起方要加上 分布式事物 千萬別忘了啊 2 尤其是 呼叫mq的時候 3 我把用到mq的地方都加了分布式註解,漏的你們看一下。portal的託運單，確認下單後，先同步到oms，再從oms同步到tms 1....
seata 分布式事務
seata 是乙個分布式事務解決方案，內建了對at xa tcc saga的支援，主要由tc tm rm三類角色，tc 事務協調器 作為服務端，tm 事務管理器 和rm 資源管理器 工作在客戶端。seata最大程度的保證了對應用的透明。at模式 at模式是通過乙個兩階段提交的方式來管理事務，第一階段...
分布式事務seata學習
1 at模式 2 tcc模式 3 saga模式 at 模式基於 支援本地 acid 事務 的 關係型資料庫 一階段 prepare 行為 在本地事務中，一併提交業務資料更新和相應回滾日誌記錄。二階段 commit 行為 馬上成功結束，自動 非同步批量清理回滾日誌。二階段 rollback 行為 通過...