1 介紹

RocketMQ作為一款純java、分布式、隊列模型的開源消息中間件，支持事務消息、順序消息、批量消息、定時消息、消息回溯等。

1.1 RocketMQ 特點

• 支持發(fā)布/訂閱（Pub/Sub）和點對點（P2P）消息模型
• 在一個隊列中可靠的先進先出（FIFO）和嚴格的順序傳遞 （RocketMQ可以保證嚴格的消息順序，而ActiveMQ無法保證）
• 支持拉（pull）和推（push）兩種消息模式

pull其實就是消費者主動從MQ中去拉消息，而push則像rabbit MQ一樣，是MQ給消費者推送消息。但是RocketMQ的push其實是基于pull來實現(xiàn)的。 它會先由一個業(yè)務代碼從MQ中pull消息，然后再由業(yè)務代碼push給特定的應用/消費者。其實底層就是一個pull模式

• 單一隊列百萬消息的堆積能力 （RocketMQ提供億級消息的堆積能力，這不是重點，重點是堆積了億級的消息后，依然保持寫入低延遲）
• 支持多種消息協(xié)議，如 JMS、MQTT 等
• 分布式高可用的部署架構(gòu),滿足至少一次消息傳遞語義（RocketMQ原生就是支持分布式的，而ActiveMQ原生存在單點性）
• 提供 docker 鏡像用于隔離測試和云集群部署
• 提供配置、指標和監(jiān)控等功能豐富的 Dashboard

1.2 RocketMQ 優(yōu)勢

• 目前主流的 MQ 主要是 RocketMQ、kafka、RabbitMQ，其主要優(yōu)勢有：
• 支持事務型消息（消息發(fā)送和 DB 操作保持兩方的最終一致性，RabbitMQ 和 Kafka 不支持）
• 支持結(jié)合 RocketMQ 的多個系統(tǒng)之間數(shù)據(jù)最終一致性（多方事務，二方事務是前提）
• 支持 18 個級別的延遲消息（Kafka 不支持）
• 支持指定次數(shù)和時間間隔的失敗消息重發(fā)（Kafka 不支持，RabbitMQ 需要手動確認）
• 支持 Consumer 端 Tag 過濾，減少不必要的網(wǎng)絡傳輸（即過濾由MQ完成，而不是由消費者完成。RabbitMQ 和 Kafka 不支持）
• 支持重復消費（RabbitMQ 不支持，Kafka 支持）

2 RocketMQ 基本概念

RocketMQ主要有四大核心組成部分：NameServer、Broker、Producer以及Consumer四部分。

2.1 NameServer

Name Server是一個幾乎無狀態(tài)節(jié)點，可集群部署，節(jié)點之間無任何信息同步。

NameServer 是整個 RocketMQ 的“大腦” ，它是 RocketMQ 的服務注冊中心，所以 RocketMQ 需要先啟動 NameServer 再啟動 Rocket 中的 Broker。

2.1.1 NameServer作用

名稱服務器（NameServer）用來保存 Broker 相關(guān)元信息并給 Producer 和 Consumer 查找Broker 信息。NameServer 被設計成幾乎無狀態(tài)的，可以橫向擴展，節(jié)點之間相互之間無通信，通過部署多臺機器來標記自己是一個偽集群。

每個 Broker 在啟動的時候會到 NameServer 注冊，Producer 在發(fā)送消息前會根據(jù) Topic 到NameServer 獲取到 Broker 的路由信息，進而和Broker取得連接。Consumer 也會定時獲取 Topic 的路由信息。所以從功能上看應該是和 ZooKeeper 差不多，據(jù)說 RocketMQ 的早期版本確實是使用的ZooKeeper ，后來改為了自己實現(xiàn)NameServer 。

2.1.2 和zk的區(qū)別

Name Server和ZooKeeper的作用大致是相同的，從宏觀上來看，Name Server做的東西很少，就是保存一些運行數(shù)據(jù)，Name Server之間不互連，這就需要broker端連接所有的Name Server，運行數(shù)據(jù)的改動要發(fā)送到每一個Name Server來保證運行數(shù)據(jù)的一致性（這個一致性確實有點弱），這樣就變成了Name Server很輕量級，但是broker端就要做更多的東西了。

