RocketMQ 是什么

Github 上關(guān)于 RocketMQ 的介紹：
RcoketMQ 是一款低延遲、高可靠、可伸縮、易于使用的消息中間件。具有以下特性：

• 支持發(fā)布/訂閱（Pub/Sub）和點對點（P2P）消息模型
• 在一個隊列中可靠的先進先出（FIFO）和嚴格的順序傳遞
• 支持拉（pull）和推（push）兩種消息模式
• 單一隊列百萬消息的堆積能力
• 支持多種消息協(xié)議，如 JMS、MQTT 等
• 分布式高可用的部署架構(gòu),滿足至少一次消息傳遞語義
• 提供 docker 鏡像用于隔離測試和云集群部署
• 提供配置、指標和監(jiān)控等功能豐富的 Dashboard

對于這些特性描述，大家簡單過一眼就即可，深入學習之后自然就明白了。

專業(yè)術(shù)語

 Producer

消息生產(chǎn)者，生產(chǎn)者的作用就是將消息發(fā)送到 MQ，生產(chǎn)者本身既可以產(chǎn)生消息，如讀取文本信息等。也可以對外提供接口，由外部應用來調(diào)用接口，再由生產(chǎn)者將收到的消息發(fā)送到 MQ。

Producer Group

生產(chǎn)者組，簡單來說就是多個發(fā)送同一類消息的生產(chǎn)者稱之為一個生產(chǎn)者組。在這里可以不用關(guān)心，只要知道有這么一個概念即可。

Consumer

消息消費者，簡單來說，消費 MQ 上的消息的應用程序就是消費者，至于消息是否進行邏輯處理，還是直接存儲到數(shù)據(jù)庫等取決于業(yè)務需要。

Consumer Group

消費者組，和生產(chǎn)者類似，消費同一類消息的多個 consumer 實例組成一個消費者組。

Topic

Topic 是一種消息的邏輯分類，比如說你有訂單類的消息，也有庫存類的消息，那么就需要進行分類，一個是訂單 Topic 存放訂單相關(guān)的消息，一個是庫存 Topic 存儲庫存相關(guān)的消息。

Message

Message 是消息的載體。一個 Message 必須指定 topic，相當于寄信的地址。Message 還有一個可選的 tag 設(shè)置，以便消費端可以基于 tag 進行過濾消息。也可以添加額外的鍵值對，例如你需要一個業(yè)務 key 來查找 broker 上的消息，方便在開發(fā)過程中診斷問題。

Tag

標簽可以被認為是對 Topic 進一步細化。一般在相同業(yè)務模塊中通過引入標簽來標記不同用途的消息。

Broker

Broker 是 RocketMQ 系統(tǒng)的主要角色，其實就是前面一直說的 MQ。Broker 接收來自生產(chǎn)者的消息，儲存以及為消費者拉取消息的請求做好準備。

Name Server

Name Server 為 producer 和 consumer 提供路由信息。

RocketMQ 架構(gòu)

有四個集群，分別是 NameServer 集群、Broker 集群、Producer 集群和 Consumer 集群：

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

Broker: 通過提供輕量級的 Topic 和 Queue 機制來處理消息存儲,同時支持推（push）和拉（pull）模式以及主從結(jié)構(gòu)的容錯機制。

Producer：生產(chǎn)者，產(chǎn)生消息的實例，擁有相同 Producer Group 的 Producer 組成一個集群。

Consumer：消費者，接收消息進行消費的實例，擁有相同 Consumer Group 的

Consumer 組成一個集群。

簡單說明一下圖中箭頭含義，從 Broker 開始，Broker Master1 和 Broker Slave1 是主從結(jié)構(gòu)，它們之間會進行數(shù)據(jù)同步，即 Date Sync。同時每個 Broker 與
NameServer 集群中的所有節(jié)
點建立長連接，定時注冊 Topic 信息到所有 NameServer 中。

Producer 與 NameServer 集群中的其中一個節(jié)點（隨機選擇）建立長連接，定期從 NameServer 獲取 Topic 路由信息，并向提供 Topic 服務的 Broker Master 建立長連接，且定時向 Broker 發(fā)送心跳。Producer 只能將消息發(fā)送到 Broker master，但是 Consumer 則不一樣，它同時和提供 Topic 服務的 Master 和 Slave
建立長連接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。

RocketMQ 集群部署模式

單 master 模式

也就是只有一個 master 節(jié)點，稱不上是集群，一旦這個 master 節(jié)點宕機，那么整個服務就不可用，適合個人學習使用。

多master 模式

多個 master 節(jié)點組成集群，單個 master 節(jié)點宕機或者重啟對應用沒有影響。

優(yōu)點：所有模式中性能最高
缺點：單個 master 節(jié)點宕機期間，未被消費的消息在節(jié)點恢復之前不可用，消息的實時性就受到影響。

注意：使用同步刷盤可以保證消息不丟失，同時 Topic 相對應的 queue 應該分布在集群中各個節(jié)點，而不是只在某各節(jié)點上，否則，該節(jié)點宕機會對訂閱該 topic 的應用造成影響。

多 master 多 slave 異步復制模式

在多 master 模式的基礎(chǔ)上，每個 master 節(jié)點都有至少一個對應的 slave。master
節(jié)點可讀可寫，但是 slave 只能讀不能寫，類似于 mysql 的主備模式。

優(yōu)點： 在 master 宕機時，消費者可以從 slave 讀取消息，消息的實時性不會受影響，性能幾乎和多 master 一樣。
缺點：使用異步復制的同步方式有可能會有消息丟失的問題。

多 master 多 slave 同步雙寫模式

同多 master 多 slave 異步復制模式類似，區(qū)別在于 master 和 slave 之間的數(shù)據(jù)同步方式。

優(yōu)點：同步雙寫的同步模式能保證數(shù)據(jù)不丟失。
缺點：發(fā)送單個消息 RT 會略長，性能相比異步復制低10%左右。

刷盤策略：同步刷盤和異步刷盤（指的是節(jié)點自身數(shù)據(jù)是同步還是異步存儲）

同步方式：同步雙寫和異步復制（指的一組 master 和 slave 之間數(shù)據(jù)的同步）

注意：要保證數(shù)據(jù)可靠，需采用同步刷盤和同步雙寫的方式，但性能會較其他方式低。

以上就是java開發(fā)RocketMQ消息中間件基礎(chǔ)詳解的詳細內(nèi)容，更多關(guān)于RocketMQ消息中間件的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論