核心組件（4個(gè)組件+消息存儲(chǔ)結(jié)構(gòu)）

客戶端消費(fèi)模式

1. MQ的使用場(chǎng)景

昨天在寫(xiě)完之后掀亩，有些讀者在評(píng)論中提出：到底什么時(shí)候用MQ？舉幾個(gè)典型的例子锻离。

1.最常用的就是Publish/Subscribe

從開(kāi)發(fā)模式中铺峭，我們使用過(guò)JAVA Swing Button EventListener或者使用JQuery 的自定義事件，由某個(gè)動(dòng)作觸發(fā)然后傳播下去汽纠，這個(gè)事件廣播就是Publish卫键，我們監(jiān)聽(tīng)的過(guò)程，就是訂閱的過(guò)程虱朵。這個(gè)是MQ最基本的功能莉炉。

舉個(gè)業(yè)務(wù)例子：訂單支付的過(guò)程，會(huì)牽扯到會(huì)員模塊碴犬、消息短信推送服務(wù)絮宁、訂單更新，最初我們還能想清楚服协，所有把代碼寫(xiě)在一個(gè)service中绍昂，但后續(xù)逐漸加業(yè)務(wù)，例如：會(huì)員還需要有積分蚯涮、會(huì)員余額要預(yù)警治专、會(huì)員等級(jí)也得變化、還得告訴商戶費(fèi)用結(jié)清了遭顶。我舉的例子可能不是很恰當(dāng)张峰，但這確實(shí)反映問(wèn)題了，系統(tǒng)過(guò)于耦合棒旗。從這里引入MQ喘批，對(duì)周邊業(yè)務(wù)做清理，附屬業(yè)務(wù)直接訂閱消息铣揉。

2.應(yīng)對(duì)大流量沖擊饶深、削峰填谷

系統(tǒng)的前端數(shù)據(jù)采集設(shè)備數(shù)量太大，且具有業(yè)務(wù)波峰逛拱。還有就是典型的雙11敌厘，促銷活動(dòng)會(huì)期間，系統(tǒng)會(huì)承受比正常流量高很多倍的沖擊朽合。此時(shí)俱两，采集的數(shù)據(jù)不要求實(shí)時(shí)饱狂，購(gòu)物訂單也不需要實(shí)時(shí)反饋給用戶，面對(duì)這種應(yīng)用場(chǎng)景宪彩，使用消息隊(duì)列可以實(shí)現(xiàn)消息的異步處理休讳、請(qǐng)求的流量削峰作用。

3.異構(gòu)系統(tǒng)的通信

直接上例子：一個(gè)系統(tǒng)有多個(gè)開(kāi)發(fā)小組尿孔，由于功能特點(diǎn)分別使用了C++俊柔、JAVA、Go活合、python等多種語(yǔ)言實(shí)現(xiàn)雏婶，系統(tǒng)之間需要通信，使用事件驅(qū)動(dòng)架構(gòu)芜辕，那么這里可以引入MQ了尚骄，作為異構(gòu)系統(tǒng)和事件驅(qū)動(dòng)架構(gòu)的backbone。

2. RocketMQ初識(shí)

首先應(yīng)該看看RocketMQ的收發(fā)消息模型：

消息收發(fā)模型

上圖侵续，你能看出來(lái)：

生產(chǎn)者生產(chǎn)消息倔丈，可以放到隊(duì)列中，多個(gè)消費(fèi)者可以消費(fèi)状蜗。

生產(chǎn)者的同一種消息需五，可以放到不同的隊(duì)列中，由消費(fèi)者消息轧坎。

實(shí)際部署圖：

物理部署圖

如上圖所示宏邮， RocketMQ的部署結(jié)構(gòu)有4部分組成：NameServer、Broker缸血、Producer蜜氨、Consumer。

這里我們抽象以下：分為客戶端（Producer捎泻、Consumer）飒炎、服務(wù)端（Broker、NameServer）兩部分笆豁。簡(jiǎn)單來(lái)說(shuō)郎汪，就是客戶端的收發(fā)消息、服務(wù)器接收消息并持久化闯狱。

2.1 客戶端的功能有什么煞赢？

