共計 4338 個字符，預(yù)計需要花費 11 分鐘才能閱讀完成。

這篇文章給大家分享的是有關(guān) RocketMQ 有什么特點的內(nèi)容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。

RocketMQ 是一款分布式、隊列模型的消息中間件，具有以下特點：

1. 能夠保證嚴(yán)格的消息順序

2. 提供豐富的消息拉取模式

3. 高效的訂閱者水平擴展能力

4. 實時的消息訂閱機制

5. 億級消息堆積能力

一.RocketMQ 網(wǎng)絡(luò)部署特點

（1）NameServer 是一個幾乎無狀態(tài)的節(jié)點，可集群部署，節(jié)點之間無任何信息同步

（2）Broker 部署相對復(fù)雜，Broker 氛圍 Master 與 Slave，一個 Master 可以對應(yīng)多個 Slaver，但是一個 Slaver 只能對應(yīng)一個 Master，Master 與 Slaver 的對應(yīng)關(guān)系通過指定相同的 BrokerName，不同的 BrokerId 來定義，BrokerId 為 0 表示 Master，非 0 表示 Slaver。Master 可以部署多個。每個 Broker 與 NameServer 集群中的所有節(jié)點建立長連接，定時注冊 Topic 信息到所有的 NameServer

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

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

二.RocketMQ 儲存特點

（1）零拷貝原理：Consumer 消費消息過程，使用了零拷貝，零拷貝包括一下 2 中方式，RocketMQ 使用第一種方式，因小塊數(shù)據(jù)傳輸?shù)囊笮Ч?sendfile 方式好

a ) 使用 mmap+write 方式

優(yōu)點：即使頻繁調(diào)用，使用小文件塊傳輸，效率也很高

缺點：不能很好的利用 DMA 方式，會比 sendfile 多消耗 CPU 資源，內(nèi)存安全性控制復(fù)雜，需要避免 JVM Crash 問題

b）使用 sendfile 方式

優(yōu)點：可以利用 DMA 方式，消耗 CPU 資源少，大塊文件傳輸效率高，無內(nèi)存安全新問題

缺點：小塊文件效率低于 mmap 方式，只能是 BIO 方式傳輸，不能使用 NIO

（2）數(shù)據(jù)存儲結(jié)構(gòu)

三.RocketMQ 關(guān)鍵特性

1. 單機支持 1W 以上的持久化隊列

（1）所有數(shù)據(jù)單獨儲存到 commit Log，完全順序?qū)懀S機讀

（2）對最終用戶展現(xiàn)的隊列實際只儲存消息在 Commit Log 的位置信息，并且串行方式刷盤

這樣做的好處：

（1）隊列輕量化，單個隊列數(shù)據(jù)量非常少

（2）對磁盤的訪問串行話，避免磁盤競爭，不會因為隊列增加導(dǎo)致 IOWait 增高

每個方案都有優(yōu)缺點，他的缺點是：

（1）寫雖然是順序?qū)懀亲x卻變成了隨機讀

（2）讀一條消息，會先讀 Consume Queue，再讀 Commit Log，增加了開銷

（3）要保證 Commit Log 與 Consume Queue 完全的一致，增加了編程的復(fù)雜度

以上缺點如何客服：

（1）隨機讀，盡可能讓讀命中 pagecache，減少 IO 操作，所以內(nèi)存越大越好。如果系統(tǒng)中堆積的消息過多，讀數(shù)據(jù)要訪問硬盤會不會由于隨機讀導(dǎo)致系統(tǒng)性能急劇下降，答案是否定的。

a）訪問 pagecache 時，即使只訪問 1K 的消息，系統(tǒng)也會提前預(yù)讀出更多的數(shù)據(jù)，在下次讀時就可能命中 pagecache

b）隨機訪問 Commit Log 磁盤數(shù)據(jù)，系統(tǒng) IO 調(diào)度算法設(shè)置為 NOOP 方式，會在一定程度上將完全的隨機讀變成順序跳躍方式，而順序跳躍方式讀較完全的隨機讀性能高 5 倍

