之前本人在實(shí)際的生產(chǎn)環(huán)境中，使用過activemq和rabbitmq消息隊(duì)列，在使用過程中出現(xiàn)一些難以解決的問題，本文通過產(chǎn)品選型、網(wǎng)絡(luò)架構(gòu)和核心特性分析了rocketmq的優(yōu)勢(shì)和特性。

你所需要的網(wǎng)站建設(shè)服務(wù)，我們均能行業(yè)靠前的水平為你提供.標(biāo)準(zhǔn)是產(chǎn)品質(zhì)量的保證，主要從事做網(wǎng)站、網(wǎng)站制作、企業(yè)網(wǎng)站建設(shè)、手機(jī)網(wǎng)站制作設(shè)計(jì)、網(wǎng)頁設(shè)計(jì)、品牌網(wǎng)站設(shè)計(jì)、網(wǎng)頁制作、做網(wǎng)站、建網(wǎng)站。創(chuàng)新互聯(lián)擁有實(shí)力堅(jiān)強(qiáng)的技術(shù)研發(fā)團(tuán)隊(duì)及素養(yǎng)的視覺設(shè)計(jì)專才。

產(chǎn)品選型

    我們?cè)谶M(jìn)行中間件選型時(shí)，一般都是通過下面幾點(diǎn)來進(jìn)行產(chǎn)品選型的：

    1.性能

    2.功能支持程度

    3.開發(fā)語言(團(tuán)隊(duì)中是否有成員熟悉此中間件的開發(fā)語言，市場(chǎng)上此種語言的開發(fā)人員是否好招)

    4.有多少公司已經(jīng)在生產(chǎn)環(huán)境上實(shí)際使用過，使用的效果如何

    5.社區(qū)的支持力度如何

    6.中間件的學(xué)習(xí)程度是否簡(jiǎn)單、文檔是否詳盡

    7.穩(wěn)定性

    8.集群功能是否完備

    ...

    如果從以上8點(diǎn)來選型一個(gè)消息隊(duì)列，作為一名熟悉java的程序員，當(dāng)遇到重新選擇消息隊(duì)列的場(chǎng)景時(shí)，我會(huì)毫不猶豫的選型rocketmq，rocketmq除了在第5點(diǎn)上表現(xiàn)略差(文檔少，學(xué)習(xí)成本高)以及監(jiān)控管理功能不友好外，從其它方面來說，它真的是一款非常優(yōu)秀的消息隊(duì)列中間件。

 

網(wǎng)絡(luò)架構(gòu)

 

 (圖片來源于官方文檔)

    rocketmq的主要部分是由4種集群構(gòu)成的：namesrv集群、broker集群、producer集群和consumer集群。

    namesrv集群：也就是注冊(cè)中心，rocketmq在注冊(cè)中心這塊沒有使用第三方的中間件，而是自己寫的代碼來實(shí)現(xiàn)的，代碼行數(shù)才1000行，producer、broker和consumer在啟動(dòng)時(shí)都需要向namesrv進(jìn)行注冊(cè)，namesrv服務(wù)之間不通訊。

    broker集群：broker提供關(guān)于消息的管理、存儲(chǔ)、分發(fā)等功能，是消息隊(duì)列的核心組件。rocket關(guān)于broker的集群提供了主要兩種方案，一種是主從同步方案，消息同時(shí)寫到master和slave服務(wù)器視為消息發(fā)送成功；另一種是異步方案，slave的異步服務(wù)負(fù)責(zé)讀取master的數(shù)據(jù)，本人在選擇時(shí)更傾向于異步方案。

    producer集群：消息的生產(chǎn)者，每個(gè)producer都需要屬于一個(gè)group，producer的group概念除了在事務(wù)消息時(shí)起到一些作用，但是其它時(shí)候，更多的還只是一個(gè)虛擬的概念。

    consumer集群：消息的消費(fèi)者，有兩個(gè)主要的consumer:DefaultMQPullConsumer和DefaultMQPushConsumer，深入代碼后可以發(fā)現(xiàn)，rocket的consumer都是采用的pull模式來處理消息的。在集群消息的配置下，集群內(nèi)各個(gè)服務(wù)平均分配消息，當(dāng)其中一臺(tái)consumer宕機(jī)，分配給它的消息會(huì)繼續(xù)分配給其它的consumer。

   

