RabbitMQ優缺點

比如說，我之前在公司做的一個系統叫 “跟蹤提醒平臺”，是一個公共的平臺，可以給客戶或者業務人員推送訊息，如電話語音、簡訊、郵件、APP 內訊息和微信訊息等。其他系統對接我們，需要在我們系統這邊配置提醒規則和物件。然後他們會推送 MQ 訊息，我們去消費處理。

為什麼使用 MQ 呢？如果不用 MQ 的話，只能透過呼叫介面的方式。我們考慮到呼叫介面會有 2 個缺點:

• 一是會阻塞，像我們系統提醒業務處理過程通常要 1-2 秒，如果一下來了太多請求，可能是處理不過來的，後面的請求只能一直等甚至超時；而 MQ 支援訊息堆積，很好解決了這個問題。
• 二是呼叫失敗無法自動重試，MQ 可以很容易實現失敗重試。
削峰

削峰跟前面說的非同步很像，比如有些系統通常是晚上 2 點跑規則然後去給我們推送訊息，讓我們幫他們提醒客戶或業務人員。

突然大量請求過來，短時間內我們可以處理不過來的，所以需要訊息堆積。MQ 可以幫我們儲存訊息，而且對接方對也不要求實時性， 所以我們可以慢慢消費處理，很舒服。

解耦

比如客戶報案後，我們處理報案資訊生成案件號等邏輯執行完後，需要把報案資訊推送給 A、 B、 C 這 3 個其他的系統。

如果用呼叫介面方式，呼叫三次介面，也不是不可以實現。但是如果後期 B 系統說你不需要推送給我了。我這邊是不是需要刪除掉推送給 B 的程式碼，這就是程式碼耦合了。

透過 MQ 可以解決這個問題，我往指定的 TOPIC:TAG 裡推送訊息，然後 A、 B、 C 三個專案都去訂閱 TOPIC:TAG，推送方式可以廣播模式。如果 B 系統不需要報案資訊，可以去取消訂閱這個 TOPIC:TAG，或者他們自己修改業務程式碼，而我這邊是不需要修改的，美滋滋。

缺點
系統可用性降低

我們在處理下單系統中返回簡訊給使用者用了 MQ、在訂單系統和庫存系統之間用了 MQ、在處理促銷活動也用到了 MQ，如果 MQ 出現問題，就會出現連鎖反應，系統崩潰。（系統引入的外部依賴越多，受到的影響也就越多。本來A系統只需要去呼叫 B、C、D 三個系統的介面就可以了，加入了 MQ 之後，如果 MQ 掛掉了，我們的系統也會受到影響。)

系統複雜度提高

我們新增了 MQ 到系統之後，如何保證訊息傳遞的順序性？訊息傳遞的過程中是否有重複？是否有丟失？這個時候我們就需要在系統中去思考解決這些問題，相應的就將系統的複雜度提高了。

一致性問題

系統 A 給 BCD 傳送訊息，只有都成功才返回成功，若是隻有 C 成功，B 和 D 都沒有成功，但是返回結果是成功了，這就出現了一個一致性問題需要解決。