訊息中介軟體有什麼優缺點？

首先，我們先來確認下業界使用mq的三大場景。

1.1 場景一：

a 系統傳送資料到 bcd 三個系統，通過介面呼叫傳送。如果 e 系統也要這個資料呢？那如果 c 系統現在不需要了呢？a 系統負責人幾乎崩潰…

在這個場景中，a系統和各個系統之間有複雜的耦合關係；

如果使用mq,a系統生產一條資料，傳送到mq中，那個系統需要資料，自己就去mq中消費。

如果有新的系統需要資料，直接從mq中消費即可；

如果某個系統不需要這條資料，我們就取消對mq的消費；

a系統就不需要關心資料要發給誰，不需要維護這個**，也不要考慮人家是否呼叫成功、失敗超時等情況。

總結：在這個場景中，我們通過發布訂閱訊息，a系統就和其他系統之間，完成了解耦。

1.2 場景二：

a系統 ,每天22個小時，每秒併發量在30個資料左右。只有在晚上8點-10點昨天，併發量在5k+左右。但是系統是基於mysql資料庫的，大量的資料請求湧入mysql，會導致mysql資料庫崩潰。（一般mysql資料庫也就是每秒2000個請求）

如果使用mq，每秒5k請求寫入mq,a系統每秒中處理2k個請求。因為mysql的資料請求瓶頸的問題，所以a系統每秒從mq中拉去2k個請求來處理。哪怕是業務高峰的時候來臨，a系統也不會掛掉。因為它每秒就處理2k+請求。

這個短暫的高峰期積壓是 ok 的，因為高峰期過了之後，每秒鐘就 50 個請求進 mq，但是 a 系統依然會按照每秒 2k 個請求的速度在處理。所以說，只要高峰期一過，a 系統就會快速將積壓的訊息給解決

總結：這樣的場景適用於解決系統的消峰的問題。比如大量的使用者註冊傳送簡訊驗證等；

1.3 場景三：

如果場景三描述的是a系統受到乙個請求，需要寫本地庫，花費3ms，而其中還需要呼叫b系統，花費300ms，c系統 450ms，d系統 200ms。這樣這個乙個業務就要花費3+300+450+200=953ms。正常的使用者請求正常控制在200ms內完成。等待1s 使用者體驗很差。

如果使用mq，那麼a系統從接受這個請求到返回響應給使用者。總時長8ms。對於使用者來說，這樣的使用者體驗很好。

總結：在這個場景中。我們看到了mq的非同步處理的作用。

2.1. 系統可用性降低

系統引入的外部依賴越多，越容易掛掉。本來你就是 a 系統呼叫 bcd 三個系統的介面就好了，人 abcd 四個系統好好的，沒啥問題，你偏加個 mq 進來，萬一 mq 掛了咋整，mq 一掛，整套系統崩潰的，你不就完了？

2.2.系統複雜度提高

硬生生加個 mq 進來，你怎麼保證訊息沒有重複消費？怎麼處理訊息丟失的情況？怎麼保證訊息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。

2.3.一致性問題

a 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 bcd 三個系統那裡，bd 兩個系統寫庫成功了，結果 c 系統寫庫失敗了，咋整？你這資料就不一致了。

所以訊息佇列實際是一種非常複雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，做好之後，你會發現，媽呀，系統複雜度提公升了乙個數量級，也許是複雜了 10 倍。但是關鍵時刻，用，還是得用的。

中小型公司，技術實力較為一般，技術挑戰不是特別高，用 rabbitmq 是不錯的選擇；大型公司，基礎架構研發實力較強，用 rocketmq 是很好的選擇。

大資料領域的實時計算、日誌採集等場景，用 kafka 是業內標準的，絕對沒問題，社群活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範

訊息中介軟體 有什麼優缺點？