消息隊列的定義
- 消息隊列： 簡稱它爲MQ(Message Queue)
- 生產者： 把數據放到消息隊列叫做生產者
- 消費者：從消息隊列裏邊取數據叫做消費者
消息隊列的好處
優勢： 解耦、異步、消峯（限流）
使用場景：使用場景
常用的消息隊列
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日誌採集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 儘量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分佈式架構 | 非常高，分佈式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，併發能力很強，性能極好，延時很低 | MQ 功能較爲完善，還是分佈式的，擴展性好 | 功能較爲簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日 |
選擇用哪種消息隊列
一般的業務系統要引入MQ，最早大家都用ActiveMQ，但是現在確實大家用的不多了，沒經過大規模吞吐量場景的驗證，社區也不是很活躍
後來大家開始用RabbitMQ，但是確實erlang語言阻止了大量的java工程師去深入研究和掌控他，對公司而言，幾乎處於不可控的狀態，但是確實人家是開源的，比較穩定的支持，活躍度也高；
不過現在確實越來越多的公司，會去用RocketMQ，確實很不錯，但是要想好社區萬一突然黃掉的風險
所以中小型公司，技術實力較爲一般，技術挑戰不是特別高，用RabbitMQ是不錯的選擇；大型公司，基礎架構研發實力較強，用RocketMQ是很好的選擇
如果是大數據領域的實時計算、日誌採集等場景，用Kafka是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，何況幾乎是全世界這個領域的事實性規範
使用消息隊列需要考慮的問題
JDK實現的隊列種類雖然有很多種，但是都是簡單的內存隊列。滿足不了我們的需求 所以需要我們的中間件
高可用
無論是我們使用消息隊列來做解耦、異步還是削峯，消息隊列肯定不能是單機的。試着想一下，如果是單機的消息隊列，萬一這臺機器掛了，那我們整個系統幾乎就是不可用了。所以在開發過程中一般都是分佈式的
數據丟失問題
我們將數據寫到消息隊列上，系統B和C還沒來得及取消息隊列的數據，就掛掉了。如果沒有做任何的措施，我們的數據就丟了。所以一般需要把他們存儲一下
- 存儲的地方
磁盤？
數據庫？
Redis？
分佈式文件系統？ - 同步存儲還是異步存儲？
消費者怎麼得到消息隊列的數據？
消費者怎麼從消息隊列裏邊得到數據？有兩種辦法：
生產者將數據放到消息隊列中，消息隊列有數據了，主動叫消費者去拿(俗稱push)
消費者不斷去輪訓消息隊列，看看有沒有新的數據，如果有就消費(俗稱pull)
RabbitMQ的5種模式與Activemq的2種模式
https://www.cnblogs.com/wjq310/p/8696733.html
RabbitMQ的5種模式
https://blog.csdn.net/lifaming15/article/details/79942793