client發(fā)送消息有負(fù)載均衡，因?yàn)榭蛻舳酥斜４嬷?dāng)前所有服務(wù)器列表哄孤，每次發(fā)送都切換一臺(tái)服務(wù)器發(fā)送消息照筑，服務(wù)均衡負(fù)載。

發(fā)送代碼為線程安全，支持高并發(fā)寫(xiě)操作凝危。

消費(fèi)者端負(fù)載均衡集群消費(fèi)模式下饭弓，同一個(gè)ID的所有消費(fèi)者實(shí)例平均消費(fèi)該Topic的所有隊(duì)列。這里要注意媒抠，廣播模式下，則一個(gè)consumer實(shí)例消費(fèi)這個(gè)Topic對(duì)應(yīng)的所有隊(duì)列咏花。這點(diǎn)和Apache ActiveMQ的主題訂閱是一樣的趴生，每個(gè)消費(fèi)者消費(fèi)Topic的所有內(nèi)容（若存在消費(fèi)者消費(fèi)慢，容易內(nèi)存溢出）昏翰。

2.2 服務(wù)端（Broker）的功能有什么苍匆？

Broker就是RocketMQ的核心了，RocketMQ高并發(fā)讀寫(xiě)主要利用Linux操作系統(tǒng)的PageCache特性棚菊，通過(guò)Java的MappedByteBuffer直接操作PageCache浸踩。MappedByteBuffer能直接將文件直接映射到內(nèi)存，其實(shí)就是Map把文件的內(nèi)容被映像到計(jì)算機(jī)虛擬內(nèi)存的一塊區(qū)域统求，這樣就可以直接操作內(nèi)存當(dāng)中的數(shù)據(jù)而無(wú)需操作的時(shí)候每次都通過(guò)I/O去物理硬盤(pán)寫(xiě)文件的检碗。

鼓勵(lì)下自己，下面開(kāi)始深入了

2.3 服務(wù)端存儲(chǔ)的消息結(jié)構(gòu)

RocketMQ高性能讀寫(xiě)码邻，得益于它的消息存儲(chǔ)結(jié)構(gòu)：commitLog和comsume queue兩部分組成折剃。（這部分大概了解，比別人多掌握一點(diǎn)）

數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)

commitLog

保存所有消息的元數(shù)據(jù)像屋，所有消息到達(dá)Broker之后都會(huì)保存到commitLog中怕犁，所有的topic消息都會(huì)寫(xiě)入一個(gè)commitLog中，通常的目錄是：

${user.home}/store/${commitlog}/${fileName}

每個(gè)commitLog上限是1G己莺，滿了之后會(huì)自動(dòng)新建一個(gè)commitLog文件保存數(shù)據(jù)奏甫。這里的Log文件會(huì)有清理機(jī)制，有兩種清理措施：

按時(shí)間清理凌受，默認(rèn)清理3天前的commitLog阵子。

按磁盤(pán)占比，當(dāng)磁盤(pán)使用到75%胁艰，開(kāi)始清理最老的commmitLog文件款筑。

consumeQueue

ConsumeQueue相當(dāng)于CommitLog的索引文件，消費(fèi)者消費(fèi)時(shí)會(huì)從consumeQueue中查找消息在commitLog中的offset腾么，再去commitLog中查找元數(shù)據(jù)奈梳。如果某個(gè)消息只在CommitLog中有數(shù)據(jù)，沒(méi)在ConsumerQueue中解虱， 則消費(fèi)者無(wú)法消費(fèi)

consumeQueue的數(shù)據(jù)結(jié)構(gòu)包含3個(gè)部分： consumeQueue中存儲(chǔ)單元是一個(gè)20字節(jié)定長(zhǎng)的二進(jìn)制數(shù)據(jù)攘须，順序?qū)戫樞蜃x 。如圖：

