淺談消息隊列及常見的分佈式消息隊列中間件

背景

分佈式消息隊列中間件是是大型分佈式系統不可缺乏的中間件，經過消息隊列，應用程序能夠在不知道彼此位置的狀況下獨立處理消息，或者在處理消息前不須要等待接收此消息。因此消息隊列主要解決應用耦合、異步消息、流量削鋒等問題，實現高性能、高可用、可伸縮和最終一致性架構。消息隊列已經逐漸成爲企業應用系統內部通訊的核心手段，當前使用較多的消息隊列有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ 等，而部分數據庫如 Redis、MySQL 以及 PhxSQL 也可實現消息隊列的功能。

在平常學習與開發過程當中，消息隊列做爲系統不可缺乏的中間件，顯得十分的重要。在現代雲架構中，應用程序被分解爲多個規模較小且更易於開發、部署和維護的獨立構建塊。消息隊列可爲這些分佈式應用程序提供通訊和協調。而本人也在工做的過程當中，前先後後後接觸到了 Kafka、RabbitMQ 兩款消息隊列。因此，本系列文章也主要以 RabbitMQ 和 Kafka 兩款典型的消息中間件來作分析。本文是該系列的開篇，主要講解消息隊列的概述、特色等，而後對消息隊列使用場景進行分析，最後對市面上比較常見的消息隊列產品進行技術對比。

 

消息隊列概述

消息隊列（Message Queue，簡稱 MQ）是指利用高效可靠的消息傳遞機制進行與平臺無關的數據交流，並基於數據通訊來進行分佈式系統的集成。經過提供消息傳遞和消息排隊模型，它能夠在分佈式環境下提供應用解耦、彈性伸縮、冗餘存儲、流量削峯、異步通訊、數據同步等等功能，其做爲分佈式系統架構中的一個重要組件，有着舉足輕重的地位。消息隊列是構建分佈式互聯網應用的基礎設施，經過 MQ 實現的鬆耦合架構設計能夠提升系統可用性以及可擴展性，是適用於現代應用的最佳設計方案。

消息隊列特色

爲何要用消息隊列？

經過異步處理提升系統性能

講解該特色以前，咱們先了解一下同步架構和異步架構的區別：

• 同步調用：是指從請求的發起一直到最終的處理完成期間，請求的調用方一直在同步阻塞等待調用的處理完成。

• 異步調用：是指在請求發起的處理過程當中，客戶端的代碼已經返回了，它能夠繼續進行本身的後續操做，而不須要等待調用處理完成，這就叫作異步調用。

如上圖，在不使用消息隊列服務器的時候，用戶的請求數據直接寫入數據庫，在高併發的狀況下數據庫壓力劇增，使得響應速度變慢。可是在使用消息隊列以後，用戶的請求數據發送給消息隊列以後當即 返回，再由消息隊列的消費者進程從消息隊列中獲取數據，異步寫入數據庫。因爲消息隊列服務器處理速度快於數據庫（消息隊列也比數據庫有更好的伸縮性），所以響應速度獲得大幅改善。

經過以上分析咱們能夠得出消息隊列具備很好的削峯做用的功能——即經過異步處理，將短期高併發產生的事務消息存儲在消息隊列中，從而削平高峯期的併發事務。舉例：在電子商務一些秒殺、促銷活動中，合理使用消息隊列能夠有效抵禦促銷活動剛開始大量訂單涌入對系統的衝擊。以下圖所示：

由於用戶請求數據寫入消息隊列以後就當即返回給用戶了，可是請求數據在後續的業務校驗、寫數據庫等操做中可能失敗。所以使用消息隊列進行異步處理以後，須要適當修改業務流程進行配合，好比用戶在提交訂單以後，訂單數據寫入消息隊列，不能當即返回用戶訂單提交成功，須要在消息隊列的訂單消費者進程真正處理完該訂單以後，甚至出庫後，再經過電子郵件或短信通知用戶訂單成功，以避免交易糾紛。這就相似咱們平時手機訂火車票和電影票。