核心特性

    1.讀隊(duì)列數(shù)量和寫隊(duì)列數(shù)量可以不一致：當(dāng)我們使用updateTopic命令創(chuàng)建topic時(shí)，會(huì)發(fā)現(xiàn)新建的topic下會(huì)有默認(rèn)的8個(gè)寫對(duì)列和8個(gè)讀對(duì)列(依賴于配置)，并且讀隊(duì)列的數(shù)量和寫隊(duì)列的數(shù)量還可以不一致，這是為什么呢？難道在底層讀寫隊(duì)列是在物理上分離的嗎？抱著這個(gè)問題，我分析了相關(guān)的源代碼，發(fā)現(xiàn)底層代碼對(duì)于讀寫隊(duì)列指的都是同一個(gè)隊(duì)列，其中寫隊(duì)列的數(shù)量是針對(duì)的producer，讀隊(duì)列的數(shù)量針對(duì)的是consumer：

           a.假設(shè)寫隊(duì)列有8個(gè)、讀隊(duì)列有4個(gè)，那么producer產(chǎn)生的消息會(huì)按輪訓(xùn)的方式寫入到8個(gè)隊(duì)列中，但是consumer卻只能消費(fèi)前4個(gè)隊(duì)列，只有把讀隊(duì)列重新設(shè)置為8后，consumer可以繼續(xù)消費(fèi)后4個(gè)隊(duì)列的歷史消息；

           b.假設(shè)寫隊(duì)列有4個(gè)、讀隊(duì)列有8個(gè)，那么producer產(chǎn)生的消息會(huì)按輪訓(xùn)的方式寫入到4個(gè)隊(duì)列中，但是consumer卻能消費(fèi)8個(gè)隊(duì)列，只是后4個(gè)隊(duì)列沒有消息可以消費(fèi)罷了。

    2.存儲(chǔ)為文件存儲(chǔ)方式，支持同步落盤和異步刷盤兩種方式，我傾向于選擇異步刷盤的方式，畢竟broker掛掉的概率比較小，大部分的業(yè)務(wù)場(chǎng)景下在極端情況下丟失及其少量消息是可以忍受的；

    3.支持消息回溯，支持定期刪除歷史消息；

    4.集群方案比activemq要優(yōu)秀很多，支持多主多從方案，例如在2主2從異步架構(gòu)下，a,b為master,as,bs為slaver，當(dāng)a機(jī)宕機(jī)后，producer會(huì)將消息全部發(fā)往b機(jī)，consumer會(huì)消費(fèi)as，b和bs上的消息，理論上只會(huì)丟失毫秒級(jí)別的消息，不會(huì)影響業(yè)務(wù)的正常使用。可以說rocketmq的集群方案完爆activemq的集群方案，很多時(shí)候，我們對(duì)于異步隊(duì)列的性能要求不高，但是集群的可用性要求一定是很高的。下面是activemq的三種集群方案：

           a.磁盤陣列類，成本較高，也是一種通用的方案；

           b.利用jdbc來實(shí)現(xiàn)統(tǒng)一存儲(chǔ)消息，不但性能成問題，而且也只是把問題丟給了數(shù)據(jù)庫罷了，沒有解決集群的單機(jī)問題；

           c.利用zookeeper的注冊(cè)中心的選主功能，在各個(gè)服務(wù)之間同步數(shù)據(jù)，在實(shí)際的使用過程中發(fā)現(xiàn)主機(jī)自動(dòng)漂移，同步數(shù)據(jù)不完全造成的數(shù)據(jù)錯(cuò)亂且服務(wù)啟動(dòng)不了，反而不如單機(jī)來的穩(wěn)定；

    5.隊(duì)列數(shù)量單機(jī)支持10000個(gè)以上；

    6.consumer支持集群功能，可以平均消費(fèi)消息，當(dāng)有一臺(tái)consumer宕機(jī)后，其它c(diǎn)onsumer繼續(xù)均分；

    7.consumer是靠pull的方式來消費(fèi)消息的，性能不低于push的方式，這也是broker的并行能力強(qiáng)的一個(gè)原因，將主動(dòng)權(quán)下放給了consumer，降低了broker的運(yùn)算量和線程切換成本；

    8.支持順序消息，可以在發(fā)送消息時(shí)，利用selector機(jī)制的hash方式取模來實(shí)現(xiàn)消息落到哪個(gè)broker的哪個(gè)queue上，當(dāng)某個(gè)broker宕機(jī)后，由于取模值也發(fā)生變化，會(huì)自動(dòng)切換隊(duì)列；

    9.producer發(fā)送消息時(shí)支持同步返回、異步返回和oneway三種方式；

    10.broker保證每條消息至少投遞到consumer一次，因此consumer的業(yè)務(wù)需要支持冪等；

    11.消息堆積能力驚人，消息隊(duì)列的一個(gè)作用便是防止洪峰直接沖垮后端業(yè)務(wù)；

    12.支持按照消息id和消息key來查詢消息，本人很喜歡按照key來查詢消息這個(gè)功能，例如在下單業(yè)務(wù)中，可以使用訂單id作為key，便于分析異常訂單在系統(tǒng)中的處理過程；

    13.支持消息過濾；

分享標(biāo)題：Rocketmq整體分析
網(wǎng)頁地址：http://sd-ha.com/article36/jgedpg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、Google、營(yíng)銷型網(wǎng)站建設(shè)、服務(wù)器托管、建站公司、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)