而ZooKeeper呢，broker只需要連接其中的一臺機器，運行數(shù)據(jù)分發(fā)、一致性都交給了ZooKeeper來完成。

2.1.3 高可用保障

Broker 在啟動時向所有 NameServer 注冊（主要是服務器地址等） ，生產(chǎn)者在發(fā)送消息之前先從NameServer 獲取 Broker 服務器地址列表（消費者一樣），然后根據(jù)負載均衡算法從列表中選擇一臺服務器進行消息發(fā)送。

NameServer 與每臺 Broker 服務保持長連接，并間隔 30S 檢查 Broker 是否存活，如果檢測到Broker 宕機，則從路由注冊表中將其移除，這樣就可以實現(xiàn) RocketMQ 的高可用。

2.2 Broker

消息服務器（Broker）是消息存儲中心，主要作用是接收來自 Producer 的消息并存儲，Consumer 從這里取得消息。它還存儲與消息相關(guān)的元數(shù)據(jù)，包括用戶組、消費進度偏移量、隊列信息等。從部署結(jié)構(gòu)圖中可以看出 Broker 有 Master 和 Slave 兩種類型，Master 既可以寫又可以讀，Slave不可以寫只可以讀。

2.2.1 部署方式

Broker部署相對復雜，Broker分為Master與Slave，一個Master可以對應多個Slave，但是一個Slave只能對應一個Master，Master與Slave的對應關(guān)系通過指定相同的Broker Name，不同的BrokerId來定義，BrokerId為0表Master，非0表示Slave。Master也可以部署多個。

從物理結(jié)構(gòu)上看 Broker 的集群部署方式有四種：單 Master 、多 Master 、多 Master 多Slave（同步刷盤）、多 Master多 Slave（異步刷盤）。

2.2.1.1 單 Master

這種方式一旦 Broker 重啟或宕機會導致整個服務不可用，這種方式風險較大，所以顯然不建議線上環(huán)境使用。

2.2.1.2 多 Master

所有消息服務器都是 Master ，沒有 Slave 。這種方式優(yōu)點是配置簡單，單個 Master 宕機或重啟維護對應用無影響。缺點是單臺機器宕機期間，該機器上未被消費的消息在機器恢復之前不可訂閱，消息實時性會受影響。

2.2.1.3 多 Master 多 Slave（異步復制）

每個 Master 配置一個 Slave，所以有多對 Master-Slave，消息采用異步復制方式，主備之間有毫秒級消息延遲。這種方式優(yōu)點是消息丟失的非常少，且消息實時性不會受影響，Master 宕機后消費者可以繼續(xù)從 Slave 消費，中間的過程對用戶應用程序透明，不需要人工干預，性能同多 Master 方式幾乎一樣。缺點是 Master 宕機時在磁盤損壞情況下會丟失極少量消息。

2.2.1.4 多 Master 多 Slave（同步雙寫）

每個 Master 配置一個 Slave，所以有多對 Master-Slave ，消息采用同步雙寫方式，主備都寫成功才返回成功。這種方式優(yōu)點是數(shù)據(jù)與服務都沒有單點問題，Master 宕機時消息無延遲，服務與數(shù)據(jù)的可用性非常高。缺點是性能相對異步復制方式略低，發(fā)送消息的延遲會略高。

2.2.2 高可用保障

每個Broker與Name Server集群中的所有節(jié)點建立長連接，定時(每隔30s)注冊Topic信息到所有Name Server。Name Server定時(每隔10s)掃描所有存活broker的連接，如果Name Server超過2分鐘沒有收到心跳，則Name Server斷開與Broker的連接。

2.3 生產(chǎn)者（Producer）

也稱為消息發(fā)布者，負責生產(chǎn)并發(fā)送消息至 Topic。 生產(chǎn)者向brokers發(fā)送由業(yè)務應用程序系統(tǒng)生成的消息。RocketMQ提供了發(fā)送：同步、異步和單向（one-way）的多種范例。

2.3.1 同步發(fā)送