下降系統耦合性

咱們知道若是模塊之間不存在直接調用，那麼新增模塊或者修改模塊就對其餘模塊影響較小，這樣系統的可擴展性無疑更好一些。

咱們最多見的事件驅動架構相似生產者消費者模式，在大型網站中一般用利用消息隊列實現事件驅動結構。以下圖所示：

消息隊列使利用發佈 - 訂閱模式工做，消息發送者（生產者）發佈消息，一個或多個消息接受者（消費者）訂閱消息。從上圖能夠看到消息發送者（生產者）和消息接受者（消費者）之間沒有直接耦合，消息發送者將消息發送至分佈式消息隊列即結束對消息的處理，消息接受者從分佈式消息隊列獲取該消息後進行後續處理，並不須要知道該消息從何而來。對新增業務，只要對該類消息感興趣，便可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展性設計。

消息接受者對消息進行過濾、處理、包裝後，構形成一個新的消息類型，將消息繼續發送出去，等待其餘消息接受者訂閱該消息。所以基於事件（消息對象）驅動的業務架構能夠是一系列流程。

另外爲了不消息隊列服務器宕機形成消息丟失，會將成功發送到消息隊列的消息存儲在消息生產者服務器上，等消息真正被消費者服務器處理後才刪除消息。在消息隊列服務器宕機後，生產者服務器會選擇分佈式消息隊列服務器集羣中的其餘服務器發佈消息。

使用消息隊列帶來的一些問題？

• 系統可用性下降：系統可用性在某種程度上下降，爲何這樣說呢？在加入 MQ 以前，你不用考慮消息丟失或者說 MQ 掛掉等狀況，可是，引入 MQ 以後你就須要如何保證消息隊列的高可用。

• 系統複雜性提升：加入 MQ 以後，你須要保證消息沒有被重複消費、處理消息丟失的狀況、保證消息傳遞的順序性等等問題，系統複發性提升。

• 一致性問題：消息隊列帶來的異步確實能夠提升系統響應速度。可是，萬一消息的真正消費者並無正確消費消息怎麼辦？這樣就會致使數據不一致的狀況。

JMS VS AMQP

JMS

Java 消息服務（Java Message Service，JMS）應用程序接口是一個 Java 平臺中關於面向消息中間件（MOM）的 API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通訊。JMS 的客戶端之間能夠經過 JMS 服務進行異步的消息傳輸。JMS PI 是一個消息服務的標準或者說是規範，容許應用程序組件基於 JavaEE 平臺建立、發送、接收和讀取消息。它使分佈式通訊耦合度更低，消息服務更加可靠以及異步性。點對點與發佈訂閱最初是由 JMS 定義的。這兩種模式主要區別或解決的問題就是發送到隊列的消息可否重複消費。

JMS 規範目前支持兩種消息模型：點對點（point to point，queue）和發佈 / 訂閱（publish/subscribe，topic）。

點對點（P2P）模型

消息生產者向消息隊列中發送了一個消息以後，只能被一個消費者消費一次。點對點（P2P）使用隊列（Queue）做爲消息通訊載體；知足生產者與消費者模式，一條消息只能被一個消費者使用，未被消費的消息在隊列中保留直到被消費或超時。

Queue 實現了負載均衡，一個消息只能被一個消費者接受，當沒有消費者可用時，這個消息會被保存直到有 一個可用的消費者，一個 queue 能夠有不少消費者，他們之間實現了負載均衡， 因此 Queue 實現了一個可靠的負載均衡。

特色：

• 每一個消息只用一個消費者；

• 發送者和接受者沒有時間依賴；

• 接受者確認消息接受和處理成功。

發佈 / 訂閱（Pub/Sub）模型

消息生產者向頻道發送一個消息以後，多個消費者能夠從該頻道訂閱到這條消息並消費。發佈訂閱模型（Pub/Sub） 使用主題（Topic）做爲消息通訊載體，相似於廣播模式；發佈者發佈一條消息，該消息經過主題傳遞給全部的訂閱者，在一條消息廣播以後才訂閱的用戶則是收不到該條消息的。