ConsumeQueue存儲(chǔ)格式的特性殴泰，保證了寫(xiě)過(guò)程的順序?qū)懕P(pán)（寫(xiě)CommitLog文件）于宙，在單臺(tái)服務(wù)器上浮驳，MQ元數(shù)據(jù)都落在單個(gè)文件上，大量數(shù)據(jù)IO都在順序?qū)懲粋€(gè)commitLog捞魁，滿1G了再寫(xiě)新的至会，真正意義上的順序?qū)懕P(pán)，再加上MQ默認(rèn)是累計(jì)4K才強(qiáng)制從PageCache中刷到磁盤(pán)（緩存）谱俭，所以高并發(fā)寫(xiě)性能突出奉件，至于讀取數(shù)據(jù)呢，有Queue的offset昆著、size县貌，讓讀盤(pán)操作是跳躍式的。在RocketMQ中讀取消息是依賴系統(tǒng)PageCache凑懂，PageCache命中率越高煤痕，讀性能越高，Linux平時(shí)也會(huì)盡量預(yù)讀數(shù)據(jù)接谨，使得應(yīng)用直接訪問(wèn)磁盤(pán)的概率降低摆碉。

3. 核心組件

3.1 Name Server

用于存儲(chǔ)Topic、Broker的關(guān)系脓豪，簡(jiǎn)單兆解、穩(wěn)定。多個(gè)Name-Server之間不通信跑揉，單臺(tái)NameServer宕機(jī)不影響其他NameServer與集群锅睛；及時(shí)整個(gè)NameServer集群宕機(jī)，已經(jīng)正常工作的Producer历谍、Consumer现拒、Broker仍然正常工作，但新加入的就無(wú)法工作望侈。

NameServer壓力不會(huì)大印蔬，主要用戶維持心跳和提供Toptic-Broker的關(guān)系。但如過(guò)topic過(guò)多脱衙，導(dǎo)致Nameserver心跳數(shù)據(jù)過(guò)大侥猬，網(wǎng)絡(luò)不好的情況下，傳輸失敗捐韩，導(dǎo)致NameServer誤認(rèn)為Broker心跳失敗退唠。

3.2 Broker

Broker部署相對(duì)復(fù)雜：

Broker分為Master與Slave，一個(gè)Master可以對(duì)應(yīng)多個(gè)Slave荤胁，但是一個(gè)Slave只能對(duì)應(yīng)一個(gè)Master瞧预。

Master與Slave的對(duì)應(yīng)關(guān)系通過(guò)指定相同的BrokerName，不同的BrokerId來(lái)定義。（BrokerId為0表示Master垢油，非0表示Slave）

Master也可以部署多個(gè)盆驹，每個(gè)Broker與Name Server集群中的所有節(jié)點(diǎn)建立長(zhǎng)連接，定時(shí)注冊(cè)Topic信息到所有Name Server滩愁。

具有高并發(fā)讀寫(xiě)躯喇，負(fù)載均衡和動(dòng)態(tài)伸縮的特性：

負(fù)載均衡：Broker上存Topic信息，Topic由多個(gè)隊(duì)列組成硝枉，隊(duì)列會(huì)平均分散在多個(gè)Broker上玖瘸，而Producer的發(fā)送機(jī)制保證消息盡量平均分布到所有隊(duì)列中，最終效果就是所有消息都平均落在每個(gè)Broker上檀咙。

動(dòng)態(tài)伸縮：Topic維度：假如一個(gè)Topic的消息量特別大，但集群水位壓力還是很低璃诀，就可以擴(kuò)大該Topic的隊(duì)列數(shù)弧可，Topic的隊(duì)列數(shù)跟發(fā)送、消費(fèi)速度成正比劣欢。Broker維度：如果集群水位很高了棕诵，需要擴(kuò)容，直接加機(jī)器部署B(yǎng)roker就可以凿将。Broker起來(lái)后想Namesrv注冊(cè)校套，Producer、Consumer通過(guò)Namesrv發(fā)現(xiàn)新Broker牧抵，立即跟該Broker直連笛匙，收發(fā)消息。

高可用與可靠性

高可用：Broker提供主備犀变，主宕機(jī)妹孙，備提供讀，不可寫(xiě)获枝。

可靠性：所有發(fā)送到Broker的消息蠢正，有同步刷盤(pán)和異步刷盤(pán)。同步刷盤(pán)時(shí)省店，消息寫(xiě)入物理文件才會(huì)返回成功嚣崭。異步刷盤(pán)時(shí)，只有機(jī)器宕機(jī)懦傍，才會(huì)產(chǎn)生消息丟失雹舀，broker掛掉可能會(huì)發(fā)生，但是機(jī)器宕機(jī)崩潰是很少發(fā)生的粗俱，除非突然斷電葱跋。