（2）由于 Consume Queue 存儲數(shù)量極少，而且順序讀，在 pagecache 的與讀取情況下，Consume Queue 的讀性能與內(nèi)存幾乎一直，即使堆積情況下。所以可以認為 Consume Queue 完全不會阻礙讀性能

（3）Commit Log 中存儲了所有的元信息，包含消息體，類似于 MySQl、Oracle 的 redolog，所以只要有 Commit Log 存在，Consume Queue 即使丟失數(shù)據(jù)，仍可以恢復(fù)出來

2. 刷盤策略

rocketmq 中的所有消息都是持久化的，先寫入系統(tǒng) pagecache，然后刷盤，可以保證內(nèi)存與磁盤都有一份數(shù)據(jù)，訪問時，可以直接從內(nèi)存讀取

2.1 異步刷盤

在有 RAID 卡，SAS 15000 轉(zhuǎn)磁盤測試順序?qū)懳募俣瓤梢赃_到 300M 每秒左右，而線上的網(wǎng)卡一般都為千兆網(wǎng)卡，寫磁盤速度明顯快于數(shù)據(jù)網(wǎng)絡(luò)入口速度，那么是否可以做到寫完 內(nèi)存就向用戶返回，由后臺線程刷盤呢？

(1). 由于磁盤速度大于網(wǎng)卡速度，那么刷盤的進度肯定可以跟上消息的寫入速度。

(2). 萬一由于此時系統(tǒng)壓力過大，可能堆積消息，除了寫入 IO，還有讀取 IO，萬一出現(xiàn)磁盤讀取落后情況，會不會導(dǎo)致系統(tǒng)內(nèi)存溢出，答案是否定的，原因如下：

a) 寫入消息到 PAGECACHE 時，如果內(nèi)存不足，則嘗試丟棄干凈的 PAGE，騰出內(nèi)存供新消息使用，策略是 LRU 方式。

b) 如果干凈頁不足，此時寫入 PAGECACHE 會被阻塞，系統(tǒng)嘗試刷盤部分?jǐn)?shù)據(jù)，大約每次嘗試 32 個 PAGE，來找出更多干凈 PAGE。
綜上，內(nèi)存溢出的情況不會出現(xiàn)

2.2 同步刷盤：

同步刷盤與異步刷盤的唯一區(qū)別是異步刷盤寫完 PAGECACHE 直接返回，而同步刷盤需要等待刷盤完成才返回，同步刷盤流程如下：

（1）寫入 PAGECACHE 后，線程等待，通知刷盤線程刷盤。

（2）刷盤線程刷盤后，喚醒前端等待線程，可能是一批線程。

（3）前端等待線程向用戶返回成功。

3. 消息查詢

3.1 按照 MessageId 查詢消息

MsgId 總共 16 個字節(jié)，包含消息儲存主機地址，消息 Commit Log Offset。從 MsgId 中解析出 Broker 的地址和 Commit Log 偏移地址，然后按照存儲格式所在位置消息 buffer 解析成一個完整消息

3.2 按照 Message Key 查詢消息

1. 根據(jù)查詢的 key 的 hashcode%slotNum 得到具體的槽位置（slotNum 是一個索引文件里面包含的最大槽目數(shù)目，例如圖中所示 slotNum=500W）

2. 根據(jù) slotValue（slot 對應(yīng)位置的值）查找到索引項列表的最后一項（倒序排列，slotValue 總是指向最新的一個索引項）

3. 遍歷索引項列表返回查詢時間范圍內(nèi)的結(jié)果集（默認一次最大返回的 32 條記錄）

4.Hash 沖突，尋找 key 的 slot 位置時相當(dāng)于執(zhí)行了兩次散列函數(shù)，一次 key 的 hash，一次 key 的 hash 取值模，因此這里存在兩次沖突的情況；第一種，key 的 hash 值不同但模數(shù)相同，此時查詢的時候會在比較第一次 key 的 hash 值（每個索引項保存了 key 的 hash 值），過濾掉 hash 值不想等的情況。第二種，hash 值相等 key 不想等，出于性能的考慮沖突的檢測放到客戶端處理（key 的原始值是存儲在消息文件中的，避免對數(shù)據(jù)文件的解析），客戶端比較一次消息體的 key 是否相同

