上圖所示的方案，利用消息中間件如 rabbitMQ 來實現分布式下單及庫存扣減過程的最終一致性。對這幅圖做以下說明： 1）order-service 中， ~~~ 在 t_order 表添加訂單記錄 && 在 t_local_msg 添加對應的扣減庫存消息 ~~~ 這兩個過程要在一個事務中完成，保證過程的原子性。同樣，repo-service 中， ~~~ 檢查本次扣庫存操作是否已經執行過 && 執行扣減庫存如果本次扣減操作沒有執行過 && 寫判重表 && 向 MQ sever 反饋消息消費完成 ACK ~~~ 這四個過程也要在一個事務中完成，保證過程的原子性。 2）order-service 中有一個后臺程序，源源不斷地把消息表中的消息傳送給消息中間件，成功后則刪除消息表中對應的消息。如果失敗了，也會不斷嘗試重傳。由于存在網絡 2 將軍問題，即當 order-service 發送給消息中間件的消息網絡超時時，這時候消息中間件可能收到了消息但響應 ACK 失敗，也可能沒收到，order-service 會再次發送該消息，直至消息中間件響應 ACK 成功，這樣可能發生消息的重復發送，不過沒關系，只要保證消息不丟失，不亂序就行，后面 repo-service 會做去重處理。 3）消息中間件向 repo-service 推送 repo\_deduction\_msg，repo-service 成功處理完成后會向中間件響應 ACK，消息中間件收到這個 ACK 才認為 repo-service 成功處理了這條消息，否則會重復推送該消息。但是有這樣的情形：repo-service 成功處理了消息，向中間件發送的 ACK 在網絡傳輸中由于網絡故障丟失了，導致中間件沒有收到 ACK 重新推送了該消息。這也要靠 repo-service 的消息去重特性來避免消息重復消費。 4）在 2）和 3）中提到了兩種導致 repo-service 重復收到消息的原因，一是生產者重復生產，二是中間件重傳。為了實現業務的冪等性，repo-service 中維護了一張判重表，這張表中記錄了被成功處理的消息的 id。repo-service 每次接收到新的消息都先判斷消息是否被成功處理過，若是的話不再重復處理 通過這種設計，實現了消息在發送方不丟失，消息在接收方不被重復消費，聯合起來就是消息不漏不重，嚴格實現了 order-service 和 repo-service 的兩個數據庫中數據的最終一致性。 基于消息中間件的最終一致性全局事務方案是互聯網公司在高并發場景中探索出的一種創新型應用模式，利用 MQ 實現微服務之間的異步調用、解耦合和流量削峰，支持全局事務的高并發，并保證分布式數據記錄的最終一致性