1 介紹

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

1.1 RocketMQ 特點(diǎn)

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

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

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

1.2 RocketMQ 優(yōu)勢

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

2 RocketMQ 基本概念

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

2.1 NameServer

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

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

2.1.1 NameServer作用

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

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

2.1.2 和zk的區(qū)別

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

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

2.1.3 高可用保障

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

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

2.2 Broker

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

2.2.1 部署方式

Broker部署相對復(fù)雜，Broker分為Master與Slave，一個Master可以對應(yīng)多個Slave，但是一個Slave只能對應(yīng)一個Master，Master與Slave的對應(yīng)關(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 重啟或宕機(jī)會導(dǎo)致整個服務(wù)不可用，這種方式風(fēng)險(xiǎn)較大，所以顯然不建議線上環(huán)境使用。

2.2.1.2 多 Master

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

2.2.1.3 多 Master 多 Slave（異步復(fù)制）

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

2.2.1.4 多 Master 多 Slave（同步雙寫）

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

2.2.2 高可用保障

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

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

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

2.3.1 同步發(fā)送

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

2.3.2 異步發(fā)送

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

2.3.3 單向發(fā)送

單向發(fā)送是指只負(fù)責(zé)發(fā)送消息而不等待服務(wù)器回應(yīng)且沒有回調(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 的名字來標(biāo)記自己是一個集群。

2.3.5 高可用保障

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

Producer每隔30s（由ClientConfig的pollNameServerInterval）從Name server獲取所有topic隊(duì)列的最新情況，這意味著如果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 消費(fèi)者（Consumer）

也稱為消息訂閱者，負(fù)責(zé)從 Topic 接收并消費(fèi)消息。 消費(fèi)者從brokers那里拉取信息并將其輸入應(yīng)用程序。

2.4.1 消費(fèi)者組

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

RocketMQ中的消息有個特點(diǎn)，同一條消息，只能被某一消費(fèi)組其中的一臺機(jī)器消費(fèi)，但是可以同時被不同的消費(fèi)組消費(fèi)。

例如圖中的消息就只能被A中的某一臺機(jī)器消費(fèi)，但是同時也可以被B中的某一臺機(jī)器消費(fèi)

2.4.2 高可用保障

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

Consumer每隔30s從Name server獲取topic的最新隊(duì)列情況，這意味著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重新分配隊(duì)列，然后繼續(xù)消費(fèi)。

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

2.5 運(yùn)轉(zhuǎn)流程

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

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

2.6 名詞解釋

消息

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

主題

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

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

標(biāo)簽

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

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

消息隊(duì)列

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

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

消息消費(fèi)模式

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

消息順序

消息順序（Message Order）有兩種：順序消費(fèi)（Orderly）和并行消費(fèi)（Concurrently）。

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

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

3 設(shè)計(jì)理念

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

3.1 NameServer設(shè)計(jì)及其簡單

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

3.2 高效的IO存儲機(jī)制

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

3.3 容忍存在的設(shè)計(jì)缺陷

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

4 RocketMQ 架構(gòu)

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

4.1 NameServer 集群

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

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

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

4.2 Broker 集群

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

Broker 有幾個重要的子模塊：

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

4.3 Producer 集群

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

4.4 Consumer 集群

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

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

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

5 設(shè)計(jì)目標(biāo)

5.1 架構(gòu)模式

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

5.1.1 順序消息

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

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

5.1.2 消息過濾

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

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

5.1.3 消息存儲

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

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

5.2 消息高可用性

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

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

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

5.2.1 消息到消費(fèi)低延遲

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

5.2.2 確保消息必須被消費(fèi)一次（不是只消費(fèi)一次！）

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

5.2.3 回溯消息

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

5.2.4 消息堆積

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

5.2.5 定時消息

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

5.2.6 消息重試機(jī)制

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

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

最新評論