之前本人在實際的生產環(huán)境中，使用過activemq和rabbitmq消息隊列，在使用過程中出現一些難以解決的問題，本文通過產品選型、網絡架構和核心特性分析了rocketmq的優(yōu)勢和特性。
產品選型
我們在進行中間件選型時，一般都是通過下面幾點來進行產品選型的：
1.性能
2.功能支持程度
3.開發(fā)語言(團隊中是否有成員熟悉此中間件的開發(fā)語言，市場上此種語言的開發(fā)人員是否好招)
4.有多少公司已經在生產環(huán)境上實際使用過，使用的效果如何
5.社區(qū)的支持力度如何
6.中間件的學習程度是否簡單、文檔是否詳盡
7.穩(wěn)定性
8.集群功能是否完備
...
如果從以上8點來選型一個消息隊列，作為一名熟悉java的程序員，當遇到重新選擇消息隊列的場景時，我會毫不猶豫的選型rocketmq，rocketmq除了在第5點上表現略差(文檔少，學習成本高)以及監(jiān)控管理功能不友好外，從其它方面來說，它真的是一款非常優(yōu)秀的消息隊列中間件。
網絡架構
(圖片來源于官方文檔)
rocketmq的主要部分是由4種集群構成的：namesrv集群、broker集群、producer集群和consumer集群。
namesrv集群：也就是注冊中心，rocketmq在注冊中心這塊沒有使用第三方的中間件，而是自己寫的代碼來實現的，代碼行數才1000行，producer、broker和consumer在啟動時都需要向namesrv進行注冊，namesrv服務之間不通訊。
broker集群：broker提供關于消息的管理、存儲、分發(fā)等功能，是消息隊列的核心組件。rocket關于broker的集群提供了主要兩種方案，一種是主從同步方案，消息同時寫到master和slave服務器視為消息發(fā)送成功；另一種是異步方案，slave的異步服務負責讀取master的數據，本人在選擇時更傾向于異步方案。
producer集群：消息的生產者，每個producer都需要屬于一個group，producer的group概念除了在事務消息時起到一些作用，但是其它時候，更多的還只是一個虛擬的概念。
consumer集群：消息的消費者，有兩個主要的consumer:DefaultMQPullConsumer和DefaultMQPushConsumer，深入代碼后可以發(fā)現，rocket的consumer都是采用的pull模式來處理消息的。在集群消息的配置下，集群內各個服務平均分配消息，當其中一臺consumer宕機，分配給它的消息會繼續(xù)分配給其它的consumer。
核心特性
1.讀隊列數量和寫隊列數量可以不一致：當我們使用updateTopic命令創(chuàng)建topic時，會發(fā)現新建的topic下會有默認的8個寫對列和8個讀對列(依賴于配置)，并且讀隊列的數量和寫隊列的數量還可以不一致，這是為什么呢？難道在底層讀寫隊列是在物理上分離的嗎？抱著這個問題，我分析了相關的源代碼，發(fā)現底層代碼對于讀寫隊列指的都是同一個隊列，其中寫隊列的數量是針對的producer，讀隊列的數量針對的是consumer：
a.假設寫隊列有8個、讀隊列有4個，那么producer產生的消息會按輪訓的方式寫入到8個隊列中，但是consumer卻只能消費前4個隊列，只有把讀隊列重新設置為8后，consumer可以繼續(xù)消費后4個隊列的歷史消息；
b.假設寫隊列有4個、讀隊列有8個，那么producer產生的消息會按輪訓的方式寫入到4個隊列中，但是consumer卻能消費8個隊列，只是后4個隊列沒有消息可以消費罷了。
2.存儲為文件存儲方式，支持同步落盤和異步刷盤兩種方式，我傾向于選擇異步刷盤的方式，畢竟broker掛掉的概率比較小，大部分的業(yè)務場景下在極端情況下丟失及其少量消息是可以忍受的；
3.支持消息回溯，支持定期刪除歷史消息；
4.集群方案比activemq要優(yōu)秀很多，支持多主多從方案，例如在2主2從異步架構下，a,b為master,as,bs為slaver，當a機宕機后，producer會將消息全部發(fā)往b機，consumer會消費as，b和bs上的消息，理論上只會丟失毫秒級別的消息，不會影響業(yè)務的正常使用?？梢哉frocketmq的集群方案完爆activemq的集群方案，很多時候，我們對于異步隊列的性能要求不高，但是集群的可用性要求一定是很高的。下面是activemq的三種集群方案：
a.磁盤陣列類，成本較高，也是一種通用的方案；
b.利用jdbc來實現統(tǒng)一存儲消息，不但性能成問題，而且也只是把問題丟給了數據庫罷了，沒有解決集群的單機問題；
c.利用zookeeper的注冊中心的選主功能，在各個服務之間同步數據，在實際的使用過程中發(fā)現主機自動漂移，同步數據不完全造成的數據錯亂且服務啟動不了，反而不如單機來的穩(wěn)定；
5.隊列數量單機支持10000個以上；
6.consumer支持集群功能，可以平均消費消息，當有一臺consumer宕機后，其它consumer繼續(xù)均分；
7.consumer是靠pull的方式來消費消息的，性能不低于push的方式，這也是broker的并行能力強的一個原因，將主動權下放給了consumer，降低了broker的運算量和線程切換成本；
8.支持順序消息，可以在發(fā)送消息時，利用selector機制的hash方式取模來實現消息落到哪個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.支持消息過濾；
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
