常見消息中間件之RocketMQ有什么用

這篇文章主要為大家展示了“常見消息中間件之RocketMQ有什么用”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“常見消息中間件之RocketMQ有什么用”這篇文章吧。

前言

　　RocketMQ是一款分布式、隊(duì)列模型的消息中間件，由阿里巴巴自主研發(fā)的一款適用于高并發(fā)、高可靠性、海量數(shù)據(jù)場(chǎng)景的消息中間件。早期開源2.X版本名為MetaQ；2015年迭代3.X版本，更名為RocketMQ，2016年貢獻(xiàn)給Apache，經(jīng)過一年多的孵化，最終成為Apache的頂級(jí)開源項(xiàng)目之一。RocketMQ是在Kafka的基礎(chǔ)上發(fā)展起來的，它的誕生參考借鑒了Apache Kafka（后面的文章我會(huì)單獨(dú)介紹Kafka）。起因是隨著阿里巴巴業(yè)務(wù)的發(fā)展，他們發(fā)現(xiàn)Kafka對(duì)于具體的業(yè)務(wù)場(chǎng)景支持的不完善，于是阿里巴巴的團(tuán)隊(duì)借鑒Kafka的設(shè)計(jì)思路，并結(jié)合自身“雙十一”場(chǎng)景，自行開發(fā)了更貼合自己業(yè)務(wù)場(chǎng)景的RocketMQ，對(duì)Kafka進(jìn)行了合理的擴(kuò)展和API豐富。RocketMQ的消息路由、存儲(chǔ)、集群劃分等設(shè)計(jì)思路與Kafka都極其相似，唯一的不同是 RocketMQ 對(duì)于業(yè)務(wù)特性的支持更完善，所以更適用于業(yè)務(wù)場(chǎng)景。

1 專業(yè)術(shù)語(yǔ)

　　每一個(gè)技術(shù)框架，都有它的專有名詞，RocketMQ的專業(yè)術(shù)語(yǔ)如下：

　　1）Producer：消息生產(chǎn)者，負(fù)責(zé)產(chǎn)生消息，一般由業(yè)務(wù)系統(tǒng)負(fù)責(zé)產(chǎn)生消息。

　　2）Consumer：消息消費(fèi)者，負(fù)責(zé)消費(fèi)消息，一般由后臺(tái)系統(tǒng)負(fù)責(zé)異步消費(fèi)。

　　3）Pull Consumer：Consumer的一種，需要主動(dòng)請(qǐng)求Broker拉取消息。

　　4）Push Consumer：Consumer的一種，需要向Consumer對(duì)象注冊(cè)監(jiān)聽。

　　5）Producer Group：生產(chǎn)者集合，一般用于發(fā)送一類消息。

　　6）Consumer Group：消費(fèi)者集合，一般用于接受一類消息進(jìn)行消費(fèi)。

　　7）Broker：MQ消息服務(wù)（中專角色，用于消息存儲(chǔ)和生產(chǎn)消費(fèi)轉(zhuǎn)發(fā)）。

2 能力與支持

　　1）支持集群模型、負(fù)載均衡、水平擴(kuò)展能力，如下面我們要講的集群架構(gòu)。

　　2）億級(jí)別的消息堆積能力。

　　3）采用零拷貝的原理、順序?qū)懕P、隨機(jī)讀（索引文件）。

　　4）豐富的API使用。

　　5）代碼優(yōu)秀，底層通信框架采用Netty NIO框架。

　　6）NameServer代替Zookeeper。

　　7）強(qiáng)調(diào)集群無單點(diǎn)，可擴(kuò)展，任意一點(diǎn)高可用，水平可擴(kuò)展。

　　8）消息失敗重試機(jī)制、消息可查詢。

　　9）開源社區(qū)活躍度高，足夠成熟（經(jīng)過雙十一考驗(yàn)）。

3 核心源碼包及功能說明