同步發(fā)送指消息發(fā)送方發(fā)出數(shù)據(jù)后會在收到接收方發(fā)回響應之后才發(fā)下一個數(shù)據(jù)包。一般用于重要通知消息，例如重要通知郵件、營銷短信。

2.3.2 異步發(fā)送

異步發(fā)送指發(fā)送方發(fā)出數(shù)據(jù)后，不等接收方發(fā)回響應，接著發(fā)送下個數(shù)據(jù)包，一般用于可能鏈路耗時較長而對響應時間敏感的業(yè)務場景，例如用戶視頻上傳后通知啟動轉(zhuǎn)碼服務。假如過一段時間檢測到某個信息發(fā)送失敗，可以選擇重新發(fā)送。

2.3.3 單向發(fā)送

單向發(fā)送是指只負責發(fā)送消息而不等待服務器回應且沒有回調(diào)函數(shù)觸發(fā)，適用于某些耗時非常短但對可靠性要求并不高的場景，例如日志收集。

2.3.4 生產(chǎn)者組

生產(chǎn)者組（Producer Group）是一類 Producer 的集合，這類 Producer 通常發(fā)送一類消息并且發(fā)送邏輯一致，所以將這些 Producer 分組在一起。從部署結(jié)構(gòu)上看生產(chǎn)者通過 Producer Group 的名字來標記自己是一個集群。

2.3.5 高可用保障

Producer與Name Server集群中的其中一個節(jié)點(隨機選擇)建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master建立長連接，且定時向Master發(fā)送心跳。Producer完全無狀態(tài)，可集群部署。

Producer每隔30s（由ClientConfig的pollNameServerInterval）從Name server獲取所有topic隊列的最新情況，這意味著如果Broker不可用，Producer最多30s能夠感知，在此期間內(nèi)發(fā)往Broker的所有消息都會失敗。

Producer每隔30s（由ClientConfig中heartbeatBrokerInterval決定）向所有關(guān)聯(lián)的broker發(fā)送心跳，Broker每隔10s中掃描所有存活的連接，如果Broker在2分鐘內(nèi)沒有收到心跳數(shù)據(jù)，則關(guān)閉與Producer的連接。

2.4 消費者（Consumer）

也稱為消息訂閱者，負責從 Topic 接收并消費消息。 消費者從brokers那里拉取信息并將其輸入應用程序。

2.4.1 消費者組

消費者組（Consumer Group）一類 Consumer 的集合名稱，這類 Consumer 通常消費同一類消息并且消費邏輯一致，所以將這些 Consumer 分組在一起。消費者組與生產(chǎn)者組類似，都是將相同角色的分組在一起并命名。

RocketMQ中的消息有個特點，同一條消息，只能被某一消費組其中的一臺機器消費，但是可以同時被不同的消費組消費。

例如圖中的消息就只能被A中的某一臺機器消費，但是同時也可以被B中的某一臺機器消費

2.4.2 高可用保障

Consumer與Name Server集群中的其中一個節(jié)點(隨機選擇)建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務的Master、Slave建立長連接，且定時向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定。

Consumer每隔30s從Name server獲取topic的最新隊列情況，這意味著Broker不可用時，Consumer最多最需要30s才能感知。

Consumer每隔30s（由ClientConfig中heartbeatBrokerInterval決定）向所有關(guān)聯(lián)的broker發(fā)送心跳，Broker每隔10s掃描所有存活的連接，若某個連接2分鐘內(nèi)沒有發(fā)送心跳數(shù)據(jù)，則關(guān)閉連接；并向該Consumer Group的所有Consumer發(fā)出通知，Group內(nèi)的Consumer重新分配隊列，然后繼續(xù)消費。

當Consumer得到master宕機通知后，轉(zhuǎn)向slave消費，slave不能保證master的消息100%都同步過來了，因此會有少量的消息丟失。但是一旦master恢復，未同步過去的消息會被最終消費掉。

2.5 運轉(zhuǎn)流程

上面介紹了RocketMQ的各個角色及其作用, 下面我們看一下各角色之間完整的交互過程。

