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

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

產(chǎn)品選型

    我們在進行中間件選型時，一般都是通過下面幾點來進行產(chǎn)品選型的：

    1.性能

    2.功能支持程度

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

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

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

    6.中間件的學習程度是否簡單、文檔是否詳盡

    7.穩(wěn)定性

    8.集群功能是否完備

    ...

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

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

 (圖片來源于官方文檔)

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

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

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

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

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

核心特性

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

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

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

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

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

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

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

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

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

    5.隊列數(shù)量單機支持10000個以上；

    6.consumer支持集群功能，可以平均消費消息，當有一臺consumer宕機后，其它consumer繼續(xù)均分；

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

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

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

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

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

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

    13.支持消息過濾；