這裏寫自定義目錄標題
通信問題是解決分佈式事務問題的根本
微服務發展到現在，一直都離不開分佈式事務問題。解決微服務之間的分佈式事務問題比傳統的單體應用的事務要複雜很多，不確定性也很多。雖然業界已經出現了很多解決方案（底層原理多半是基於2pc和3pc），但是最近的項目裏面，發現其實mq也可以解決分佈式事務問題。
爲什麼呢？
因爲雖然分佈式事務問題的根本上是數據一致性問題，而分佈式事務解決方式的根本卻是微服務的通信問題。也就是說，通信是必然要設計的一環。而mq天然就是被設計來解決異步通信、或者高併發問題的組件，故而被成爲消息中間件。
採用mp實現微服務之間的通信要注意的地方
比如有訂單order和會員member兩個微服務，order產生了訂單之後，把訂單消息發送到mq，member訂閱mq的消息，對會員進行積分計算即可。
上述沒有采用兩階段提交2pc或者三階段提交3pc，但一樣可以解決分佈式事務問題，保持數據一致性（稍有延遲，屬於最終一致性）。這樣的優點十分明顯，簡單，解耦，代碼上沒有任何處理分佈式事務的跡象。
不過也要注意，mq實現了最數據的最終一致性，但也有它的缺點：
1、柔性事務，有些微延遲，這個能接受，畢竟cap三選其二，一般都是柔性的
2、消息冪等性。這個屬於主要問題，因爲在網絡延遲的情況下，mq很容易重複發送消息或者重複訂閱，要怎樣防止這個問題，很關鍵，一般採用全局Id+日誌記錄來解決
3、消息堆積問題，這也很正常。由於程序本身產生的bug導致消費失敗，則會產生消息隊列有大堆消息堆積，無法消費，久而久之，影響性能。解決這個問題，通常採用定時任務掃描日誌記錄來分析mq健康來統計，最後人工干預，加以解決。