九個問答牢記RocketMQ架構

作者：不焦躁的程序員 2023-12-27 13:54:00

RocketMQ是Java兄弟們常用的消息中間件，雖說常用，但對于RocketMQ架構經常忘記。本文用大白話描述架構設計過程，牢記RocketMQ架構。

RocketMQ是Java兄弟們常用的消息中間件，雖說常用，但對于RocketMQ架構經常忘記。究其原因就2點：忙于業務開發然后長時間不看則忘了、不理解架構設計的根本原因記不牢。本文用大白話描述架構設計過程，牢記RocketMQ架構。

一、架構的思考過程

首先，在記框架的原理和架構時，要先把握全局的脈絡，在思考為什么這么設計，最后才是思考細節，這樣才能記得牢。本文通過層層追問的方式，一步步解說RocketMQ架構設計的原因。

答：起碼要設計3個角色：

答：這里借鑒實際生活中的案例，比如物流公司在發快遞時，發往同一個城市的快遞，肯定安排在一起，然后用同一批貨車運往那個城市，這樣整個物流體系運轉是最高效的。這里就用到了聚類的方式，讓相似的事物聚到一起。

同樣的，在設計怎么存儲消息時，也用到聚類的概念，我們把相同類型的消息，放到一個邏輯空間里，這個邏輯空間就是主題Topic。

答：Topic的內部肯定是一個個的消息對象，那這些消息對象是以什么數據結構存在一起的呢？先發的消息，盡量要保證先被消費到，這里就用到了先進先出的數據結構-隊列，這就是消息隊列MessageQueue。所以，Topic內部是由MessageQueue組成，消息隊列內部存放著一個個的消息對象。

答：既然是RocketMQ的核心，肯定要保證高可用不能掛，所以RocketMQ 會部署多臺 Broker 組成一個集群對外提供服務。

答：我們要學習“雞蛋不能放在一個籃子里”的思想。既然是要存大量的消息，又有多臺Broker，為了分擔單臺機器性能壓力、分擔存儲容量壓力、保證數據容災，所以將不同的Topic存儲到不同的Broker里。

還是按照上面物流的例子說明，比如從北京發往南京的快遞，肯定用同一批貨車運送，快遞少則用一輛貨車，快遞多則用多輛貨車，快遞被劃分到了多個貨車上。同樣的，RocketMQ里的Topic也是分散存儲在多臺 Broker 上的，每臺Broker上存儲的消息內容是不同的。

答：上面我們提到，Topic實際上是一個個隊列的集合，那只需要將隊列分散存儲到不同的Broker上就行了。

答：這時候就會用到Broker的主-從架構，Broker按角色分為Master和Slave，主從之間會定期地進行數據同步。Master 負責響應客戶端的讀寫請求、存儲消息、處理消費者請求等，而 Slave 只負責同步 Master 的數據。

答：RocketMQ引入了NameServer的概念，NameServer相當于大管家，RocketMQ里的所有基礎信息它都知道。NameServer 存儲了RocketMQ 集群的元數據。NameServer 中存放的元數據主要有：

答：類似古時候某個人去府里當差，當差之前要把自己的所有信息登記在冊。同樣的，Broker、Producer、Consumer在啟動時也會將數據注冊到 NameServer。

Broker 在啟動時會將自己注冊到 NameServer 上，通過心跳持續更新元數據。同樣的，Producer、Consumer也會和NameServer建立連接、動態交互集群中的數據，這樣即方便上報自己的信息和也方便獲取集群里的其他信息。

至此，RocketMQ的架構圖已經成型，每一個部件這么設計的原因也很清晰。

RocketMQ里的核心角色有4個：Broker、Producer、Consumer、NameServer，消息存儲的核心對象有2個：Topic、MessageQueue。

為了保證數據不丟失和數據不傾斜，同一個Topic里的MessageQueue會分散存儲在不同的Broker里。

責任編輯：趙寧寧來源：不焦躁的程序員