[[410293]]

前面幾篇文章分享了kafka 相關(guān)的實(shí)現(xiàn)邏輯，kafka在大吞吐量方面有較好的表現(xiàn)，但是有時(shí)候我們需要實(shí)現(xiàn)比較復(fù)雜的業(yè)務(wù)邏輯從而對(duì)于吞吐量方面要求不是太高，這個(gè)時(shí)候我們就可以選擇RocketMQ.

有了Kafka 為什么還要RocketMQ?

我們知道kafka 的性能非常好，吞吐量也非常大。Kafka單機(jī)寫入 TPS 號(hào)稱在百萬條/秒;追求性能的話，Kafka單機(jī)性能更高。這也依靠基于他的順序?qū)懭?，Memory Mapped Files 技術(shù) 和消費(fèi)者端的zero copy。(kafka基于sendfile實(shí)現(xiàn)Zero Copy，直接從內(nèi)核空間(DMA的)到內(nèi)核空間(Socket的)，然后發(fā)送網(wǎng)卡。)但是對(duì)平常工作中各種復(fù)雜的應(yīng)用場(chǎng)景及對(duì)數(shù)據(jù)可靠性要求嚴(yán)格的業(yè)務(wù)就有點(diǎn)力不從心了。我們從以下幾個(gè)方面分析：

【數(shù)據(jù)可靠性方面】

RocketMQ所支持的同步方式提升了數(shù)據(jù)的可靠性，RocketMQ支持異步/同步刷盤;異步/同步Replication;Kafka使用異步刷盤方式，異步Replication。

【消息順序性】

Kafka 某些配置下，支持消息順序，但是一臺(tái)Broker宕機(jī)后，就會(huì)產(chǎn)生消息亂序;

RocketMQ支持嚴(yán)格的消息順序，在順序消息場(chǎng)景下，一臺(tái)Broker宕機(jī)后，

發(fā)送消息會(huì)失敗，但是不會(huì)亂序;

【關(guān)于定時(shí)/延時(shí)消息】

Kafka不支持定時(shí)消息;

RocketMQ支持定時(shí)消息;

【關(guān)于分布式事務(wù)消息】

Kafka不支持分布式事務(wù)消息;RocketMQ支持分布式事務(wù)消息

【關(guān)于消息查詢機(jī)制】

Kafka不支持消息查詢。

RocketMQ支持根據(jù)Message Id查詢消息，也支持根據(jù)消息內(nèi)容查詢消息

【關(guān)于Broker 的設(shè)計(jì)上】

當(dāng)broker里面的topic的partition數(shù)量過多時(shí)，kafka的性能卻不如rocketMQ。

kafka和rocketMq都使用文件存儲(chǔ)，但是kafka是一個(gè)分區(qū)一個(gè)文件，當(dāng)topic過多，分區(qū)的總量也會(huì)增加，kafka中存在過多的文件，當(dāng)對(duì)消息刷盤時(shí)，就會(huì)出現(xiàn)文件競(jìng)爭(zhēng)磁盤，出現(xiàn)性能的下降。一個(gè)partition(分區(qū))一個(gè)文件，順序讀寫。一個(gè)分區(qū)只能被一個(gè)消費(fèi)組中的一個(gè) 消費(fèi)線程進(jìn)行消費(fèi)，因此可以同時(shí)消費(fèi)的消費(fèi)端也比較少。

rocketMq所有的隊(duì)列都存儲(chǔ)在一個(gè)文件中，每個(gè)隊(duì)列的存儲(chǔ)的消息量也比較小，因此topic的增加對(duì)rocketMq的性能的影響較小。rocketMq可以存在的topic比較多，可以適應(yīng)比較復(fù)雜的業(yè)務(wù)。

RocketMQ架構(gòu)設(shè)計(jì)

RocketMq技術(shù)架構(gòu)

RocketMQ架構(gòu)上主要分為四部分，如上圖所示:

