現在的微服務這麼流行這麼火，分佈式的事務是每個系統都會遇到的問題。
CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務無法同時滿足一下3個屬性：
- 一致性(Consistency) ： 客戶端知道一系列的操作都會同時發生(生效)
- 可用性(Availability) ： 每個操作都必須以可預期的響應結束
- 分區容錯性(Partition tolerance) ： 即使出現單個組件無法可用,操作依然可以完成
具體地講在分佈式系統中，在任何數據庫設計中，一個Web應用至多隻能同時支持上面的兩個屬性。顯然，任何橫向擴展策略都要依賴於數據分區。因此，設計人員必須在一致性與可用性之間做出選擇。
解決方案：
一、兩階段提交（2PC）
核心是：事務協調器， 每個操作都先不提交事務，把是否提交提交事務的結果提交到事務協調器這裏，並且告知是否可以提交事務，等所有的都告知處理完了可以提交事務了，這個是由事務協調器一起提交。
二、補償事務（TCC）
TCC 其實就是採用的補償機制，其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。
三、本地消息表(主要是利用消息中間件的 --異步處理機制)
本地消息表這個方案最初是 eBay 提出的，eBay 的完整方案 https://queue.acm.org/detail.cfm?id=1394128
簡單點的說，就是利用了本地事務的一致性來保證，最終的事務的一致性
舉個簡單的例子： A支付系統 B訂單系統
我們拿錢去買東西，支付系統在接受到錢支付成功了， 訂單系統則要減去對應的訂單！
- 在分佈式事務操作的一方完成寫業務數據的操作之後向本地消息表發送一個消息，本地事務能保證這個消息一定會被寫入本地消息表中。
- 之後將本地消息表中的消息轉發到 Kafka 等消息隊列中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。
- 在分佈式事務操作的另一方從消息隊列中讀取一個消息，並執行消息中的操作。
四、MQ事務
這裏不多說，大部分的比如 kafka，rabbitMq 都是不支持事務的
阿里的RocketMQ 據說支持，實現的大體思路
第一階段Prepared消息，會拿到消息的地址。
第二階段執行本地事務，第三階段通過第一階段拿到的地址去訪問消息，並修改狀態。
也就是說在業務方法內要想消息隊列提交兩次請求，一次發送消息和一次確認消息。如果確認消息發送失敗了RocketMQ會定期掃描消息集羣中的事務消息，這時候發現了Prepared消息，它會向消息發送者確認，所以生產方需要實現一個check接口，RocketMQ會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。