認識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的人 才能寫得出來這麼優秀的框架 裏面有太多值的學習和借鑒的設計和思想 後面再慢慢精研。
相關鏈接 //www.cnblogs.com/peachyy/p/9406526.html