• Producer：消息發(fā)布的角色，支持分布式集群方式部署。Producer通過MQ的負(fù)載均衡模塊選擇相應(yīng)的Broker集群隊(duì)列進(jìn)行消息投遞，投遞的過程支持快速失敗并且低延遲。
• Consumer：消息消費(fèi)的角色，支持分布式集群方式部署。支持以push推，pull拉兩種模式對(duì)消息進(jìn)行消費(fèi)。同時(shí)也支持集群方式和廣播方式的消費(fèi)，它提供實(shí)時(shí)消息訂閱機(jī)制，可以滿足大多數(shù)用戶的需求。
• NameServer：NameServer是一個(gè)非常簡(jiǎn)單的Topic路由注冊(cè)中心，其角色類似Dubbo中的zookeeper，支持Broker的動(dòng)態(tài)注冊(cè)與發(fā)現(xiàn)。主要包括兩個(gè)功能：Broker管理，NameServer接受Broker集群的注冊(cè)信息并且保存下來作為路由信息的基本數(shù)據(jù)。然后提供心跳檢測(cè)機(jī)制，檢查Broker是否還存活;路由信息管理，每個(gè)NameServer將保存關(guān)于Broker集群的整個(gè)路由信息和用于客戶端查詢的隊(duì)列信息。然后Producer和Conumser通過NameServer就可以知道整個(gè)Broker集群的路由信息，從而進(jìn)行消息的投遞和消費(fèi)。NameServer通常也是集群的方式部署，各實(shí)例間相互不進(jìn)行信息通訊。Broker是向每一臺(tái)NameServer注冊(cè)自己的路由信息，所以每一個(gè)NameServer實(shí)例上面都保存一份完整的路由信息。當(dāng)某個(gè)NameServer因某種原因下線了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以動(dòng)態(tài)感知Broker的路由的信息。但是NameServer 并不會(huì)像ZK 一樣提供選舉功能
• BrokerServer：Broker主要負(fù)責(zé)消息的存儲(chǔ)、投遞和查詢以及服務(wù)高可用保證，為了實(shí)現(xiàn)這些功能，Broker包含了以下幾個(gè)重要子模塊。
• Remoting Module：整個(gè)Broker的實(shí)體，負(fù)責(zé)處理來自clients端的請(qǐng)求。
• Client Manager：負(fù)責(zé)管理客戶端(Producer/Consumer)和維護(hù)Consumer的Topic訂閱信息
• Store Service：提供方便簡(jiǎn)單的API接口處理消息存儲(chǔ)到物理硬盤和查詢功能。
• HA Service：高可用服務(wù)，提供Master Broker 和 Slave Broker之間的數(shù)據(jù)同步功能。
• Index Service：根據(jù)特定的Message key對(duì)投遞到Broker的消息進(jìn)行索引服務(wù)，以提供消息的快速查詢。

RocketMq架構(gòu)部署

RocketMQ 網(wǎng)絡(luò)部署特點(diǎn)

NameServer是一個(gè)幾乎無狀態(tài)節(jié)點(diǎn)，可集群部署，節(jié)點(diǎn)之間無任何信息同步。

• 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)系通過指定相同的BrokerName，不同的BrokerId 來定義，BrokerId為0表示Master，非0表示Slave。Master也可以部署多個(gè)。每個(gè)Broker與NameServer集群中的所有節(jié)點(diǎn)建立長連接，定時(shí)注冊(cè)Topic信息到所有NameServer。注意：當(dāng)前RocketMQ版本在部署架構(gòu)上支持一Master多Slave，但只有BrokerId=1的從服務(wù)器才會(huì)參與消息的讀負(fù)載。
• Producer與NameServer集群中的其中一個(gè)節(jié)點(diǎn)(隨機(jī)選擇)建立長連接，定期從NameServer獲取Topic路由信息，并向提供Topic 服務(wù)的Master建立長連接，且定時(shí)向Master發(fā)送心跳。Producer完全無狀態(tài)，可集群部署。
• Consumer與NameServer集群中的其中一個(gè)節(jié)點(diǎn)(隨機(jī)選擇)建立長連接，定期從NameServer獲取Topic路由信息，并向提供Topic服務(wù)的Master、Slave建立長連接，且定時(shí)向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，消費(fèi)者在向Master拉取消息時(shí)，Master服務(wù)器會(huì)根據(jù)拉取偏移量與最大偏移量的距離(判斷是否讀老消息，產(chǎn)生讀I/O)，以及從服務(wù)器是否可讀等因素建議下一次是從Master還是Slave拉取。

結(jié)合部署架構(gòu)圖，描述集群工作流程：

• 啟動(dòng)NameServer，NameServer起來后監(jiān)聽端口，等待Broker、Producer、Consumer連上來，相當(dāng)于一個(gè)路由控制中心。
• Broker啟動(dòng)，跟所有的NameServer保持長連接，定時(shí)發(fā)送心跳包。心跳包中包含當(dāng)前Broker信息(IP+端口等)以及存儲(chǔ)所有Topic信息。注冊(cè)成功后，NameServer集群中就有Topic跟Broker的映射關(guān)系。
• 收發(fā)消息前，先創(chuàng)建Topic，創(chuàng)建Topic時(shí)需要指定該Topic要存儲(chǔ)在哪些Broker上，也可以在發(fā)送消息時(shí)自動(dòng)創(chuàng)建Topic。
• Producer發(fā)送消息，啟動(dòng)時(shí)先跟NameServer集群中的其中一臺(tái)建立長連接，并從NameServer中獲取當(dāng)前發(fā)送的Topic存在哪些Broker上，輪詢從隊(duì)列列表中選擇一個(gè)隊(duì)列，然后與隊(duì)列所在的Broker建立長連接從而向Broker發(fā)消息。
• Consumer跟Producer類似，跟其中一臺(tái)NameServer建立長連接，獲取當(dāng)前訂閱Topic存在哪些Broker上，然后直接跟Broker建立連接通道，開始消費(fèi)消息。

模塊間數(shù)據(jù)流轉(zhuǎn)

生產(chǎn)-消費(fèi)模型

生產(chǎn)消費(fèi)流程