Topic 實現了發佈和訂閱，當你發佈一個消息，全部訂閱這個 Topic 的服務都能獲得這個消息，因此從 1 到 N 個訂閱者都能獲得一個消息的拷貝， 只有在消息代理收到消息時有一個有效訂閱時的訂閱者才能獲得這個消息的拷貝。

特色：

• 每一個消息能夠有多個訂閱者；

• 客戶端只有訂閱後才能接收到消息；

• 持久訂閱和非持久訂閱。

注意：

1. 發佈者和訂閱者有時間依賴：接受者和發佈者只有創建訂閱關係才能收到消息；

2. 持久訂閱：訂閱關係創建後，消息就不會消失，無論訂閱者是否都在線；

3. 非持久訂閱：訂閱者爲了接受消息，必須一直在線。當只有一個訂閱者時約等於點對點模型。

點對點（P2P）模型與發佈 / 訂閱（Pub/Sub）模型應用

• 點對點模型：主要用於一些耗時較長的、邏輯相對獨立的業務。

好比說發送郵件這樣一個操做。由於發送郵件比較耗時，並且應用程序其實也並不太關心郵件發送是否成功，發送郵件的邏輯也相對比較獨立，因此它只須要把郵件消息丟到消息隊列中就能夠返回了，而消費者也不須要關心是哪一個生產者去發送的郵件，它只須要把郵件消息內容取出來之後進行消費，經過遠程服務器將郵件發送出去就能夠了。並且每一個郵件只須要被髮送一次。因此消息只被一個消費者消費就能夠了。

• 發佈訂閱模型：如新用戶註冊這樣一個消息，須要使用按主題發佈的方式。

好比新用戶註冊，一個新用戶註冊成功之後，須要給用戶發送一封激活郵件，發送一條歡迎短信，還須要將用戶註冊數據寫入數據庫，甚至須要將新用戶信息發送給關聯企業的系統，好比淘寶新用戶信息發送給支付寶，這樣容許用戶能夠一次註冊就能登陸使用多個關聯產品。一個新用戶註冊，會把註冊消息發送給一個主題，多種消費者能夠訂閱這個主題。好比發送郵件的消費者、發送短信的消費者、將註冊信息寫入數據庫的消費者，跨系統同步消息的消費者等。

AMQP

AMQP（advanced message queuing protocol）在 2003 年時被提出，最先用於解決金融領不一樣平臺之間的消息傳遞交互問題。顧名思義，AMQP 是一種協議，更準確的說是一種 binary wire-level protocol（連接協議）。這是其和 JMS 的本質差異，AMQP 不從 API 層進行限定，而是直接定義網絡交換的數據格式。這使得實現了 AMQP 的 provider 自然性就是跨平臺的。意味着咱們可使用 Java 的 AMQP provider，同時使用一個 python 的 producer 加一個 rubby 的 consumer。

在 AMQP 中，消息路由（message routing）和 JMS 存在一些差異，在 AMQP 中增長了 Exchange 和 binding 的角色。producer 將消息發送給 Exchange，binding 決定 Exchange 的消息應該發送到那個 queue，而 consumer 直接從 queue 中消費消息。

AMQP 提供五種消息模型：①Direct Exchange；②Fanout Exchange；③Topic Exchange；④Headers Exchange；⑤System Exchange。本質來說，後四種和 JMS 的 pub/sub 模型沒有太大差異，僅是在路由機制上作了更詳細的劃分。

JMS 與 AMQP 對比

總結：

• AMQP 爲消息定義了線路層（wire-level protocol）的協議，而 JMS 所定義的是 API 規範。在 Java 體系中，多個 client 都可以經過 JMS 進行交互，不須要應用修改代碼，可是其對跨平臺的支持較差。而 AMQP 自然具備跨平臺、跨語言特性。