1. NameServer 先啟動
2. Broker 啟動時向 NameServer 注冊
3. 生產(chǎn)者在發(fā)送某個主題的消息之前先從 NamerServer 獲取 Broker 服務器地址列表（有可能是集群），然后根據(jù)負載均衡算法從列表中選擇一臺Broker 進行消息發(fā)送。
4. NameServer 與每臺 Broker 服務器保持長連接，并間隔 30S 檢測 Broker 是否存活，如果檢測到Broker 宕機（使用心跳機制， 如果檢測超120S），則從路由注冊表中將其移除。
5. 消費者在訂閱某個主題的消息之前從 NamerServer 獲取 Broker 服務器地址列表（有可能是集群），但是消費者選擇從 Broker 中 訂閱消息，訂閱規(guī)則由 Broker 配置決定

2.6 名詞解釋

消息

消息（Message）就是要傳輸?shù)男畔?。一條消息必須有一個主題（Topic），主題可以看做是你的信件要郵寄的地址。一條消息也可以擁有一個可選的標簽（Tag）和額處的鍵值對，它們可以用于設置一個業(yè)務 key 并在 Broker 上查找此消息以便在開發(fā)期間查找問題。

主題

主題（Topic）可以看做消息的規(guī)類，它是消息的第一級類型。比如一個電商系統(tǒng)可以分為：交易消息、物流消息等，一條消息必須有一個 Topic 。

Topic 與生產(chǎn)者和消費者的關(guān)系非常松散，一個 Topic可以有0個、1個、多個生產(chǎn)者向其發(fā)送消息，一個生產(chǎn)者也可以同時向不同的 Topic 發(fā)送消息。一個Topic 也可以被 0個、1個、多個消費者訂閱。

標簽

標簽（Tag）可以看作子主題，它是消息的第二級類型，用于為用戶提供額外的靈活性。使用標簽，同一業(yè)務模塊不同目的的消息就可以用相同 Topic 而不同的 Tag 來標識。 比如交易消息又可以分為：交易創(chuàng)建消息、交易完成消息等，一條消息可以沒有 Tag 。標簽有助于保持您的代碼干凈和連貫，并且還可以為 RocketMQ 提供的查詢系統(tǒng)提供幫助。

簡單來說TOPIC可以看作衣服，而TAG可以看作衣服下的【短袖】、【外套】、【衛(wèi)衣】等

消息隊列

消息隊列（Message Queue），主題被劃分為一個或多個子主題，即消息隊列。一個 Topic 下可以設置多個消息隊列，發(fā)送消息時執(zhí)行該消息的 Topic ，RocketMQ 會輪詢該 Topic 下的所有隊列將消息發(fā)出去。下圖 Broker 內(nèi)部消息情況：

其實Topic只是一個邏輯上的概念，下面的消息隊列才是真正的實體。

消息消費模式

消息消費模式有兩種：集群消費（Clustering）和廣播消費（Broadcasting） 默認情況下就是集群消費，該模式一條消息只能被某一消費者組中的某一臺機器消費，如果某個消費者掛掉，分組內(nèi)其它消費者會接替掛掉的消費者繼續(xù)消費。 而廣播消費消息會發(fā)給消費者組中的每一個消費者進行消費。

消息順序

消息順序（Message Order）有兩種：順序消費（Orderly）和并行消費（Concurrently）。

順序消費表示消息消費的順序和生產(chǎn)者為每個消息隊列發(fā)送信息時候的順序一致，所以如果正在處理全局順序是強制性的場景，需要確保使用的主題只有一個消息隊列。

并行消費不再保證消息順序，消費的最大并行數(shù)量受每個消費者客戶端指定的線程池限制。

3 設計理念

RocketMQ 的設計基于主題的發(fā)布與訂閱模式，其核心功能包括消息發(fā)送、消息存儲(Broker)、消息消費，整體設計追求簡單與性能第一，主要體現(xiàn)在以下三個方面：

3.1 NameServer設計及其簡單

RocketMQ摒棄了業(yè)界常用的zookeeper作為注冊中心，而是使用自研的NameServer來實現(xiàn)元數(shù)據(jù)的管理，因為Topic路由信息無須在集群間保持強一致性，追求最終一致性，并且能容忍分鐘級的不一致，所以RocketMQ的NameServer集群間互不通信，極大降低了設計的復雜度，降低了對網(wǎng)絡的要求，提升性能。

