消息队列概念与认知
MQ學習系列:
本文是-消息隊列學習的概念與介紹篇。目的是能夠對消息隊列能夠有一個簡單的了解和大體的認知。
參考/學習資料整理(好東西要學會分享 )
B站上的黑馬ActiveMQ的視頻教程
Hollis公眾號上的消息隊列文章
架構之家公眾號上的消息隊列文章
JavaGuide(一份涵蓋大部分Java程序員所需要掌握的核心知識的文檔類項目)
CS-Notes(技術面試必備基礎知識)
JCSprout(處于萌芽階段的 Java 核心知識庫)
一個在線繪圖的工具
一、消息隊列簡介
消息隊列 MQ(message queue)中間件是分布式系統中的重要組件,主要解決異步消息、應用解耦、流量 削峰等問題,從而實現高性能、高可用 ,可伸縮和最終一致性的架構。
使用較多的消息隊列有ActiveMQ 、RabbitMQ、RocketMQ、Kafka、MetaMQ等
1 消息隊列應用場景分析
1.1 異步處理
舉個栗子:
有這樣一個用戶注冊場景 ,實現將注冊信息寫入數據庫并發送郵件和注冊短信的功能。
傳統的方式如圖:
這樣的方式會一步步按照先后順序 完成后返回給用戶信息 ,整個過程用戶都處于等待的狀態,并用時150ms。
而引用消息對列 ,異步處理,改造后的架構如下:
這樣對于用戶的響應時間就大大減少了。
1.2 應用解耦
多應用間通過消息隊列對同一消息進行處理,避免調用接口失敗導致整個過程失敗。
1.3 流量削峰
廣泛應用于秒殺或搶購活動中,避免流量過大導致應用系統掛掉的情況。
具體場景:購物網站開展秒殺活動,一般由于瞬時訪問量過大,服務器接收過大,會導致流量暴增,相關系統無法處理請求甚至崩潰。而加入消息隊列后,系統可以從消息隊列中取數據,相當于消息隊列做了一次緩沖。
二、JMS & AMQP
1 JMS 簡介
JMS(JAVA Message Service,java消息服務)是java的消息服務,JMS的客戶端之間可以通過JMS服務進行異步的消息傳輸。JMS(JAVA Message Service,Java消息服務)API是一個消息服務的標準或者說是規范,允許應用程序組件基于JavaEE平臺創建、發送、接收和讀取消息。它使分布式通信耦合度更低,消息服務更加可靠以及異步性。
ActiveMQ 就是基于 JMS 規范實現的。
2 JMS 消息模型
2.1 P2P(point to point)點對點模式
P2P模式包含三個角色:消息隊列(Queue)、發送者(Sender)、接收者(Receiver)。每個消息都被發送到一個特定的隊列,接收者從隊列中獲取消息。隊列保留消息 ,直到他們被消費或超時。
P2P的特點:
- 每個消息只有一個消費者(Consumer)(即一旦被消費,消息就不再在消息隊列中)。
- 發送者和接收者之間在時間上沒有依賴性,也就是說當大發送者發送了消息之后,不管接收者有沒有正在運行 ,他不會影響到消息被發送到隊列。
- 接收者在成功接收消息之后需向隊列應答成功。
如果希望發送的每個消息都會被成功處理的話,那么需要P2P模式。
2.2 Publish/Subscribe(Pub/Sub)發布訂閱模式
Pub/Sub模式包含三個角色:主題(Topic)、發布者(Publisher)、訂閱者(Subscriber)。多個 發布者將消息發布到Topic,系統將這些消息傳遞給多個訂閱者。
![消息隊列-pub/sub.jpg
Pub/Sub的特點:
- 每個消息可以有多個消費者。
- 發布者和訂閱者之間沒有時間上的依賴性,針對某個主題(Topic)的訂閱者,他必須創建一個訂閱之后,才能消費發布者的消息。
- 為了消費消息,訂閱者必須保持運行的狀態。[為了緩和這樣嚴格的時間相關性,JMS允許訂閱者創建一個可持久化的訂閱。這樣即使訂閱者沒有被激活(運行),它也能收到發布者發布的消息。]
如果希望發送的消息可以被多個消費者處理的話,那么可以采用Pub/Sub模型。
2.3 JMS 五種不同的正文消息格式
JMS定義了五種不同的消息正文格式,以及調用的消息類型,允許你發送并接收以一些不同形式的數據,提供現有消息格式的一些級別的兼容性。
- StreamMessage -- Java原始值的數據流
- MapMessage--一套名稱-值對
- TextMessage--一個字符串對象
- ObjectMessage--一個序列化的 Java對象
- BytesMessage--一個字節的數據流
3 AMQP
3.1 AMQP簡介
AMQP,即Advanced Message Queuing Protocol,一個提供統一消息服務的應用層標準 高級消息隊列協議(二進制應用層協議),是應用層協議的一個開放標準,為面向消息的中間件設計,兼容 JMS。基于此協議的客戶端與消息中間件可傳遞消息,并不受客戶端/中間件同產品,不同的開發語言等條件的限制。
RabbitMQ 就是基于 AMQP 協議實現的。
4 JMS與AMQP對比
| 定義 | Java API | 協議 |
| 跨語言 | 否 | 是 |
| 跨平臺 | 否 | 是 |
| 支持消息類型 | 提供兩種消息模型:①Peer-2-Peer;②Pub/sub | 提供了五種消息模型:①direct exchange;②fanout exchange;③topic change;④headers exchange;⑤system exchange。本質來講,后四種和JMS的pub/sub模型沒有太大差別,僅是在路由機制上做了更詳細的劃分; |
| 支持消息類型 | 支持多種消息類型 ,我們在上面提到過 | byte[](二進制) |
總結:
- AMQP 為消息定義了線路層(wire-level protocol)的協議,而JMS所定義的是API規范。在 Java 體系中,多個client均可以通過JMS進行交互,不需要應用修改代碼,但是其對跨平臺的支持較差。而AMQP天然具有跨平臺、跨語言特性。
- JMS 支持TextMessage、MapMessage 等復雜的消息類型;而 AMQP 僅支持 byte[] 消息類型(復雜的類型可序列化后發送)。
- 由于Exchange 提供的路由算法,AMQP可以提供多樣化的路由方式來傳遞消息到消息隊列,而 JMS 僅支持 隊列 和 主題/訂閱 方式兩種。
三、常見消息隊列對比總結
| 吞吐量 | 萬級的 ActiveMQ 和 RabbitMQ 的吞吐量(ActiveMQ 的性能最差)要比 十萬級甚至是百萬級的 RocketMQ 和 Kafka 低一個數量級。 |
| 可用性 | 都可以實現高可用。ActiveMQ 和 RabbitMQ 都是基于主從架構實現高可用性。RocketMQ 基于分布式架構。 kafka 也是分布式的,一個數據多個副本,少數機器宕機,不會丟失數據,不會導致不可用 |
| 時效性 | RabbitMQ 基于erlang開發,所以并發能力很強,性能極其好,延時很低,達到微秒級。其他三個都是 ms 級。 |
| 功能支持 | 除了 Kafka,其他三個功能都較為完備。 Kafka 功能較為簡單,主要支持簡單的MQ功能,在大數據領域的實時計算以及日志采集被大規模使用,是事實上的標準 |
| 消息丟失 | ActiveMQ 和 RabbitMQ 丟失的可能性非常低, RocketMQ 和 Kafka 理論上不會丟失。 |
總結:
- ActiveMQ 的社區算是比較成熟,但是較目前來說,ActiveMQ 的性能比較差,而且版本迭代很慢,不推薦使用。
- RabbitMQ 在吞吐量方面雖然稍遜于 Kafka 和 RocketMQ ,但是由于它基于 erlang 開發,所以并發能力很強,性能極其好,延時很低,達到微秒級。但是也因為 RabbitMQ 基于 erlang 開發,所以國內很少有公司有實力做erlang源碼級別的研究和定制。如果業務場景對并發量要求不是太高(十萬級、百萬級),那這四種消息隊列中,RabbitMQ 一定是你的首選。如果是大數據領域的實時計算、日志采集等場景,用 Kafka 是業內標準的,絕對沒問題,社區活躍度很高,絕對不會黃,何況幾乎是全世界這個領域的事實性規范。
- RocketMQ 阿里出品,Java 系開源項目,源代碼我們可以直接閱讀,然后可以定制自己公司的MQ,并且 RocketMQ 有阿里巴巴的實際業務場景的實戰考驗。RocketMQ 社區活躍度相對較為一般,不過也還可以,文檔相對來說簡單一些,然后接口這塊不是按照標準 JMS 規范走的有些系統要遷移需要修改大量代碼。還有就是阿里出臺的技術,你得做好這個技術萬一被拋棄,社區黃掉的風險,那如果你們公司有技術實力我覺得用RocketMQ 挺好的
- kafka 的特點其實很明顯,就是僅僅提供較少的核心功能,但是提供超高的吞吐量,ms 級的延遲,極高的可用性以及可靠性,而且分布式可以任意擴展。同時 kafka 最好是支撐較少的 topic 數量即可,保證其超高吞吐量。kafka 唯一的一點劣勢是有可能消息重復消費,那么對數據準確性會造成極其輕微的影響,在大數據領域中以及日志采集中,這點輕微影響可以忽略這個特性天然適合大數據實時計算以及日志收集。
四、更多參考資料匯總[粘貼狂魔 (﹁"﹁)(﹁"﹁)(﹁"﹁)]
1 消息隊列:
2 RabbitMQ
3 ActiveMQ
4 RocketMQ
5 Kafka
6 RabbitMQ/ActiveMQ/RocketMQ/Kafka對比
轉載于:https://www.cnblogs.com/nm666/p/10326345.html
總結
- 上一篇: ONTAK2010 Peaks加强版(离
- 下一篇: 三部排序|2013年蓝桥杯B组题解析第六