分佈式事務—MQ最終一致性模型（無獨立消息系統）

參考：https://blog.csdn.net/shanchahua123456/article/details/84781638

冪等性，有序性，補償性，可查性

保證同種服務集羣讀寫同一個數據庫/數據庫中間件，這樣即便是集羣服務，也能夠正常確認，由於同種服務集羣共用相同的數據。

流程

1 上游程序/數據庫（生產者）：

1.1 本地事務  【生成惟一ID——》執行業務流程  ——》  本地保存消息數據（db_queue 表） ——》發送到MQ】 

本地db_queue 表：消息ID，相關單據編號，路由鍵(目標MQ-QUEUE)，內容Json，時間，狀態。

MQ採用confirm方式發送，會有異步的返回結果。根據返回結果，而後更新db_queue表裏的消息狀態"已發"。

本地事務中任意異常都會回滾，但小几率出現 MQ發送成功，可是本地事務未提交。因此下游消費時，要確認上游業務已完成。如果簡單的數據傳輸/同步則不須要確認，由於上游無數據，下游也不會拉取到數據。

1.2 確認接口（冪等）：回寫業務表狀態，刪除db_queue 表。 （成功/失敗）   

      下游服務消費出現邏輯失敗。好比庫存不足，金額不足等。此時生產者要視狀況手動實現業務回滾邏輯 。若調用了多個下游服務，則可能還要經過MQ通知其餘下游服務執行回滾邏輯。        

1.3 查詢接口：狀態業務表、db_queue 表查詢等。知足恢復功能和下游服務的查詢功能。

2 消息恢復功能（定時任務）：(注意冪等性設計)  

本服務主要作的是定時補償工做。

2.1查詢db_queue 表，上游程序超時未發送，重發；

2.2查詢db_queue 表，上游程序超時未確認數據，調用下游消費者查詢接口，若下游已消費則調用上游確認接口，若下游未消費則重發。

3 下游程序/數據庫（消費者）：(注意冪等性設計)  

監聽MQ隊列：調用對應消費服務

3.1 根據業務判斷是否須要查詢上游業務已完成，避免無效重試。（數據傳輸不須要）

3.2 本地事務  【 冪等執行業務流程  ——》 用上游接口，確認上游業務數據 】 

           3.3 注意MQ的可靠消費，手動ACK，限制收取量

           3.4 數據庫冪等設計能夠依靠：主鍵/惟一索引/update+條件/先查再寫(高併發必定機率有問題)

           3.5 查詢接口：查詢消費狀態。

推薦參考文章：RabbitMQ消息可靠性投遞解決方案 

https://blog.csdn.net/shanchahua123456/article/details/86188705