3.2 高效的IO存儲機制

RocketMQ追求消息發(fā)送的高吞吐量，RocketMQ消息存儲文件設計成文件組的概念，組內(nèi)單個文件大小固定，方便引入內(nèi)存映射機制。 所有主題的消息存儲基于順序?qū)?，提升寫性能，同時為了兼顧消息消費與消息查找，引入了消息消費隊列文件與索引文件。

3.3 容忍存在的設計缺陷

適當將某些工作下放給RocketMQ使用者。消息中間件的實現(xiàn)者經(jīng)常會遇到一個難題： 如何保證消息一定能被消息消費者消費，并且保證只消費一次。 RocketMQ的設計者給出的解決辦法是不解決這個難題，而是退而求其次，只保證消息被消費者消費，但設計上允許消息被重復消費，如果你們要用RocketMQ那么你們自己在消費端用邏輯實現(xiàn)只消費一次的功能。

4 RocketMQ 架構(gòu)

RocketMQ 架構(gòu)圖中展示了四個集群：

4.1 NameServer 集群

提供輕量級的服務發(fā)現(xiàn)及路由，每個 NameServer 記錄完整的路由信息，提供相應的讀寫服務，支持快速存儲擴展。

NameServer是一個功能齊全的服務器，主要包含兩個功能：

• Broker 管理，接收來自 Broker 集群的注冊請求，提供心跳機制檢測 Broker 是否存活
• 路由管理，每個 NameServer 持有全部有關(guān) Broker 集群和客戶端請求隊列的路由信息

4.2 Broker 集群

通過提供輕量級的 Topic 和Queue 機制處理消息存儲。同時支持推（Push）和拉（Pull）兩種模型，包含容錯機制。提供強大的峰值填充和以原始時間順序累積數(shù)千億條消息的能力。此外還提供災難恢復，豐富的指標統(tǒng)計數(shù)據(jù)和警報機制，這些都是傳統(tǒng)的消息系統(tǒng)缺乏的。

Broker 有幾個重要的子模塊：

• 遠程處理模塊，Broker 入口，處理來自客戶端的請求
• 客戶端管理，管理客戶端（包括消息生產(chǎn)者和消費者），維護消費者的主題訂閱
• 存儲服務，提供在物理硬盤上存儲和查詢消息的簡單 API
• HA 服務，提供主從 Broker 間數(shù)據(jù)同步
• 索引服務，通過指定鍵為消息建立索引并提供快速消息查詢

4.3 Producer 集群

消息生產(chǎn)者支持分布式部署，分布式生產(chǎn)者通過多種負載均衡模式向 Broker 集群發(fā)送消息。

4.4 Consumer 集群

消息消費者也支持 Push 和 Pull 模型的分布式部署，還支持集群消費和消息廣播。提供了實時的消息訂閱機制，可以滿足大多數(shù)消費者的需求。

架構(gòu)圖中集群間交互方式的說明

1. Broker Master 和 Broker Slave 是主從結(jié)構(gòu)，會執(zhí)行數(shù)據(jù)同步 Data Sync
2. 每個 Broker 與 NameServer 集群中所有節(jié)點建立長連接，定時注冊 Topic 信息到所有NameServer
3. Producer 與 NameServer 集群中的其中一個節(jié)點（隨機）建立長連接，定期從 NameServer 獲取Topic 路由信息，并與提供 Topic 服務的 Broker Master 建立長連接，定時向 Broker 發(fā)送心跳
4. Producer 只能將消息發(fā)送到 Broker Master，但是 Consumer 同時和Broker Master和 Broker Slave 建立長連接，既可以從 Master 訂閱消息，也可以從 Slave 訂閱消息。

5 設計目標

5.1 架構(gòu)模式

RocketMQ與大部分消息中間件一樣，采用發(fā)布訂閱模式，基本的參與組件主要包括：消息發(fā)送者、消息服務器（消息存儲）、消息消費、路由發(fā)現(xiàn)。

5.1.1 順序消息