　　如下圖，我們看一下RocketMQ源碼包的組成，這有利于我們以后更深入的學(xué)習(xí)。

　　1）rocketmq-broker 主要的業(yè)務(wù)邏輯，消息收發(fā)，主從同步,pagecache

　　2）rocketmq-client 客戶端接口，比如生產(chǎn)者和消費(fèi)者

　　3）rocketmq-common 公用數(shù)據(jù)結(jié)構(gòu)等等

　　4）rocketmq-distribution 編譯模塊，編譯輸出等

　　5）rocketmq-example 示例，比如生產(chǎn)者和消費(fèi)者

　　6）rocketmq-fliter 進(jìn)行Broker過濾的不感興趣的消息傳輸，減小帶寬壓力

　　7）rocketmq-logappender、rocketmq-logging日志相關(guān)

　　8）rocketmq-namesrv Namesrv服務(wù)，用于服務(wù)協(xié)調(diào)

　　9）rocketmq-openmessaging 對(duì)外提供服務(wù)

　　10）rocketmq-remoting 遠(yuǎn)程調(diào)用接口，封裝Netty底層通信

　　11）rocketmq-srvutil 提供一些公用的工具方法，比如解析命令行參數(shù)

　　12）rocketmq-store 消息存儲(chǔ)核心包

　　13）rocketmq-test 提供一些測(cè)試代碼包

　　14）rocketmq-tools 管理工具，比如有名的mqadmin工具

 4 集群架構(gòu)

　　RocketMQ為我們提供了豐富的集群架構(gòu)模型，包括單點(diǎn)模式、主從模式、雙主模式以及生產(chǎn)上使用最多的雙主雙主模式（或者說多主多從模式），我們來看一下最經(jīng)典的雙主雙從模式，如下圖：

　　1）NameServer集群

　　NameServer集群作為超輕量級(jí)的配置中心，存儲(chǔ)當(dāng)前集群所有的Broker信息、Topic與Broker的對(duì)應(yīng)關(guān)系。每個(gè)NameServer記錄完整的路由信息，提供等效的讀寫服務(wù)，并支持快速存儲(chǔ)擴(kuò)展。NameServer只做集群元數(shù)據(jù)存儲(chǔ)和心跳工作，功能簡(jiǎn)單，穩(wěn)定性高。多個(gè)NameServer之間沒有通信，不必保障節(jié)點(diǎn)間的數(shù)據(jù)強(qiáng)一致性，也就是說NameServer集群是一個(gè)多機(jī)熱備的概念，單臺(tái)NameServer宕機(jī)不影響其他NameServer工作。需要注意的是，及時(shí)整個(gè)NameServer集群宕機(jī)了，已經(jīng)正常工作的Producer、Consumer、Broker仍然能正常工作，但新起的Producer、Consumer、Broker就無法工作。

　　NameServer采用的是心跳機(jī)制，具體如下：

　　a、單個(gè)Broker跟所有NameServer保持心跳請(qǐng)求，心跳間隔為30秒，心跳請(qǐng)求中包括當(dāng)前Broker所有的Topic信息。需要注意的是，Broker向Namesrv發(fā)心跳時(shí)， 會(huì)帶上當(dāng)前自己所負(fù)責(zé)的所有Topic信息，如果Topic個(gè)數(shù)太多（萬級(jí)別），會(huì)導(dǎo)致一次心跳中，就Topic的數(shù)據(jù)就幾十M，網(wǎng)絡(luò)情況差的話， 網(wǎng)絡(luò)傳輸失敗，心跳失敗，導(dǎo)致Namesrv誤認(rèn)為Broker心跳失敗。

　　b、NameServer會(huì)反查Broer的心跳信息， 如果某個(gè)Broker在2分鐘之內(nèi)都沒有心跳，則認(rèn)為該Broker下線，調(diào)整Topic跟Broker的對(duì)應(yīng)關(guān)系。但此時(shí)NameServer不會(huì)主動(dòng)通知Producer、Consumer有Broker宕機(jī)。

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

