認識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