Broker與NameServer的心跳 ，單個(gè)Broker跟所有Namesrv保持心跳請(qǐng)求，心跳間隔為30秒娱俺，心跳請(qǐng)求中包括當(dāng)前Broker所有的Topic信息稍味。Namesrv會(huì)反查Broer的心跳信息，如果某個(gè)Broker在2分鐘之內(nèi)都沒(méi)有心跳荠卷，則認(rèn)為該Broker下線模庐，調(diào)整Topic跟Broker的對(duì)應(yīng)關(guān)系。但此時(shí)Namesrv不會(huì)主動(dòng)通知Producer油宜、Consumer有Broker宕機(jī)掂碱。

3.3 Producer

Producer啟動(dòng)時(shí)，也需要指定Namesrv的地址慎冤，從Namesrv集群中隨機(jī)選一臺(tái)建立長(zhǎng)連接疼燥。如果該Namesrver宕機(jī)，會(huì)自動(dòng)連其他Nameserver蚁堤。直到有可用的Namesrv為止醉者。

Producer每30秒從Namesrv獲取Topic跟Broker的映射關(guān)系，更新到本地內(nèi)存中披诗。Producer會(huì)和它要發(fā)送的topic相關(guān)的master類型的broker建立TCP連接撬即，每隔30秒發(fā)一次心跳。在Broker端也會(huì)每10秒掃描一次當(dāng)前注冊(cè)的Producer呈队，如果發(fā)現(xiàn)某個(gè)Producer超過(guò)2分鐘都沒(méi)有發(fā)心跳剥槐，則斷開(kāi)連接。

生產(chǎn)者發(fā)送時(shí)宪摧，會(huì)自動(dòng)輪詢當(dāng)前所有可發(fā)送的broker粒竖，一條消息發(fā)送成功，下次換另外一個(gè)broker發(fā)送几于，以達(dá)到消息平均落到所有的broker上温圆。

3.4 Consumer

消費(fèi)者啟動(dòng)時(shí)需要指定Namesrv地址，隨機(jī)與其中一個(gè)Namesrv建立長(zhǎng)連接孩革。消費(fèi)者每隔30秒從nameserver獲取所有topic的最新隊(duì)列情況（這意味著某個(gè)broker如果宕機(jī)岁歉，客戶端最多要30秒才能感知），并向提供Topic服務(wù)的Master膝蜈、Slave建立長(zhǎng)連接锅移，且定時(shí)向Master、Slave發(fā)送心跳饱搏。Consumer既可以從Master訂閱消息非剃，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定推沸。

Consumer跟Broker是長(zhǎng)連接备绽，會(huì)每隔30秒發(fā)心跳信息到Broker券坞。Broker端每10秒檢查一次當(dāng)前存活的Consumer，若發(fā)現(xiàn)某個(gè)Consumer 2分鐘內(nèi)沒(méi)有心跳肺素，就斷開(kāi)與該Consumer的連接恨锚，并且向該消費(fèi)組的其他實(shí)例發(fā)送通知，觸發(fā)該消費(fèi)者集群的負(fù)載均衡倍靡。

3.5 通信關(guān)系

Producer和Name Server：每一個(gè)Producer會(huì)與Name Server集群中的一臺(tái)機(jī)器建立TCP連接猴伶，會(huì)從這臺(tái)Name Server上拉取路由信息。

Producer和broker：Producer會(huì)和它要發(fā)送的topic相關(guān)的master類型的broker建立TCP連接塌西，用于發(fā)送消息以及定時(shí)的心跳信息他挎。broker中會(huì)記錄該P(yáng)roducer的信息，供查詢使用

broker與Name Server：broker（不管是master還是slave）會(huì)和每一臺(tái)Name Server機(jī)器來(lái)建立TCP連接捡需。broker在啟動(dòng)的時(shí)候會(huì)注冊(cè)自己配置的topic信息到Name Server集群的每一臺(tái)機(jī)器中办桨。即每一臺(tái)Name Server都有該broker的topic的配置信息。master與master之間無(wú)連接站辉，master與slave之間有連接