　　d、生產(chǎn)者每30秒從Namesrv獲取Topic跟Broker的映射關(guān)系，更新到本地內(nèi)存中。再跟Topic涉及的所有Broker建立長(zhǎng)連接，每隔30秒發(fā)一次心跳。在Broker端也會(huì)每10秒掃描一次當(dāng)前注冊(cè)的Producer，如果發(fā)現(xiàn)某個(gè)Producer超過2分鐘都沒有發(fā)心跳，則斷開連接。

　　2）Producer集群

　　Producer集群就是消息生產(chǎn)者集群，它們?cè)谕粋€(gè)生產(chǎn)者組Producer Group。Producer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)選擇）建立長(zhǎng)連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master建立長(zhǎng)連接，且定時(shí)向Master發(fā)送心跳。Producer完全無狀態(tài)，可集群部署。

　　3）Consumer集群

　　Consumer集群就是消息消費(fèi)者，它們?cè)谕粋€(gè)消費(fèi)者組Consumer Group。Consumer與Name Server集群中的其中一個(gè)節(jié)點(diǎn)（隨機(jī)選擇）建立長(zhǎng)連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master、Slave建立長(zhǎng)連接，且定時(shí)向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定。

　　4）Broker集群

　　對(duì)于Broker來說，通常Master和Slave為一組服務(wù)，它們互為主從節(jié)點(diǎn)，通過NameServer與外部的Client端暴露統(tǒng)一的集群入口。Broker就是消息存儲(chǔ)的核心MQ服務(wù)。

5 總結(jié)

　　RockerMQ作為國(guó)內(nèi)頂級(jí)的消息中間件，其性能主要依賴于天然的分布式Topic/Queue，并且其內(nèi)存與磁盤都會(huì)存儲(chǔ)消息數(shù)據(jù)，借鑒了Kafka的“空中接力”概念，就是指數(shù)據(jù)不一定落地，RocketMQ提供了同步/異步雙寫、同步/異步復(fù)制的特性。在真正的生產(chǎn)環(huán)境中應(yīng)該選擇符合自己業(yè)務(wù)的配置。下面針對(duì)RocketMQ的高性能和瓶頸加以說明：

　　1）在實(shí)際生產(chǎn)環(huán)境中面臨的主要瓶頸最終會(huì)落在IOPS上，也就是磁盤讀寫能力。當(dāng)高峰期來臨，每秒收發(fā)消息IOPS達(dá)到10W+消息，在云環(huán)境上，云環(huán)境的SSD物理存儲(chǔ)顯然和自建機(jī)房SSD有著很大的差距，這一點(diǎn)我們無論是從數(shù)據(jù)庫(kù)的磁盤性能、還是搜索服務(wù)（ElasticSearch）的磁盤性能，都能給出準(zhǔn)確的瓶頸點(diǎn)，單機(jī)IOPS達(dá)到1萬左右就是云存儲(chǔ)SSD的性能瓶頸，在這里我們也看到了“木桶短板原理”的效應(yīng)，在真正的生產(chǎn)中，CPU的工作主要在等待IO操作，高并發(fā)下CPU資源接近極限，但是IOPS還是達(dá)不到我們想要的效果。

　　2）RocketMQ的性能已經(jīng)足夠好，但是在很多時(shí)候，我們的業(yè)務(wù)會(huì)有一些非核心的消息投遞，可以進(jìn)行消息中間件的業(yè)務(wù)拆分，把不重要的消息（允許消息丟失、非可靠性投遞的消息）采用Kafka的異步發(fā)送機(jī)制，借住Kafka強(qiáng)大的吞吐量和消息堆積能力來做業(yè)務(wù)分流，以此緩解RocketMQ的性能瓶頸。

以上是“常見消息中間件之RocketMQ有什么用”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！