一.引入消息中間件缺點

缺點有以下幾個：

系統(tǒng)可用性降低

系統(tǒng)引入的外部依賴越多，越容易掛掉。本來你就是 A 系統(tǒng)調(diào)用 BCD 三個系統(tǒng)的接口就好了，ABCD 四個系統(tǒng)還好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整？MQ 一掛，整套系統(tǒng)崩潰，你不就完了？如何保證消息隊列的高可用，可以點擊這里查看。

系統(tǒng)復雜度提高

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

一致性問題

A 系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統(tǒng)那里，BD 兩個系統(tǒng)寫庫成功了，結果 C 系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致了。

二 .Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么優(yōu)缺點？

特性ActiveMQRabbitMQRocketMQKafka

單機吞吐量萬級，比 RocketMQ、Kafka 低一個數(shù)量級同 ActiveMQ10 萬級，支撐高吞吐10 萬級，高吞吐，一般配合大數(shù)據(jù)類的系統(tǒng)來進行實時數(shù)據(jù)計算、日志采集等場景

topic 數(shù)量對吞吐量的影響topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優(yōu)勢，在同等機器下，可以支撐大量的 topictopic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 盡量保證 topic 數(shù)量不要過多，如果要支撐大規(guī)模的 topic，需要增加更多的機器資源

時效性ms 級微秒級，這是 RabbitMQ 的一大特點，延遲最低ms 級延遲在 ms 級以內(nèi)

可用性高，基于主從架構實現(xiàn)高可用同 ActiveMQ非常高，分布式架構非常高，分布式，一個數(shù)據(jù)多個副本，少數(shù)機器宕機，不會丟失數(shù)據(jù)，不會導致不可用

消息可靠性有較低的概率丟失數(shù)據(jù)基本不丟經(jīng)過參數(shù)優(yōu)化配置，可以做到 0 丟失同 RocketMQ

功能支持MQ 領域的功能極其完備基于 erlang 開發(fā)，并發(fā)能力很強，性能極好，延時很低MQ 功能較為完善，還是分布式的，擴展性好功能較為簡單，主要支持簡單的 MQ 功能，在大數(shù)據(jù)領域的實時計算以及日志采集被大規(guī)模使用