認識RocketMQ4.x架構設計

RocketMQ訊息模型跟其他的訊息佇列一樣 都是 producer - > topic->consumer

producer 生產訊息 也就是傳送者

topic 訊息主題 按topic傳送訊息 以後訊息的儲存 分片等都是基於topic做業務處理的

consumer 訊息消費者 也是基於topic來進行訊息的消費 支援推和拉模式(其實內部都是pull模式的變種)。

擴充套件叢集訊息模型

為了支援高併發、提高可擴充套件性、提高訊息堆積能力。

一個topic可以有多個佇列 而且還可以在不同的物理機器，這就為高吞吐、水平擴充套件支援打了基礎。

在消費端consumer支援組(group)概念。一組consumer裡面有多個消費者例項，一組consumer來消費某個topic 這樣消費能力就得到了水平擴充套件

consumer組支援 叢集消費模式 、 廣播消費模式

• 叢集消費下同組consumer例項會去拉取對應topic的不同佇列上資料進行消費。‘

• 廣播模式是每個消費者都會拉取對應topic中所有佇列的訊息來消費。

架構設計

RocketMQ 總體最元件分為 NameServer Broker Porducer Consumer

NameServer 名稱服務

NameServer類似於Zookeeper這種角色 負責管理叢集元件，簡單來說NameServer可以查詢到Broker有哪些、Topic在哪些Broker機器上 佇列是如何分佈的，它就像一顆大腦 管理者 收集者。相當於是一個topic路由管理中心，NameServer可以多例項分別獨立部署、相互之間不產出資料交換，每個Broker在啟動的時候會向所有的NameServer上報資訊，所以他們之間可以相互獨立，完全無狀態。就算掛掉1個也不影響叢集。

Broker 訊息儲存代理服務

Broker 才是真正託管消費儲存、投遞查詢的服務，這個是非常核心的服務，大部分的效能優化都是針對這個服務進行。Broker分為 master slave 角色 在配置檔案中brokerId=0表示Master 不為0表示slave。

broker啟動後和NameServer建立了長連線 定期向NameServer上報Topic資訊自身資訊。

producer 生產者

生產/傳送訊息服務，一般是程式自己編寫的業務傳送訊息端，啟動後首先會和NameServer建立連線，定時從NameServer獲取Topic路由資訊，定時查詢Broker服務資訊 同時會和Broker master 角色建立長連線。producer 也是無狀態的。

consumer 消費者

消費者服務 一般是由自己業務程式編寫實現。啟動後和NameServer建立連線 定時從NameServer獲取topic資訊和Broker資訊，獲取到Broker的資訊後會和broker中的master salve角色也建立長連線 所有consumer中可以訂閱master和slave。

只有非常懂IO的人 才能寫得出來這麼優秀的框架 裡面有太多值的學習和借鑑的設計和思想 後面再慢慢精研。

參考 https://rocketmq.apache.org/docs/%E4%BB%8B%E7%BB%8D/03whatis