• JMS 支持 TextMessage、MapMessage 等複雜的消息類型；而 AMQP 僅支持 byte[] 消息類型（複雜的類型可序列化後發送）。

• 因爲 Exchange 提供的路由算法，AMQP 能夠提供多樣化的路由方式來傳遞消息到消息隊列，而 JMS 僅支持 隊列 和 主題 / 訂閱 方式兩種。

消息隊列推拉模型

Push 推消息模型：消息生產者將消息發送給消息隊列，消息隊列又將消息推給消息消費者。

Pull 拉消息模型：消費者請求消息隊列接受消息，消息生產者從消息隊列中拉該消息。

 

RabbitMQ

RabbitMQ 實現了 AQMP 協議，AQMP 協議定義了消息路由規則和方式。生產端經過路由規則發送消息到不一樣 queue，消費端根據 queue 名稱消費消息。此外 RabbitMQ 是向消費端推送消息，訂閱關係和消費狀態保存在服務端。

Kafka

Kafka 只支持消息持久化，消費端爲拉模型，消費狀態和訂閱關係由客戶端端負責維護，消息消費完後不會當即刪除，會保留歷史消息。所以支持多訂閱時，消息只會存儲一份就能夠了。同一個訂閱組會消費 topic 全部消息，每條消息只會被同一個訂閱組的一個消費節點消費，同一個訂閱組內不一樣消費節點會消費不一樣消息。

 

 

 

消息隊列使用場景

異步處理：實現異步處理，提高處理性能

對一些比較耗時的操做，能夠把處理過程經過消息隊列進行異步處理。這樣作能夠推遲耗時操做的處理，使耗時操做異步化，而沒必要阻塞客戶端的程序，客戶端的程序在獲得處理結果以前就能夠繼續執行，從而提升客戶端程序的處理性能。非核心流程異步化，減小系統響應時間，提升吞吐量。

例如：短信通知、終端狀態推送、App 推送、用戶註冊等。

解耦：可使生產者和消費者的代碼實現解耦合

能夠多個生產者發佈消息，多個消費者處理消息，共同完成完整的業務處理邏輯，可是它們的不須要直接的交互調用，沒有代碼的依賴耦合。在傳統的同步調用中，調用者代碼必需要依賴被調用者的代碼，也就是生產者代碼必需要依賴消費者的處理邏輯代碼，代碼須要直接的耦合，而使用消息隊列，這兩部分的代碼不須要進行任何的耦合。由於耦合程度越低的代碼越容易維護，也越容易進行擴展。

好比新用戶註冊，若是用傳統同步調用的方式，那麼發郵件、發短信、寫數據庫、通知關聯繫統這些代碼會和用戶註冊代碼直接耦合起來，整個代碼看起來就是完成用戶註冊邏輯後，後面必然跟着發郵件、發短信這些代碼。若是要新增一個功能，好比將監控用戶註冊狀況，將註冊信息發送到業務監控系統，就必需要修改前面的代碼，至少增長一行代碼，發送註冊信息到監控系統，咱們知道，任何代碼的修改均可能會引發 bug。

而使用分佈式消息隊列實現生產者和消費者解耦合之後，用戶註冊之後，不須要調用任何後續處理代碼，只須要將註冊消息發送到分佈式消息隊列就能夠了。若是要增長新功能，只須要寫個新功能的消費者程序，在分佈式消息隊列中，訂閱用戶註冊主題就能夠了，不須要修改原來任何一行代碼。

流量削峯和流控：能夠平衡流量峯值，削峯填谷

當上下游系統處理能力存在差距的時候，利用消息隊列作一個通用的 「漏斗」，進行限流控制。在下游有能力處理的時候，再進行分發。

使用消息隊列，即使是訪問流量持續的增加，系統依然能夠持續地接收請求。這種狀況下，雖然生產者發佈消息的速度比消費者消費消息的速度快，可是能夠持續的將消息歸入到消息隊列中，用消息隊列做爲消息的緩衝，所以短期內，發佈者不會受到消費處理能力的影響。

