之前本人在實際的生產環境中，使用過activemq和rabbitmq消息隊列，在使用過程中出現一些難以解決的問題，本文通過產品選型、網絡架構和核心特性分析了rocketmq的優勢和特性。
產品選型
我們在進行中間件選型時，一般都是通過下面幾點來進行產品選型的：
1.性能
2.功能支持程度
3.開發語言(團隊中是否有成員熟悉此中間件的開發語言，市場上此種語言的開發人員是否好招)
4.有多少公司已經在生產環境上實際使用過，使用的效果如何
5.社區的支持力度如何
6.中間件的學習程度是否簡單、文檔是否詳盡
7.穩定性
8.集群功能是否完備
...
如果從以上8點來選型一個消息隊列，作為一名熟悉java的程序員，當遇到重新選擇消息隊列的場景時，我會毫不猶豫的選型rocketmq，rocketmq除了在第5點上表現略差(文檔少，學習成本高)以及監控管理功能不友好外，從其它方面來說，它真的是一款非常優秀的消息隊列中間件。
網絡架構
(圖片來源於官方文檔)
rocketmq的主要部分是由4種集群構成的：namesrv集群、broker集群、producer集群和consumer集群。
namesrv集群：也就是注冊中心，rocketmq在注冊中心這塊沒有使用第三方的中間件，而是自己寫的代碼來實現的，代碼行數才1000行，producer、broker和consumer在啟動時都需要向namesrv進行注冊，namesrv服務之間不通訊。
broker集群：broker提供關於消息的管理、存儲、分發等功能，是消息隊列的核心組件。rocket關於broker的集群提供了主要兩種方案，一種是主從同步方案，消息同時寫到master和slave服務器視為消息發送成功；另一種是異步方案，slave的異步服務負責讀取master的數據，本人在選擇時更傾向於異步方案。
producer集群：消息的生產者，每個producer都需要屬於一個group，producer的group概念除了在事務消息時起到一些作用，但是其它時候，更多的還只是一個虛擬的概念。
consumer集群：消息的消費者，有兩個主要的consumer:DefaultMQPullConsumer和DefaultMQPushConsumer，深入代碼后可以發現，rocket的consumer都是采用的pull模式來處理消息的。在集群消息的配置下，集群內各個服務平均分配消息，當其中一台consumer宕機，分配給它的消息會繼續分配給其它的consumer。
核心特性
1.讀隊列數量和寫隊列數量可以不一致：當我們使用updateTopic命令創建topic時，會發現新建的topic下會有默認的8個寫對列和8個讀對列(依賴於配置)，並且讀隊列的數量和寫隊列的數量還可以不一致，這是為什么呢？難道在底層讀寫隊列是在物理上分離的嗎？抱着這個問題，我分析了相關的源代碼，發現底層代碼對於讀寫隊列指的都是同一個隊列，其中寫隊列的數量是針對的producer，讀隊列的數量針對的是consumer：
a.假設寫隊列有8個、讀隊列有4個，那么producer產生的消息會按輪訓的方式寫入到8個隊列中，但是consumer卻只能消費前4個隊列，只有把讀隊列重新設置為8后，consumer可以繼續消費后4個隊列的歷史消息；
b.假設寫隊列有4個、讀隊列有8個，那么producer產生的消息會按輪訓的方式寫入到4個隊列中，但是consumer卻能消費8個隊列，只是后4個隊列沒有消息可以消費罷了。
2.存儲為文件存儲方式，支持同步落盤和異步刷盤兩種方式，我傾向於選擇異步刷盤的方式，畢竟broker掛掉的概率比較小，大部分的業務場景下在極端情況下丟失及其少量消息是可以忍受的；
3.支持消息回溯，支持定期刪除歷史消息；
4.集群方案比activemq要優秀很多，支持多主多從方案，例如在2主2從異步架構下，a,b為master,as,bs為slaver，當a機宕機后，producer會將消息全部發往b機，consumer會消費as，b和bs上的消息，理論上只會丟失毫秒級別的消息，不會影響業務的正常使用。可以說rocketmq的集群方案完爆activemq的集群方案，很多時候，我們對於異步隊列的性能要求不高，但是集群的可用性要求一定是很高的。下面是activemq的三種集群方案：
a.磁盤陣列類，成本較高，也是一種通用的方案；
b.利用jdbc來實現統一存儲消息，不但性能成問題，而且也只是把問題丟給了數據庫罷了，沒有解決集群的單機問題；
c.利用zookeeper的注冊中心的選主功能，在各個服務之間同步數據，在實際的使用過程中發現主機自動漂移，同步數據不完全造成的數據錯亂且服務啟動不了，反而不如單機來的穩定；
5.隊列數量單機支持10000個以上；
6.consumer支持集群功能，可以平均消費消息，當有一台consumer宕機后，其它consumer繼續均分；
7.consumer是靠pull的方式來消費消息的，性能不低於push的方式，這也是broker的並行能力強的一個原因，將主動權下放給了consumer，降低了broker的運算量和線程切換成本；
8.支持順序消息，可以在發送消息時，利用selector機制的hash方式取模來實現消息落到哪個broker的哪個queue上，當某個broker宕機后，由於取模值也發生變化，會自動切換隊列；
9.producer發送消息時支持同步返回、異步返回和oneway三種方式；
10.broker保證每條消息至少投遞到consumer一次，因此consumer的業務需要支持冪等；
11.消息堆積能力驚人，消息隊列的一個作用便是防止洪峰直接沖垮后端業務；
12.支持按照消息id和消息key來查詢消息，本人很喜歡按照key來查詢消息這個功能，例如在下單業務中，可以使用訂單id作為key，便於分析異常訂單在系統中的處理過程；
13.支持消息過濾；
...