Consumer和Name Server：每一個(gè)Consumer會(huì)和Name Server集群中的一臺(tái)機(jī)器建立TCP連接呢撞，會(huì)從這臺(tái)Name Server上拉取路由信息，進(jìn)行負(fù)載均衡

Consumer和broker：Consumer可以與master或者slave的broker建立TCP連接來(lái)進(jìn)行消費(fèi)消息庵寞，Consumer也會(huì)向它所消費(fèi)的broker發(fā)送心跳信息，供broker記錄薛匪。

4. 消費(fèi)模式

4.1 消費(fèi)者端的消費(fèi)以及負(fù)載均衡

先討論消費(fèi)者的消費(fèi)模式捐川，消費(fèi)者有兩種模式消費(fèi)：

集群消費(fèi)

廣播消費(fèi)。

廣播消費(fèi)

每個(gè)消費(fèi)者消費(fèi)Topic下的所有隊(duì)列逸尖。

集群消費(fèi)

一個(gè)topic可以由同一個(gè)ID下所有消費(fèi)者分擔(dān)消費(fèi)古沥。具體例子：假如TopicA有6個(gè)隊(duì)列（kafka稱之為分區(qū)），某個(gè)消費(fèi)者ID起了2個(gè)消費(fèi)者實(shí)例娇跟，那么每個(gè)消費(fèi)者負(fù)責(zé)消費(fèi)3個(gè)隊(duì)列岩齿。如果再增加一個(gè)消費(fèi)者ID相同消費(fèi)者實(shí)例，即當(dāng)前共有3個(gè)消費(fèi)者同時(shí)消費(fèi)6個(gè)隊(duì)列苞俘，那每個(gè)消費(fèi)者負(fù)責(zé)2個(gè)隊(duì)列的消費(fèi)盹沈。

消費(fèi)者端的負(fù)載均衡，就是集群消費(fèi)模式下吃谣，同一個(gè)ID的所有消費(fèi)者實(shí)例平均消費(fèi)該Topic的所有隊(duì)列乞封。

對(duì)于負(fù)載均衡，在出現(xiàn)分區(qū)（kafka稱為分區(qū)）或者隊(duì)列（RocketMQ稱隊(duì)列）增加或者減少的時(shí)候岗憋、Consumer增加或者減少的時(shí)候都會(huì)進(jìn)行reblance操作肃晚。

對(duì)于RocketMQ：客戶端自己會(huì)定時(shí)對(duì)所有的topic的進(jìn)行reblance操作，對(duì)于每個(gè)topic仔戈，會(huì)從broker獲取所有Consumer列表关串，從broker獲取隊(duì)列列表拧廊，按照負(fù)載均衡策略，計(jì)算各自負(fù)責(zé)哪些隊(duì)列晋修。這種就要求進(jìn)行負(fù)載均衡的時(shí)候吧碾，各個(gè)Consumer獲取的數(shù)據(jù)是一致的，不然不同的Consumer的reblance結(jié)果就不同飞蚓。

遍歷Consumer下的所有topic滤港，然后根據(jù)topic訂閱所有的消息

獲取同一topic和Consumer Group下的所有Consumer

然后根據(jù)具體的分配策略來(lái)分配消費(fèi)隊(duì)列，分配的策略包含：平均分配趴拧、消費(fèi)端配置等

4.2 客戶端消費(fèi)是broker的Push還是客戶端的Pull溅漾？

實(shí)際上consumer的消費(fèi)只有主動(dòng)拉的方式，那么有沒(méi)有push的方式著榴？實(shí)際上類似http的請(qǐng)求長(zhǎng)連接添履，consumer發(fā)起pull請(qǐng)求，等待broker有數(shù)據(jù)之后脑又，再把數(shù)據(jù)push回來(lái)暮胧，實(shí)際上還是主動(dòng)拉消息。

以上我們對(duì)Rocket做了全面的理論探索问麸，后續(xù)配合實(shí)施外加代碼實(shí)戰(zhàn)往衷，帶你玩轉(zhuǎn)RocketMQ。