rabbitmq解決分布式事務原理： 採用最終一致性原理。
需要保證以下三要素
1、確認生產者一定要將資料投遞到mq伺服器中（採用mq訊息確認機制）
2、mq消費者訊息能夠正確消費訊息，採用手動ack模式，使用不補償機制（注意重試冪等性問題）
3、如何保證第乙個事務先執行，採用補償機制（補單機制），在建立乙個補單消費者進行監聽，如果訂單沒有建立成功，進行補單。
mq解決分布式事務一致性
用mq 可以做流量削峰值
如果生產者投遞訊息到mq伺服器成功
場景1 如果消費者消費訊息失敗了
生產者是不需要回滾事務。 消費者採用手動ack應答方式 進行補償機制，補償的過程中注意 冪等性 問題。
分布式事務中遵循base理論 遵循cpa理論
如何確保生產者傳送訊息一定傳送到mq訊息伺服器端成功？ confirm機制 確認應答機制
場景2 如果生產者傳送訊息到mq伺服器端失敗
使用生產者重試機制進行發訊息，重試也是有一定次數限制的 如果超過一定次數 就需要進行人工補償了
分布式事務的補償機制，在很多成熟的案例都是使用tcc機制，來實現資源凍結，以及提交，失敗則釋放資源，很多情況下，處理業務的特殊情況需要對不支援事務的redis進行手動的事務補償。
我們的訂單系統和商品（庫存）是兩個系統，當我們下訂單後，我們就要去修改庫存。
分布式系統要滿足cap定理。一致性，可靠性，可用性。
我們沒法都滿足，只能滿足兩個。因為我們是電商專案。我們要滿足服務的高可用。所以我們滿足可靠性，和可用性。但是，我們又得滿足一致性，這個時候，這個矛盾的解決又要依靠base理論中的最終一致性。我們無法滿足強一致，但是我們可以滿足最終一致性。
在電商系統中，我們用mq來保證最終一致性。保證mq一定會被消費。保證mq會被消費，我們主要有ack機制和序列化機制。
解決分布式事務
1.分布式解決方案 2.非常詳細的乙個業務邏輯 至於消費端消費失敗？通過 返回訊息的狀態，過一段時間，rocketmq會繼續傳送 漲姿勢了 2段式 先查詢每個資料庫的狀態，ok了之後，第2段是本地執行然後提交事務。事務管理器 atomikos,jtom,bitromix 缺點是 一旦詢問的階段機器掛...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...