在訪問高峯，用戶的併發訪問數可能超過了系統的處理能力，因此在高峯期就可能會致使系統負載過大，響應速度變慢，更嚴重的可能會致使系統崩潰。這種狀況下，經過消息隊列將用戶請求的消息歸入到消息隊列中，經過消息隊列緩衝消費者處理消息的速度。

消息的生產者它有高峯有低谷，可是到了消費者這裏，只會按照本身的最佳處理能力去消費消息。高峯期它會把消息緩衝在消息隊列中，而在低谷期它也仍是使用本身最大的處理能力去獲取消息，將前面緩衝起來、來不及及時處理的消息處理掉。那麼，經過這種手段能夠實現系統負載消峯填谷，也就是說將訪問的高峯消掉，而將訪問的低谷填平，使系統處在一個最佳的處理狀態之下，不會對系統的負載產生太大的衝擊。

舉個例子：用戶在支付系統成功結帳後，訂單系統會經過短信系統向用戶推送扣費通知。短信系統可能因爲短板效應，速度卡在網關上（每秒幾百次請求），跟前端的併發量不是一個數量級。因而，就形成支付系統和短信系統的處理能力出現差別化。

然而用戶晚上個半分鐘左右收到短信，通常是不會有太大問題的。若是沒有消息隊列，兩個系統之間經過協商、滑動窗口等複雜的方案也不是說不能實現。但系統複雜性指數級增加，勢必在上游或者下游作存儲，而且要處理定時、擁塞等一系列問題。並且每當有處理能力有差距的時候，都須要單獨開發一套邏輯來維護這套邏輯。因此，利用中間系統轉儲兩個系統的通訊內容，並在下游系統有能力處理這些消息的時候，再處理這些消息，是一套相對較通用的方式。

易伸縮：可讓系統得到更好的伸縮性

耗時的任務能夠經過分佈式消息隊列，向多臺消費者服務器並行發送消息，而後在不少臺消費者服務器上並行處理消息，也就是說能夠在多臺物理服務器上運行消費者。那麼當負載上升的時候，能夠很容易地添加更多的機器成爲消費者。

例如：用戶上傳文件後，經過發佈消息的方式，通知後端的消費者獲取數據、讀取文件，進行異步的文件處理操做。那麼當前端發佈更多文件的時候，或者處理邏輯比較複雜的時候，就能夠經過添加後端的消費者服務器，提供更強大的處理能力。

隔離失效機器以及自我修復：失敗隔離和自我修復

由於發佈者不直接依賴消費者，因此分佈式消息隊列能夠將消費者系統產生的錯誤異常與生產者系統隔離開來，生產者不受消費者失敗的影響。當在消息消費過程當中出現處理邏輯失敗的時候，這個錯誤只會影響到消費者自身，而不會傳遞給消息的生產者，也就是應用程序能夠按照原來的處理邏輯繼續執行。

因此，這也就意味着在任什麼時候候均可以對後端的服務器執行維護和發佈操做。能夠重啓、添加或刪除服務器，而不影響生產者的可用性，這樣簡化了部署和服務器管理的難度。

日誌處理

日誌處理是指將消息隊列用在日誌處理中，好比 Kafka 的應用，解決大量日誌傳輸和緩衝的問題。日誌採集客戶端，負責日誌數據採集，定時寫受寫入 Kafka 隊列；Kafka 消息隊列，負責日誌數據的接收，存儲和轉發；日誌處理應用，訂閱並消費 kafka 隊列中的日誌數據。

消息隊列技術對比

• ActiveMQ 是 Apache 出品的、採用 Java 語言編寫的徹底基於 JMS1.1 規範的面向消息的中間件，爲應用程序提供高效的、可擴展的、穩定的和安全的企業級消息通訊。不過因爲歷史緣由包袱過重，目前市場份額沒有後面三種消息中間件多，其最新架構被命名爲 Apollo，號稱下一代 ActiveMQ，有興趣的同窗可行了解。

