RocketMQ架構上主要分為四部分構成：
消息生產者，負責生產消息。Producer通過MQ的負載均衡模塊選擇相應的Broker集群隊列進行消息投遞，投遞的過程支持快速失敗並且低延遲
RocketMQ中的消息生產者都是以生產者組(Producer Group)的形式出現的。生產者組是同壹類生產者的集合，這類Producer發送相同Topic類型的消息。壹個生產者組可以同時發送多個主題的消息。
消息消費者，負責消費消息。壹個消息消費者會從Broker服務器中獲取到消息，並對消息進行相關業務處理
RocketMQ中的消息消費者都是以消費者組(Consumer Group)的形式出現的。消費者組是統壹類消費者的集合，這類Consumer消費的是同壹個Topic類型的消息。消費者組使得在消息消費方法，實現負載均衡（講壹個Topic中不同的Queue平均分配給同壹個Consumer Group的不同Consumer，並不是負載均衡）和容錯(壹個Consumer掛了，該Consumer Group中的其他Consumer可以接著消費元Consumer消費的Queue)的目標變得非常容易
消費者組中Consumer的數量應小於等於Topic的Queue數量。如果超出Queue數量，則多出的Consumer將不能消費消息。
不過壹個Topic類型的消息可以被多個消費者組同時消費。
NameServer是壹個Broker與Topic路由的註冊中心，支持Broker的動態註冊與發現。
RocketMQ的思想來自於Kafuka，而Kafka是以來了Zookeeper的。所以，在RocketMQ的早期版本也依賴Zookeeper。從3.0開始去掉了Zookeeper的依賴，使用了自己的NameServer。
NameServer通常也是以集群的方式部署，不過，NameServer是無狀態的，即NameServer集群中的各個節點之間是無差異的，各個節點相互不進行信息通訊。那各個節點中的數據是如何進行數據同步的呢？在Broker節點啟動時，輪詢NameServer列表，與每個NameServer節點建立長連接，發起註冊請求。在NameServer內部維護者壹個Broker列表，用來動態存儲Broker信息
Broker節點為了證明自己是活著的，為了維護與NameServer間的長連接，會將最新的信息以心跳包的方式上報給NameServer，每30秒發送壹次心跳。心跳包中包含BrokerId、Broker地址(IP+Port)、Broker名稱、Broker所屬集群名稱等等。NameServer在接收到心跳包後，會更新心跳時間戳，記錄這個Broker的最新存活時間。
由於Broker關機、宕機或網絡抖動等原因，NameServer沒有收到Broker的心跳，NameServer可能會將其從Broker列表中剔除
NameServer中有壹個定時任務，每隔10秒就會掃描壹次Broker表，查看每壹個Broker的最新心跳時間戳距離當前時間是否超過120秒，如果超過，則會判定Broekr失效，然後將其從Broker列表中剔除。
RocketMQ的路由發現采用的是Pull模型。當Topic路由信息出現變化時，NameServer不會主動推送給客戶端，而是客戶端定時拉取最新的路由。默認每30秒拉取壹次最新的路由
客戶端再配置時必須要寫上NameServer集群的地址，那麽客戶端道理連接在哪個NameServer節點呢?客戶端首先會生產壹個隨機數，然後再與NameServer節點數取模，此時得到的就是要連接的節點索引，然後就會進行連接。如果連接失敗，則會采用round-robin策略，逐個嘗試去連接其他節點。
首先采用的是 隨機策略 進行選擇，失敗後采用的是輪詢策略。
Broker充當著消息中轉角色，負責存儲消息、轉發消息。Broker在RocketMQ系統中負責接收並存儲從生產者發送來的消息，同時為消費者的拉取請求作準備。Broker同時也存儲著消息相關的元數據，包括消費者組、消費進度偏移offset、主題、隊列等
Remoting Module ：整個Broker的實體，負責處理來自clients端的請求。而這個Broker實體則由以下模塊構成。
Client Manager ：客戶端管理器。負責接收、解析客戶端(Producer/Consumer)請求，管理客戶端。
Store Service ：存儲服務。提供方便簡單的API接口，處理消息存儲到物理硬盤和消息查詢功能。
HA Service ：高可用服務，提供Master Broker和Slave Broker之間的數據同步功能。
Index Service ：索引服務。根據特定的Message Key，對投遞到Broker的消息進行索引服務，同時也提供根據Message Key對消息進行快速查詢的功能
為了增強Broker性能與吞吐量，Broker壹般都是以集群形式出現的。各集群節點中可能存放著相同Topic的不同Queue。
如果某Broker節點宕機，如何保證數據不丟失呢？
其解決方案是，將每個Broekr集群節點進行橫向擴展，即將Broker節點再建為壹個HA集群，解決單點問題。
Broker節點集群是壹個主從集群，即有Master和Slave兩種角色。Master負責處理讀寫操作請求，Slave負責對Master中的數據進行備份。當Master掛掉了，Slaver會自動切換為Master去工作。所以這個Broker集群式主備集群。Master與Slave的對應關系是通過指定相同的BrokerName、不同的BrokerId來確定的。BrokerId為0表示Master，非0表示Slave。每個Broker與NameServer集群中的所有節點建立長連接，定時註冊Topic信息到所有NameServer。
①啟動NameServer，NameServer啟動後開始監聽端口，等待Broker、Producer、Consumer連接
②啟動Broker時，Broker會與所有的NameServer保持長連接，每30秒向NameServer定時發送心跳包
③發送消息前，可以先創建Topic ,創建Topic時需要指定該Topic要存儲在哪些Broker上，當然，在創建Topic時也會將Topic與Broker的關系寫入到NameServer中。也可以在發送消息時自動創建Topic。
④Producer發送消息，啟動時先跟NameServer集群中的其中壹臺建立長連接，並從NameServer中獲取路由信息，即當前發送Topic的Queue與Broker地址的映射關系。然後根據算法策略從隊選擇壹個Queue，與隊列所在的Broker建立長連接從而向Broker發送消息。
⑤Consumer與Producer類似，跟其中壹臺NameServer建立長連接，獲取其所訂閱Topic的路由信息，然後根據算法策略從路由信息中獲取到其要消費的Queue，然後與Broker建立長連接，消費其中的消息。Consumer會向Broker發送心跳，以確保Broker的存活狀態
手動創建Topic時，有兩種模式：
自動創建Topic時，默認采用的是Broker模式，會為每個Broker默認創建四個Queue
從物理上講，讀/寫隊列是同壹個隊列。所以，不存在讀/寫隊列數據同步問題。讀/寫隊列是邏輯上進行區分的概念 。壹般來說，讀/寫隊列數量是相同的。
讀/寫隊列數量不同是有問題的。
但這樣可以方便縮容
perm用於設置對當前創建Topic的操作權限：2表示只寫，4表示只讀，6表示讀寫