1、爲什麼要使用消息中間件？
一般說法：
- 解耦與複用
- 異步
- 削峯
以登錄舉例說明，假設登錄服務和認證服務不是同一個系統，登錄服務收到登錄請求後調用認證服務的接口認證用戶名、密碼，需要等待認證服務的結果，認證通過後通知其他應用服務做相應的處理。這個過程對於登錄服務來說，只有認證服務是需要強依賴的，是一種典型的調用關係，而登錄服務與其他應用服務之間如果也使用這種調用關係，它們之間的依賴關係會使得整體架構非常複雜，每個應用服務的變化擴展都可能需要同步修改登錄服務。因此使用MQ可以做到將登錄服務與應用服務解耦，登錄服務處理完登錄後只需要往MQ發送通知，其他應用服務從MQ接收通知即可，登錄服務不需要關注誰要接收這些通知。
異步僅適用於不需要關注返回結果的調用關係，例如登錄成功後發通知加載廣告。
對於削峯，首先需要知道MQ並不能解決高併發問題，只是一種緩解的策略。將消息放到隊列中等待各個服務節點消費，使用隊列維護消息，可以暫時將來不及處理的消息緩存在隊列中。對於偶現的高併發，使用MQ是一種很好的緩解策略，高併發時有隊列頂着，併發量降下來時隊列的壓力慢慢減小了。但是如果服務節點的消費速度太慢，併發量一直不降，這種情況MQ的隊列只會越堆積越多，數據延遲越來越大，這時候應該考慮的服務的垂直擴展與水平擴展。無法擴展的時候應該考慮限流、熔斷等方式。
參考
2、引入MQ導致的問題
- 系統可用性降低
各個服務依賴於MQ，若是MQ掛掉了，整個系統功能都會不正常。（可提一提RabbitMQ的事務機制） - 系統複雜度提高
很多中間件無法避免消息重複、消息丟失的問題，無法保證消息順序。爲了解決這些問題，需要設計一些補償機制，導致系統複雜度提高。 - 數據一致性問題
A 系統調用 BC 系統接口，如果 BC 系統出錯了，會拋出異常，返回給 A 系統讓 A 系統知道，這樣的話就可以做回滾操作了。但是使用了 MQ 之後，A 系統發送完消息就完事了，認爲成功了。而剛好 C 系統寫數據庫的時候失敗了，但是 A 認爲 C 已經成功了?這樣一來數據就不一致了。所以說使用MQ解決異步調用問題要考慮適用場景，它適用於不需要關注返回結果的調用關係。