文章目錄
什麼是消息中間件？
消息中間件是可以用來進行跨系統通信的一個軟件，提供了可靠的異步通信機制。
目前常見的消息中間件有哪些？
目前常見的消息中間件有四種
- ActiveMQ
ActiveMQ是Apache開源的一款使用java編寫的基於JMS規範的消息中間件，不過目前官方的維護似乎變得特變少了 - RabbitMQ
RabbitMQ是一款開源的使用ERLang開發的基於AMQP協議的消息中間件，社區活躍度還不錯 - RocketMQ
RocketMQ是阿里團隊開源的一款使用java編寫的消息中間件 - Kafka
kafka是LinkedIn公司開發的一款使用scala語言編寫的高性能消息中間件
各個消息中間件之間的對比
| 特點 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 社區活躍度 | 低 | 高 | 相對較高 | 高 |
| 性能 | 單機吞吐量在萬級左右 | 單機吞吐量在萬級左右，不過消息延遲特別低，在微秒級別 | 單機吞吐量可達到10w級別 | 單機的吞吐量可以達到10w級別 |
| 可靠性 | 可靠性相對來說低一點，有較低的概率丟失數據 | 可靠性非常高，基本上不會丟失數據 | 經過配置可以做到0丟失 | 經過配置可以做到0丟失 |
| 可用性 | 基於主從架構實現高可用 | 可以部署鏡像集羣，創建高可用隊列保證可用性 | 分佈式架構，可用性很高 | 也是分佈式架構，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 功能完善情況 | 由於誕生早，支持的功能非常豐富 | 功能完善，而且有非常友好的web管理界面，插件支持豐富 | 功能比較完善，提供命令控制檯管理 | 提供比較簡單的MQ功能 |
| 主要使用場景 | 一般小型的公司，或者併發不高的場景都可以使用，不過現在社區活躍度不高了，不建議使用它 | 適用於中小型企業，以及對消息的可靠性要求高於吞吐量的場景 | 適用於高併發場景，並且公司實力強，有能力改源碼 | 更多的是適用於日誌採集的場景，在大數據，雲計算領域使用的相對比較多 |
你使用過哪些消息中間件？
目前我還僅僅使用到了Rabbitmq
你爲什麼會選擇使用RabbitMQ
基於我的業務場景來說，我選擇使用rabbitmq是根據一下幾點來考量的：
1、業務場景需要保證消息不能丟失，對可靠性要求比較高，所以我排除了ActiveMQ
2、業務的吞吐量本身並不是特別大，引入消息中間件主要是爲了解耦和異步，所以我決定選擇RabbitMQ
3、團隊中有了解過RabbitMQ的人佔多數，而我自身也是比較熟悉RabbitMQ，所以降低了開發的風險
你在使用的過程中都遇到了哪些問題？
在使用的過程中遇到了以下幾個問題：
1、數據同步的時候消費者掛掉了
消費者掛掉的原因是因爲內存溢出，爲什麼會內存溢出？
後面發現線停到消費者，然後等待隊列裏面堆積很多消息之後在啓動消費者，發現不一會兒就會出現內存溢出，排查發現是因爲沒有使用QOS預取，導致了消息一下子全部被拉取到消費者，導致消費者內存溢出。
解決方案：設置QOS的值爲300，重新發布消費者，沒有出現內存溢出
2、消息丟失了
由於之前消費者掛掉，所有的消息都堆積到了隊列裏面，隊列都已經堆積滿了，溢出的消息卻無處可去直接被丟棄了
解決方案：增加死信交換器和死信隊列，溢出的消息會進入死信隊列繼續消費，同時也把隊列和交換器以及消息做了持久化設置
使用消息中間件給系統帶來了哪些弊端
1、系統的整體可用性降低了
由於引入了消息中間件，所以不得不去考慮消息中間件會掛掉的可能性，一旦消息中間件掛掉，那麼系統就會不可用。
2、系統變得更復雜了
由於引入了一個消息中間件，從系統整體上來說又多了一個需要整合的模塊，從開發上來說需要進行消息中間件代碼的編寫。