消息隊列概念與認知

MQ學習系列:php

  1. 消息隊列概念與認知
  2. ActiveMQ Topic消息重發
  3. ActiveMQ Topic 持久化訂閱
  4. zookeeper+ActiveMQ集羣實現高可用

本文是-消息隊列學習的概念與介紹篇。目的是可以對消息隊列可以有一個簡單的瞭解和大致的認知。html

參考/學習資料整理(好東西要學會分享 )java

B站上的黑馬ActiveMQ的視頻教程git

Hollis公衆號上的消息隊列文章程序員

架構之家公衆號上的消息隊列文章github

JavaGuide(一份涵蓋大部分Java程序員所須要掌握的核心知識的文檔類項目)面試

CS-Notes(技術面試必備基礎知識)算法

JCSprout(處於萌芽階段的 Java 核心知識庫)數據庫

一個在線繪圖的工具apache

1、消息隊列簡介

消息隊列 MQ(message queue)中間件是分佈式系統中的重要組件,主要解決異步消息、應用解耦、流量 削峯等問題,從而實現高性能、高可用 ,可伸縮和最終一致性的架構。

使用較多的消息隊列有ActiveMQ 、RabbitMQ、RocketMQ、Kafka、MetaMQ等

1 消息隊列應用場景分析

1.1 異步處理

舉個栗子:

有這樣一個用戶註冊場景 ,實現將註冊信息寫入數據庫併發送郵件和註冊短信的功能。

傳統的方式如圖:

消息隊列-傳統.PNG

這樣的方式會一步步按照前後順序 完成後返回給用戶信息 ,整個過程用戶都處於等待的狀態,並用時150ms。

而引用消息對列 ,異步處理,改造後的架構以下

消息隊列-改進.PNG

這樣對於用戶的響應時間就大大減小了。

1.2 應用解耦

多應用間經過消息隊列對同一消息進行處理,避免調用接口失敗致使整個過程失敗。

消息隊列-應用解耦.png

1.3 流量削峯

普遍應用於秒殺或搶購活動中,避免流量過大致使應用系統掛掉的狀況。

具體場景:購物網站開展秒殺活動,通常因爲瞬時訪問量過大,服務器接收過大,會致使流量暴增,相關係統沒法處理請求甚至崩潰。而加入消息隊列後,系統能夠從消息隊列中取數據,至關於消息隊列作了一次緩衝。

2、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模型.png

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對比

對比方向 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 僅支持 隊列 和 主題/訂閱 方式兩種。

3、常見消息隊列對比總結

對比方向 概要
吞吐量 萬級的 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 惟一的一點劣勢是有可能消息重複消費,那麼對數據準確性會形成極其輕微的影響,在大數據領域中以及日誌採集中,這點輕微影響能夠忽略這個特性自然適合大數據實時計算以及日誌收集。

4、更多參考資料彙總[粘貼狂魔 (﹁"﹁)(﹁"﹁)(﹁"﹁)]

1 消息隊列:

  1. 大型網站架構之分佈式消息隊列 http://blog.csdn.net/shaobingj126/article/details/50585035
  2. 消息隊列的使用場景 https://www.zhihu.com/question/34243607/answer/127666030
  3. 淺談異步消息隊列模型 http://www.cnblogs.com/sunkeydev/p/5248855.html
  4. 消息隊列的兩種模式 http://blog.csdn.net/heyutao007/article/details/50131089

2 RabbitMQ

  1. RabbitMQ主頁 https://www.rabbitmq.com/
  2. RabbitMQ學習教程 https://www.rabbitmq.com/getstarted.html
  3. 專欄:RabbitMQ從入門到精通 http://blog.csdn.net/column/details/rabbitmq.html
  4. RabbitMQ能爲你作些什麼 http://rabbitmq.mr-ping.com/description.html
  5. RabbitMQ指南(1)-特性及功能 https://blog.zenfery.cc/archives/79.html

3 ActiveMQ

  1. ActiveMQ主頁 http://activemq.apache.org/
  2. Apache ActiveMQ介紹 http://jfires.iteye.com/blog/1187688
  3. ActiveMQ的簡介與安裝 http://blog.csdn.net/sl1992/article/details/72824562
  4. ActiveMQ 和消息簡介 http://www.cnblogs.com/craftsman-gao/p/7002605.html

4 RocketMQ

  1. 主頁 https://github.com/alibaba/RocketMQ
  2. RocketMQ 原理簡介 http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf
  3. RocketMQ與kafka對比(18項差別) http://jm.taobao.org/2016/03/24/rmq-vs-kafka/

5 Kafka

  1. Kafka主頁: http://kafka.apache.org/
  2. Kafka特性 http://www.cnblogs.com/lsx1993/p/4847719.html
  3. Kafka客戶端支持語言 https://cwiki.apache.org/confluence/display/KAFKA/Clients

6 RabbitMQ/ActiveMQ/RocketMQ/Kafka對比

  1. RocketMQ,隊列選型 http://www.zmannotes.com/index.php/2016/01/17/rocketmq/
  2. RabbitMQ和Kafka http://www.dongcoder.com/detail-416804.html
  3. 即時通訊RabbitMQ二-性能測試 http://www.jianshu.com/p/d31ae9e3bfb6
  4. RabbitMq、ActiveMq、ZeroMq、kafka之間的比較,資料彙總 http://blog.csdn.net/linsongbin1/article/details/47781187
  5. 消息隊列軟件產品大比拼 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html
相關文章
相關標籤/搜索