順序消息（FIFO：First Input First Output）是一種嚴格按照順序進行發(fā)布和消費的消息類型。要求消息的發(fā)布和消息消費都按照順序進行，RocketMQ可以嚴格保證消息有序

RocketMQ可以嚴格的保證消息有序。但這個順序，不是全局順序，只是分區(qū)（queue）順序。要全局順序只能一個分區(qū)，但是同一條queue里面，RocketMQ的確是能保證FIFO的。

5.1.2 消息過濾

消息過濾是指在消息消費時，消息消費者可以對同一主題下的消息按照規(guī)則只消費自己感興趣的消息。RocketMQ消息過濾支持在服務端與消費端的消息過濾機制。

1. 消息在Broker端過濾，Broker只將消息消費者感興趣的消息發(fā)送給消息消費者。
2. 消息在消息消費端過濾，消息過濾方式完全由消息消費者自定義，但缺點是有很多無用的消息會從Broker傳輸?shù)较M端。

5.1.3 消息存儲

消息中間件的一個核心實現(xiàn)是消息的存儲，對消息存儲一般有如下兩個維度的考量：消息堆積能力和消息存儲性能。

RocketMQ追求消息存儲的高性能，引入內(nèi)存映射機制，所有主題的消息順序存儲在同一個文件中。同時為了避免消息無限在消息存儲服務器中累積，引入了消息文件過期機制與文件存儲空間報警機制。

5.2 消息高可用性

通常影響消息可靠性的有以下幾種情況

1. Broker正常關(guān)機。
2. Broker異常宕機。
3. 操作系統(tǒng)宕機。
4. 機器斷電，但是能立即恢復供電情況。
5. 機器無法開機（可能是CPU、主板、內(nèi)存等關(guān)鍵設備損壞）。
6. 磁盤設備損壞。

針對上述情況，情況1,4的RocketMQ在同步刷盤機制下可以確保不丟失消息，在異步刷盤模式下，會丟失少量消息。情況5,6屬于單點故障，一旦發(fā)生，該節(jié)點上的消息全部丟失，如果開啟了異步復制機制，RoketMQ能保證只丟失少量消息，RocketMQ在后續(xù)版本中將引入雙寫機制，以滿足消息可靠性要求極高的場合。

5.2.1 消息到消費低延遲

RocketMQ在消息不發(fā)生消息堆積時，以長輪詢模式實現(xiàn)準實時的消息推送模式。

5.2.2 確保消息必須被消費一次（不是只消費一次?。?/h4>

RocketMQ通過消息消費確認機制（ACK）來確保消息至少被消費一次，但由于ACK消息有可能丟失等其他原因，RocketMQ無法做到消息只被消費一次，有重復消費的可能。

5.2.3 回溯消息

回溯消息是指消息消費端已經(jīng)消費成功的消息，由于業(yè)務要求需要重新消費消息。RocketMQ支持按時間回溯消息，時間維度可精確到毫秒，可以向前或向后回溯。

5.2.4 消息堆積

消息中間件的主要功能是異步解耦，必須具備應對前端的數(shù)據(jù)洪峰，提高后端系統(tǒng)的可用性，必然要求消息中間件具備一定的消息堆積能力。RocketMQ消息存儲使用磁盤文件（內(nèi)存映射機制），并且在物理布局上為多個大小相等的文件組成邏輯文件組，可以無限循環(huán)使用。RocketMQ消息存儲文件并不是永久存儲在消息服務器端，而是提供了過期機制，默認保留3天。

5.2.5 定時消息

定時消息是指消息發(fā)送到Broker后，不能被消息消費端立即消費，要到特定的時間點或者等待特定的時間后才能被消費。如果要支持任意精度的定時消息消費，必須在消息服務端對消息進行排序，勢必帶來很大的性能損耗，故RocketMQ不支持任意進度的定時消息，而只支持特定延遲級別。

5.2.6 消息重試機制

消息重試是指消息在消費時，如果發(fā)送異常，消息中間件需要支持消息重新投遞，RocketMQ支持消息重試機制。

到此這篇關(guān)于RocketMQ消息中間件超詳細解讀的文章就介紹到這了,更多相關(guān)RocketMQ消息中間件內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論