RocketMQ是Java兄弟們常用的消息中間件，雖說(shuō)常用，但對(duì)于RocketMQ架構(gòu)經(jīng)常忘記。究其原因就l兩點(diǎn)：忙于業(yè)務(wù)開(kāi)發(fā)然后長(zhǎng)時(shí)間不看則忘了、不理解架構(gòu)設(shè)計(jì)的根本原因記不牢。本文用大白話描述架構(gòu)設(shè)計(jì)過(guò)程，牢記RocketMQ架構(gòu)。

一、架構(gòu)的思考過(guò)程

首先，在記框架的原理和架構(gòu)時(shí)，要先把握全局的脈絡(luò)，在思考為什么這么設(shè)計(jì)，最后才是思考細(xì)節(jié)，這樣才能記得牢。本文通過(guò)層層追問(wèn)的方式，一步步解說(shuō)RocketMQ架構(gòu)設(shè)計(jì)的原因。

1、基本形態(tài)

(1) 如果你是RocketMQ的開(kāi)發(fā)者，讓你來(lái)設(shè)計(jì)一個(gè)消息中間件，你會(huì)設(shè)計(jì)哪些角色？

答：起碼要設(shè)計(jì)3個(gè)角色：

• 消息中轉(zhuǎn)站：Broker，Broker是核心，負(fù)責(zé)：接受消息、存儲(chǔ)消息、處理消費(fèi)者的消費(fèi)請(qǐng)求、備份容災(zāi)等。
• 生產(chǎn)者：Producer，生產(chǎn)消息然后投遞到Broker。
• 消費(fèi)者：Consumer，從Broker中消費(fèi)消息。

2.消息怎么存

(2) 有了基本形態(tài)后，我們知道，具體的消息肯定是存在Broker里，那消息在Broker里應(yīng)該怎么存儲(chǔ)呢？

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

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

(3) 那Topic的內(nèi)部又是什么結(jié)構(gòu)呢？

答：Topic的內(nèi)部肯定是一個(gè)個(gè)的消息對(duì)象，那這些消息對(duì)象是以什么數(shù)據(jù)結(jié)構(gòu)存在一起的呢？先發(fā)的消息，盡量要保證先被消費(fèi)到，這里就用到了先進(jìn)先出的數(shù)據(jù)結(jié)構(gòu)-隊(duì)列，這就是消息隊(duì)列MessageQueue。所以，Topic內(nèi)部是由MessageQueue組成，消息隊(duì)列內(nèi)部存放著一個(gè)個(gè)的消息對(duì)象。

3.引入集群

(4) 我們知道Broker是RocketMQ的核心，這么重要的核心掛了怎么辦？

答：既然是RocketMQ的核心，肯定要保證高可用不能掛，所以RocketMQ 會(huì)部署多臺(tái) Broker 組成一個(gè)集群對(duì)外提供服務(wù)。

4.再說(shuō)消息怎么存

(5) RocketMQ為了保障高可用，會(huì)部署多臺(tái)Broker組成集群，那么集群場(chǎng)景下有多臺(tái)機(jī)器，Topic怎么存呢？

答：我們要學(xué)習(xí)毛主席的思想，“雞蛋不能放在一個(gè)籃子里”。既然是要存大量的消息，又有多臺(tái)Broker，為了分擔(dān)單臺(tái)機(jī)器性能壓力、分擔(dān)存儲(chǔ)容量壓力、保證數(shù)據(jù)容災(zāi)，所以將不同的Topic存儲(chǔ)到不同的Broker里。

還是按照上面物流的例子說(shuō)明，比如從北京發(fā)往南京的快遞，肯定用同一批貨車(chē)運(yùn)送，快遞少則用一輛貨車(chē)，快遞多則用多輛貨車(chē)，快遞被劃分到了多個(gè)貨車(chē)上。同樣的，RocketMQ里的Topic也是分散存儲(chǔ)在多臺(tái) Broker 上的，每臺(tái)Broker上存儲(chǔ)的消息內(nèi)容是不同的。

(6) 如果不同的Topic存儲(chǔ)在不同的Broker里，可能某個(gè)topic數(shù)據(jù)太大了，出現(xiàn)數(shù)據(jù)傾斜直接干爆某個(gè)Broker怎么辦？

答：上面我們提到，Topic實(shí)際上是一個(gè)個(gè)隊(duì)列的集合，那只需要將隊(duì)列分散存儲(chǔ)到不同的Broker上就行了。

(7) 如果不同的Topic分散存儲(chǔ)在不同的Broker里，還是有數(shù)據(jù)丟失的風(fēng)險(xiǎn)，只不過(guò)某個(gè)topic丟失的數(shù)據(jù)變小而已，這種情況的數(shù)據(jù)容災(zāi)備份怎么做呢？

答：這時(shí)候就會(huì)用到Broker的主-從架構(gòu)，Broker按角色分為Master和Slave，主從之間會(huì)定期地進(jìn)行數(shù)據(jù)同步。Master 負(fù)責(zé)響應(yīng)客戶端的讀寫(xiě)請(qǐng)求、存儲(chǔ)消息、處理消費(fèi)者請(qǐng)求等，而 Slave 只負(fù)責(zé)同步 Master 的數(shù)據(jù)。

5.說(shuō)說(shuō)NameServer

(8) Broker既然是集群，那生產(chǎn)者在投遞消息時(shí)，總得知道有哪些Broker吧，總得知道要往哪個(gè)Broker里投遞消息吧，這又要怎么做呢？

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

• 集群里都有哪些Broker？
• 有哪些生產(chǎn)者？
• 有哪些消費(fèi)者？
• 集群里都有哪些 Topic？
• 這些 Topic 的消息隊(duì)列分別存在哪些 Broker 上？

(9) 那Nameserver如何知道這些消息呢？

答：類似古時(shí)候某個(gè)人去府里當(dāng)差，當(dāng)差之前要把自己的所有信息登記在冊(cè)。同樣的，Broker、Producer、Consumer在啟動(dòng)時(shí)也會(huì)將數(shù)據(jù)注冊(cè)到 NameServer。

Broker 在啟動(dòng)時(shí)會(huì)將自己注冊(cè)到 NameServer 上，通過(guò)心跳持續(xù)更新元數(shù)據(jù)。同樣的，Producer、Consumer也會(huì)和NameServer建立連接、動(dòng)態(tài)交互集群中的數(shù)據(jù)，這樣即方便上報(bào)自己的信息和也方便獲取集群里的其他信息。

至此，RocketMQ的架構(gòu)圖已經(jīng)成型，每一個(gè)部件這么設(shè)計(jì)的原因也很清晰。

二、總結(jié)

RocketMQ里的核心角色有4個(gè)：Broker、Producer、Consumer、NameServer，消息存儲(chǔ)的核心對(duì)象有兩個(gè)：Topic、MessageQueue。

為了保證數(shù)據(jù)不丟失和數(shù)據(jù)不傾斜，同一個(gè)Topic里的MessageQueue會(huì)分散存儲(chǔ)在不同的Broker里。