• RabbitMQ 是採用 Erlang 語言實現的 AMQP 協議的消息中間件，最初起源於金融系統，用於在分佈式系統中存儲轉發消息。RabbitMQ 發展到今天，被愈來愈多的人承認，這和它在可靠性、可用性、擴展性、功能豐富等方面的卓越表現是分不開的。主要特色是性能好，社區活躍，可是 RabbitMQ 用 Erlang 開發，咱們的應用不多用 Erlang，因此不便於二次開發和維護。

• Kafka 是由 LinkedIn 公司採用 Scala 語言開發的一個分佈式、多分區、多副本且基於 zookeeper 協調的分佈式消息系統，現已捐獻給 Apache 基金會。它是一種高吞吐量的分佈式發佈訂閱消息系統，以可水平擴展和高吞吐率而被普遍使用。目前愈來愈多的開源分佈式處理系統如 Cloudera、Apache Storm、Spark、Flink 等都支持與 Kafka 集成。

• RocketMQ 是阿里開源的消息中間件，目前在 Apache 孵化，使用純 Java 開發，具備高吞吐量、高可用性、適合大規模分佈式系統應用的特色。RocketMQ 思路起源於 Kafka，但並非簡單的複製，它對消息的可靠傳輸及事務性作了優化，目前在阿里集團被普遍應用於交易、充值、流計算、消息推送、日誌流式處理、binglog 分發等場景，支撐了阿里屢次雙十一活動。

• ZeroMQ 是基於 C 語言開發，號稱史上最快的消息隊列。ZeroMQ 是一個消息處理隊列庫，可在多線程、多內核和主機之間彈性伸縮，雖然大多數時候咱們習慣將其納入消息隊列家族之中，可是其和前面的幾款有着本質的區別，ZeroMQ 自己就不是一個消息隊列服務器，更像是一組底層網絡通信庫，對原有的 Socket API 上加上一層封裝而已。

總結：

• ActiveMQ 的社區算是比較成熟，可是較目前來講，ActiveMQ 的性能比較差，並且版本迭代很慢，不推薦使用。

• RabbitMQ 在吞吐量方面雖然稍遜於 Kafka 和 RocketMQ ，可是因爲它基於 erlang 開發，因此併發能力很強，性能極其好，延時很低，達到微秒級。可是也由於 RabbitMQ 基於 erlang 開發，因此國內不多有公司有實力作 erlang 源碼級別的研究和定製。若是業務場景對併發量要求不是過高（十萬級、百萬級），那這四種消息隊列中，RabbitMQ 必定是你的首選。若是是大數據領域的實時計算、日誌採集等場景，用 Kafka 是業內標準的，絕對沒問題，社區活躍度很高，絕對不會黃，況且幾乎是全世界這個領域的事實性規範。

• RocketMQ 阿里出品，Java 系開源項目，源代碼咱們能夠直接閱讀，而後能夠定製本身公司的 MQ，而且 RocketMQ 有阿里巴巴的實際業務場景的實戰考驗。RocketMQ 社區活躍度相對較爲通常，不過也還能夠，文檔相對來講簡單一些，而後接口這塊不是按照標準 JMS 規範走的有些系統要遷移須要修改大量代碼。還有就是阿里出臺的技術，你得作好這個技術萬一被拋棄，社區黃掉的風險，那若是大家公司有技術實力我以爲用 RocketMQ 挺好的

• kafka 最初設計時就是針對互聯網的分佈式、高可用應用場景而設計，因此其特色其實很明顯，就是僅僅提供較少的核心功能，可是提供超高的吞吐量，ms 級的延遲，極高的可用性以及可靠性，並且分佈式能夠任意擴展。同時 kafka 最好是支撐較少的 topic 數量便可，保證其超高吞吐量。kafka 惟一的一點劣勢是有可能消息重複消費，那麼對數據準確性會形成極其輕微的影響，在大數據領域中以及日誌採集中，這點輕微影響能夠忽略這個特性自然適合大數據實時計算以及日誌收集。