這篇文章主要為大家展示了“常見消息中間件之RocketMQ有什么用”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“常見消息中間件之RocketMQ有什么用”這篇文章吧。
創(chuàng)新互聯(lián)公司是專業(yè)的長海網(wǎng)站建設(shè)公司，長海接單;提供網(wǎng)站制作、做網(wǎng)站,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行長海網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
RocketMQ是一款分布式、隊列模型的消息中間件，由阿里巴巴自主研發(fā)的一款適用于高并發(fā)、高可靠性、海量數(shù)據(jù)場景的消息中間件。早期開源2.X版本名為MetaQ；2015年迭代3.X版本，更名為RocketMQ，2016年貢獻給Apache，經(jīng)過一年多的孵化，最終成為Apache的頂級開源項目之一。RocketMQ是在Kafka的基礎(chǔ)上發(fā)展起來的，它的誕生參考借鑒了Apache Kafka（后面的文章我會單獨介紹Kafka）。起因是隨著阿里巴巴業(yè)務(wù)的發(fā)展，他們發(fā)現(xiàn)Kafka對于具體的業(yè)務(wù)場景支持的不完善，于是阿里巴巴的團隊借鑒Kafka的設(shè)計思路，并結(jié)合自身“雙十一”場景，自行開發(fā)了更貼合自己業(yè)務(wù)場景的RocketMQ，對Kafka進行了合理的擴展和API豐富。RocketMQ的消息路由、存儲、集群劃分等設(shè)計思路與Kafka都極其相似，唯一的不同是 RocketMQ 對于業(yè)務(wù)特性的支持更完善，所以更適用于業(yè)務(wù)場景。
每一個技術(shù)框架，都有它的專有名詞，RocketMQ的專業(yè)術(shù)語如下：
1）Producer：消息生產(chǎn)者，負(fù)責(zé)產(chǎn)生消息，一般由業(yè)務(wù)系統(tǒng)負(fù)責(zé)產(chǎn)生消息。
2）Consumer：消息消費者，負(fù)責(zé)消費消息，一般由后臺系統(tǒng)負(fù)責(zé)異步消費。
3）Pull Consumer：Consumer的一種，需要主動請求Broker拉取消息。
4）Push Consumer：Consumer的一種，需要向Consumer對象注冊監(jiān)聽。
5）Producer Group：生產(chǎn)者集合，一般用于發(fā)送一類消息。
6）Consumer Group：消費者集合，一般用于接受一類消息進行消費。
7）Broker：MQ消息服務(wù)（中專角色，用于消息存儲和生產(chǎn)消費轉(zhuǎn)發(fā)）。
1）支持集群模型、負(fù)載均衡、水平擴展能力，如下面我們要講的集群架構(gòu)。
2）億級別的消息堆積能力。
3）采用零拷貝的原理、順序?qū)懕P、隨機讀（索引文件）。
4）豐富的API使用。
5）代碼優(yōu)秀，底層通信框架采用Netty NIO框架。
6）NameServer代替Zookeeper。
7）強調(diào)集群無單點，可擴展，任意一點高可用，水平可擴展。
8）消息失敗重試機制、消息可查詢。
9）開源社區(qū)活躍度高，足夠成熟（經(jīng)過雙十一考驗）。
如下圖，我們看一下RocketMQ源碼包的組成，這有利于我們以后更深入的學(xué)習(xí)。
1）rocketmq-broker 主要的業(yè)務(wù)邏輯，消息收發(fā)，主從同步,pagecache
2）rocketmq-client 客戶端接口，比如生產(chǎn)者和消費者
3）rocketmq-common 公用數(shù)據(jù)結(jié)構(gòu)等等
4）rocketmq-distribution 編譯模塊，編譯輸出等
5）rocketmq-example 示例，比如生產(chǎn)者和消費者
6）rocketmq-fliter 進行Broker過濾的不感興趣的消息傳輸，減小帶寬壓力
7）rocketmq-logappender、rocketmq-logging日志相關(guān)
8）rocketmq-namesrv Namesrv服務(wù)，用于服務(wù)協(xié)調(diào)
9）rocketmq-openmessaging 對外提供服務(wù)
10）rocketmq-remoting 遠程調(diào)用接口，封裝Netty底層通信
11）rocketmq-srvutil 提供一些公用的工具方法，比如解析命令行參數(shù)
12）rocketmq-store 消息存儲核心包
13）rocketmq-test 提供一些測試代碼包
14）rocketmq-tools 管理工具，比如有名的mqadmin工具
RocketMQ為我們提供了豐富的集群架構(gòu)模型，包括單點模式、主從模式、雙主模式以及生產(chǎn)上使用最多的雙主雙主模式（或者說多主多從模式），我們來看一下最經(jīng)典的雙主雙從模式，如下圖：
1）NameServer集群
NameServer集群作為超輕量級的配置中心，存儲當(dāng)前集群所有的Broker信息、Topic與Broker的對應(yīng)關(guān)系。每個NameServer記錄完整的路由信息，提供等效的讀寫服務(wù)，并支持快速存儲擴展。NameServer只做集群元數(shù)據(jù)存儲和心跳工作，功能簡單，穩(wěn)定性高。多個NameServer之間沒有通信，不必保障節(jié)點間的數(shù)據(jù)強一致性，也就是說NameServer集群是一個多機熱備的概念，單臺NameServer宕機不影響其他NameServer工作。需要注意的是，及時整個NameServer集群宕機了，已經(jīng)正常工作的Producer、Consumer、Broker仍然能正常工作，但新起的Producer、Consumer、Broker就無法工作。
NameServer采用的是心跳機制，具體如下：
a、單個Broker跟所有NameServer保持心跳請求，心跳間隔為30秒，心跳請求中包括當(dāng)前Broker所有的Topic信息。需要注意的是，Broker向Namesrv發(fā)心跳時， 會帶上當(dāng)前自己所負(fù)責(zé)的所有Topic信息，如果Topic個數(shù)太多（萬級別），會導(dǎo)致一次心跳中，就Topic的數(shù)據(jù)就幾十M，網(wǎng)絡(luò)情況差的話， 網(wǎng)絡(luò)傳輸失敗，心跳失敗，導(dǎo)致Namesrv誤認(rèn)為Broker心跳失敗。
b、NameServer會反查Broer的心跳信息， 如果某個Broker在2分鐘之內(nèi)都沒有心跳，則認(rèn)為該Broker下線，調(diào)整Topic跟Broker的對應(yīng)關(guān)系。但此時NameServer不會主動通知Producer、Consumer有Broker宕機。
c、Consumer跟Broker是長連接，會每隔30秒發(fā)心跳信息到Broker。Broker端每10秒檢查一次當(dāng)前存活的Consumer，若發(fā)現(xiàn)某個Consumer 2分鐘內(nèi)沒有心跳， 就斷開與該Consumer的連接，并且向該消費組的其他實例發(fā)送通知，觸發(fā)該消費者集群的負(fù)載均衡(rebalance)。
d、生產(chǎn)者每30秒從Namesrv獲取Topic跟Broker的映射關(guān)系，更新到本地內(nèi)存中。再跟Topic涉及的所有Broker建立長連接，每隔30秒發(fā)一次心跳。在Broker端也會每10秒掃描一次當(dāng)前注冊的Producer，如果發(fā)現(xiàn)某個Producer超過2分鐘都沒有發(fā)心跳，則斷開連接。
2）Producer集群
Producer集群就是消息生產(chǎn)者集群，它們在同一個生產(chǎn)者組Producer Group。Producer與Name Server集群中的其中一個節(jié)點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master建立長連接，且定時向Master發(fā)送心跳。Producer完全無狀態(tài)，可集群部署。
3）Consumer集群
Consumer集群就是消息消費者，它們在同一個消費者組Consumer Group。Consumer與Name Server集群中的其中一個節(jié)點（隨機選擇）建立長連接，定期從Name Server取Topic路由信息，并向提供Topic服務(wù)的Master、Slave建立長連接，且定時向Master、Slave發(fā)送心跳。Consumer既可以從Master訂閱消息，也可以從Slave訂閱消息，訂閱規(guī)則由Broker配置決定。
4）Broker集群
對于Broker來說，通常Master和Slave為一組服務(wù)，它們互為主從節(jié)點，通過NameServer與外部的Client端暴露統(tǒng)一的集群入口。Broker就是消息存儲的核心MQ服務(wù)。
RockerMQ作為國內(nèi)頂級的消息中間件，其性能主要依賴于天然的分布式Topic/Queue，并且其內(nèi)存與磁盤都會存儲消息數(shù)據(jù)，借鑒了Kafka的“空中接力”概念，就是指數(shù)據(jù)不一定落地，RocketMQ提供了同步/異步雙寫、同步/異步復(fù)制的特性。在真正的生產(chǎn)環(huán)境中應(yīng)該選擇符合自己業(yè)務(wù)的配置。下面針對RocketMQ的高性能和瓶頸加以說明：
1）在實際生產(chǎn)環(huán)境中面臨的主要瓶頸最終會落在IOPS上，也就是磁盤讀寫能力。當(dāng)高峰期來臨，每秒收發(fā)消息IOPS達到10W+消息，在云環(huán)境上，云環(huán)境的SSD物理存儲顯然和自建機房SSD有著很大的差距，這一點我們無論是從數(shù)據(jù)庫的磁盤性能、還是搜索服務(wù)（ElasticSearch）的磁盤性能，都能給出準(zhǔn)確的瓶頸點，單機IOPS達到1萬左右就是云存儲SSD的性能瓶頸，在這里我們也看到了“木桶短板原理”的效應(yīng)，在真正的生產(chǎn)中，CPU的工作主要在等待IO操作，高并發(fā)下CPU資源接近極限，但是IOPS還是達不到我們想要的效果。
2）RocketMQ的性能已經(jīng)足夠好，但是在很多時候，我們的業(yè)務(wù)會有一些非核心的消息投遞，可以進行消息中間件的業(yè)務(wù)拆分，把不重要的消息（允許消息丟失、非可靠性投遞的消息）采用Kafka的異步發(fā)送機制，借住Kafka強大的吞吐量和消息堆積能力來做業(yè)務(wù)分流，以此緩解RocketMQ的性能瓶頸。
以上是“常見消息中間件之RocketMQ有什么用”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
重慶分公司
重慶分公司
