訊息佇列概念與認知

廚房有隻偷吃的貓發表於2019-01-27
佇列

MQ學習系列：

  1. 訊息佇列概念與認知
  2. ActiveMQ Topic訊息重發

  3. ActiveMQ Topic 持久化訂閱

本文是-訊息佇列學習的概念與介紹篇。目的是能夠對訊息佇列能夠有一個簡單的瞭解和大體的認知。

參考/學習資料整理（好東西要學會分享 ）

B站上的黑馬ActiveMQ的視訊教程

Hollis公眾號上的訊息佇列文章

架構之家公眾號上的訊息佇列文章

JavaGuide（一份涵蓋大部分Java程式設計師所需要掌握的核心知識的文件類專案）

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

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

一個線上繪圖的工具

一、訊息佇列簡介

訊息佇列 MQ（message queue）中介軟體是分散式系統中的重要元件，主要解決非同步訊息、應用解耦、流量 削峰等問題，從而實現高效能、高可用 ，可伸縮和最終一致性的架構。

使用較多的訊息佇列有ActiveMQ 、RabbitMQ、RocketMQ、Kafka、MetaMQ等

1 訊息佇列應用場景分析

1.1 非同步處理

舉個例子：

有這樣一個使用者註冊場景 ，實現將註冊資訊寫入資料庫併傳送郵件和註冊簡訊的功能。

傳統的方式如圖：

訊息佇列-傳統.PNG

這樣的方式會一步步按照先後順序 完成後返回給使用者資訊 ，整個過程使用者都處於等待的狀態，並用時150ms。

而引用訊息對列 ，非同步處理，改造後的架構如下：

訊息佇列-改進.PNG

這樣對於使用者的響應時間就大大減少了。

1.2 應用解耦

多應用間通過訊息佇列對同一訊息進行處理，避免呼叫介面失敗導致整個過程失敗。

訊息佇列-應用解耦.png

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模型.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 僅支援 佇列 和 主題/訂閱 方式兩種。

三、常見訊息佇列對比總結

對比方向 概要
吞吐量 萬級的 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 訊息佇列：

  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

相關文章