簡單聊聊分佈式事務管理

什麼是分佈式系統

簡單來說,就是一個用戶請求需要多個系統協同完成。

爲什麼會出現分佈式事務

因爲兩個業務系統直接操作的是兩個不同的數據庫，用的是兩個不同的connection連接對象。無法像傳統單體項目一樣通過普通的數據庫事務特性（acid）保證數據庫數據的一致性。

分佈式事務的一些常用解決方案

• 基於數據庫XA/JTA協議方式； （需要數據庫廠商支持；Java組件有 atomikos）；
• 異步數據校對方式；（支付寶/微信支付主動查詢支付狀態，對賬單的形式）；
• 基於可靠消息（MQ）的解決方案； （異步場景，通用性強，擴展性高）；
• TCC編程式解決方案；（聽說像阿里這些牛逼的公司都自己封裝DTX）。

通過一個電商場景聊聊RebbitMQ解決分佈式事務。

先來看看不做分佈式處理的情況:

這種情況下可能遇到的問題:
1、當庫存系統響應較慢，或者極端些庫存系統掛了，會導致用戶的訂單信息和庫存信息不一致的情況。
2、訂單系統沒有成功生成訂單（訂單數據庫相應超時），但是庫存系統卻更新了庫存。兩數據庫的信息又不一致了（很坑爹）。

接下來再看看加了RabbitMQ做柔性事務管理的分佈式方案:

這樣雖然沒有辦法保證兩數據庫之間的實時一致性，但卻保證了數據的最終一致性。

** 細節: **

• 消息一定要發送到MQ(可靠消息生產)
  • 消息發佈確認機制(publisher-confirms:true)
    消息發佈確認+本地消息表 保證數據一定發送成功
• 消費者被消費掉(可靠的消息消費)
  • 消費確認機制