5. 存儲，為了節(jié)省空間索引項中存儲的時間是時間差值（存儲時間——開始時間，開始時間存儲在索引文件頭中），整個索引文件是定長的，結(jié)構(gòu)也是固定的

4. 服務(wù)器消息過濾

RocketMQ 的消息過濾方式有別于其他的消息中間件，是在訂閱時，再做過濾，先來看下 Consume Queue 存儲結(jié)構(gòu)

1. 在 Broker 端進行 Message Tag 比較，先遍歷 Consume Queue，如果存儲的 Message Tag 與訂閱的 Message Tag 不符合，則跳過，繼續(xù)比對下一個，符合則傳輸給 Consumer。注意 Message Tag 是字符串形式，Consume Queue 中存儲的是其對應(yīng)的 hashcode，比對時也是比對 hashcode

2.Consumer 收到過濾消息后，同樣也要執(zhí)行在 broker 端的操作，但是比對的是真實的 Message Tag 字符串，而不是 hashcode

為什么過濾要這么做？

1.Message Tag 存儲 hashcode，是為了在 Consume Queue 定長方式存儲，節(jié)約空間

2. 過濾過程中不會訪問 Commit Log 數(shù)據(jù)，可以保證堆積情況下也能高效過濾

3. 即使存在 hash 沖突，也可以在 Consumer 端進行修正，保證萬無一失

5. 單個 JVM 進程也能利用機器超大內(nèi)存

1.Producer 發(fā)送消息，消息從 socket 進入 java 堆

2.Producer 發(fā)送消息，消息從 java 堆進入 pagecache，物理內(nèi)存

3.Producer 發(fā)送消息，由異步線程刷盤，消息從 pagecache 刷入磁盤

4.Consumer 拉消息（正常消費），消息直接從 pagecache（數(shù)據(jù)在物理內(nèi)存）轉(zhuǎn)入 socket，到達 Consumer，不經(jīng)過 java 堆。這種消費場景最多，線上 96G 物理內(nèi)存，按照 1K 消息算，可以物理緩存 1 億條消息

5.Consumer 拉消息（異常消費），消息直接從 pagecache 轉(zhuǎn)入 socket

6.Consumer 拉消息（異常消費），由于 socket 訪問了虛擬內(nèi)存，產(chǎn)生缺頁中斷，此時會產(chǎn)生磁盤 IO，從磁盤 Load 消息到 pagecache，然后直接從 socket 發(fā)出去

7. 同 5

8. 同 6

6. 消息堆積問題解決辦法

1 消息的堆積容量、依賴磁盤大小

2 發(fā)消息的吞吐量大小受影響程度、無 Slave 情況，會受一定影響、有 Slave 情況，不受影響

3 正常消費的 Consumer 是否會受影響、無 Slave 情況，會受一定影響、有 Slave 情況，不受影響

4 訪問堆積在磁盤的消息時，吞吐量有多大、與訪問的并發(fā)有關(guān)，最終會降到 5000 左右

在有 Slave 情況下，Master 一旦發(fā)現(xiàn) Consumer 訪問堆積在磁盤的數(shù)據(jù)時，回想 Consumer 下達一個重定向指令，令 Consumer 從 Slave 拉取數(shù)據(jù)，這樣正常的發(fā)消息與正常的消費不會因為堆積受影響，因為系統(tǒng)將堆積場景與非堆積場景分割在了兩個不同的節(jié)點處理。這里會產(chǎn)生一個問題，Slave 會不會寫性能下降，答案是否定的。因為 Slave 的消息寫入只追求吞吐量，不追求實時性，只要整體的吞吐量高就行了，而 Slave 每次都是從 Master 拉取一批數(shù)據(jù)，如 1M，這種批量順序?qū)懭敕绞绞苟逊e情況，整體吞吐量影響相對較小，只是寫入 RT 會變長。

感謝各位的閱讀！關(guān)于“RocketMQ 有什么特點”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！