RocketMQ作為一款分布式的消息中間件（阿里的說法是不遵循任何規(guī)范的，所以不能完全用JMS的那一套東西來看它），經(jīng)歷了Metaq1.x、Metaq2.x的發(fā)展和淘寶雙十一的洗禮，在功能和性能上遠超ActiveMQ。
1.要知道RocketMQ原生就是支持分布式的，而ActiveMQ原生存在單點性。
2.RocketMQ可以保證嚴格的消息順序，而ActiveMQ無法保證！
3.RocketMQ提供億級消息的堆積能力，這不是重點，重點是堆積了億級的消息后，依然保持寫入低延遲！
4.豐富的消息拉取模式（Push or Pull）
Push好理解，比如在消費者端設置Listener回調(diào)；而Pull，控制權(quán)在于應用，即應用需要主動的調(diào)用拉消息方法從Broker獲取消息，這里面存在一個消費位置記錄的問題（如果不記錄，會導致消息重復消費）。
5.在Metaq1.x/2.x的版本中，分布式協(xié)調(diào)采用的是Zookeeper，而RocketMQ自己實現(xiàn)了一個NameServer，更加輕量級，性能更好！
6.消息失敗重試機制、高效的訂閱者水平擴展能力、強大的API、事務機制等等（后續(xù)詳細介紹）
初步理解Producer/Consumer Group
ActiveMQ中并沒有Group這個概念，而在RocketMQ中理解Group的機制很重要。
Group機制
想過沒有，通過Group機制，讓RocketMQ天然的支持消息負載均衡！
比如某個Topic有9條消息，其中一個Consumer Group有3個實例（3個進程 OR 3臺機器），那么每個實例將均攤3條消息！（注意RocketMQ只有一種模式，即發(fā)布訂閱模式。）
http://rocketmq.apache.org/docs/quick-start/
Quick Start
This quick start guide is a detailed instruction of setting up RocketMQ messaging system on your local machine to send and receive messages.
The following softwares are assumed installed:
64bit OS, Linux/Unix/Mac is recommended;
64bit JDK 1.8+;
Maven 3.2.x
Git
Clone & Build
> git clone -b develop https://github.com/apache/incubator-rocketmq.git
> cd incubator-rocketmq
> mvn -Prelease-all -DskipTests clean install -U
> cd distribution/target/apache-rocketmq
Start Name Server
> nohup sh bin/mqnamesrv &
> tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
Start Broker
> nohup sh bin/mqbroker -n localhost:9876 &
> tail -f ~/logs/rocketmqlogs/broker.log
The broker[%s, 172.30.30.233:10911] boot success...
Send & Receive Messages
Before sending/receiving messages, we need to tell clients the location of name servers. RocketMQ provides multiple ways to achieve this. For simplicity, we use environment variable NAMESRV_ADDR
> export NAMESRV_ADDR=localhost:9876
> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer
SendResult [sendStatus=SEND_OK, msgId= ...
> sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer
ConsumeMessageThread_%d Receive New Messages: [MessageExt...
Shutdown Servers
> sh bin/mqshutdown broker
The mqbroker(36695) is running...
Send shutdown request to mqbroker(36695) OK
> sh bin/mqshutdown namesrv
The mqnamesrv(36664) is running...
Send shutdown request to mqnamesrv(36664) OK
轉(zhuǎn)自：https://github.com/alibaba/RocketMQ/wiki/rmq_vs_kafka
淘寶內(nèi)部的交易系統(tǒng)使用了淘寶自主研發(fā)的Notify消息中間件，使用Mysql作為消息存儲媒介，可完全水平擴容，為了進一步降低成本，我們認為存儲部分可以進一步優(yōu)化，2011年初，Linkin開源了Kafka這個優(yōu)秀的消息中間件，淘寶中間件團隊在對Kafka做過充分Review之后，Kafka無限消息堆積，高效的持久化速度吸引了我們，但是同時發(fā)現(xiàn)這個消息系統(tǒng)主要定位于日志傳輸，對于使用在淘寶交易、訂單、充值等場景下還有諸多特性不滿足，為此我們重新用Java語言編寫了RocketMQ，定位于非日志的可靠消息傳輸（日志場景也OK），目前RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理，binglog分發(fā)等場景。
為了方便大家選型，整理一份RocketMQ與Kafka的對比文檔，文中如有錯誤之處，歡迎來函指正。vintage.wang@gmail.com
數(shù)據(jù)可靠性
RocketMQ支持異步實時刷盤，同步刷盤，同步Replication，異步Replication
Kafka使用異步刷盤方式，異步Replication
總結(jié)：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因為操作系統(tǒng)Crash，導致數(shù)據(jù)丟失。 同時同步Replication也比Kafka異步Replication更可靠，數(shù)據(jù)完全無單點。另外Kafka的Replication以topic為單位，支持主機宕機，備機自動切換，但是這里有個問題，由于是異步Replication，那么切換后會有數(shù)據(jù)丟失，同時Leader如果重啟后，會與已經(jīng)存在的Leader產(chǎn)生數(shù)據(jù)沖突。開源版本的RocketMQ不支持Master宕機，Slave自動切換為Master，阿里云版本的RocketMQ支持自動切換特性。
性能對比
Kafka單機寫入TPS約在百萬條/秒，消息大小10個字節(jié)
RocketMQ單機寫入TPS單實例約7萬條/秒，單機部署3個Broker，可以跑到最高12萬條/秒，消息大小10個字節(jié)
總結(jié)：Kafka的TPS跑到單機百萬，主要是由于Producer端將多個小消息合并，批量發(fā)向Broker。
RocketMQ為什么沒有這么做？
Producer通常使用Java語言，緩存過多消息，GC是個很嚴重的問題
Producer調(diào)用發(fā)送消息接口，消息未發(fā)送到Broker，向業(yè)務返回成功，此時Producer宕機，會導致消息丟失，業(yè)務出錯
Producer通常為分布式系統(tǒng)，且每臺機器都是多線程發(fā)送，我們認為線上的系統(tǒng)單個Producer每秒產(chǎn)生的數(shù)據(jù)量有限，不可能上萬。
緩存的功能完全可以由上層業(yè)務完成。
單機支持的隊列數(shù)
Kafka單機超過64個隊列/分區(qū)，Load會發(fā)生明顯的飆高現(xiàn)象，隊列越多，load越高，發(fā)送消息響應時間變長
RocketMQ單機支持最高5萬個隊列，Load不會發(fā)生明顯變化
隊列多有什么好處？
單機可以創(chuàng)建更多Topic，因為每個Topic都是由一批隊列組成
Consumer的集群規(guī)模和隊列數(shù)成正比，隊列越多，Consumer集群可以越大
消息投遞實時性
Kafka使用短輪詢方式，實時性取決于輪詢間隔時間
RocketMQ使用長輪詢，同Push方式實時性一致，消息的投遞延時通常在幾個毫秒。
消費失敗重試
Kafka消費失敗不支持重試
RocketMQ消費失敗支持定時重試，每次重試間隔時間順延
總結(jié)：例如充值類應用，當前時刻調(diào)用運營商網(wǎng)關，充值失敗，可能是對方壓力過多，稍后在調(diào)用就會成功，如支付寶到銀行扣款也是類似需求。
這里的重試需要可靠的重試，即失敗重試的消息不因為Consumer宕機導致丟失。
嚴格的消息順序
Kafka支持消息順序，但是一臺Broker宕機后，就會產(chǎn)生消息亂序
RocketMQ支持嚴格的消息順序，在順序消息場景下，一臺Broker宕機后，發(fā)送消息會失敗，但是不會亂序
Mysql Binlog分發(fā)需要嚴格的消息順序
定時消息
Kafka不支持定時消息
RocketMQ支持兩類定時消息
開源版本RocketMQ僅支持定時Level
阿里云ONS支持定時Level，以及指定的毫秒級別的延時時間
分布式事務消息
Kafka不支持分布式事務消息
阿里云ONS支持分布式定時消息，未來開源版本的RocketMQ也有計劃支持分布式事務消息
消息查詢
Kafka不支持消息查詢
RocketMQ支持根據(jù)Message Id查詢消息，也支持根據(jù)消息內(nèi)容查詢消息（發(fā)送消息時指定一個Message Key，任意字符串，例如指定為訂單Id）
總結(jié)：消息查詢對于定位消息丟失問題非常有幫助，例如某個訂單處理失敗，是消息沒收到還是收到處理出錯了。
消息回溯
Kafka理論上可以按照Offset來回溯消息
RocketMQ支持按照時間來回溯消息，精度毫秒，例如從一天之前的某時某分某秒開始重新消費消息
總結(jié)：典型業(yè)務場景如consumer做訂單分析，但是由于程序邏輯或者依賴的系統(tǒng)發(fā)生故障等原因，導致今天消費的消息全部無效，需要重新從昨天零點開始消費，那么以時間為起點的消息重放功能對于業(yè)務非常有幫助。
消費并行度
Kafka的消費并行度依賴Topic配置的分區(qū)數(shù)，如分區(qū)數(shù)為10，那么最多10臺機器來并行消費（每臺機器只能開啟一個線程），或者一臺機器消費（10個線程并行消費）。即消費并行度和分區(qū)數(shù)一致。
RocketMQ消費并行度分兩種情況
順序消費方式并行度同Kafka完全一致
亂序方式并行度取決于Consumer的線程數(shù)，如Topic配置10個隊列，10臺機器消費，每臺機器100個線程，那么并行度為1000。
消息軌跡
Kafka不支持消息軌跡
阿里云ONS支持消息軌跡
開發(fā)語言友好性
Kafka采用Scala編寫
RocketMQ采用Java語言編寫
Broker端消息過濾
Kafka不支持Broker端的消息過濾
RocketMQ支持兩種Broker端消息過濾方式
根據(jù)Message Tag來過濾，相當于子topic概念
向服務器上傳一段Java代碼，可以對消息做任意形式的過濾，甚至可以做Message Body的過濾拆分。
消息堆積能力
理論上Kafka要比RocketMQ的堆積能力更強，不過RocketMQ單機也可以支持億級的消息堆積能力，我們認為這個堆積能力已經(jīng)完全可以滿足業(yè)務需求。
開源社區(qū)活躍度
Kafka社區(qū)更新較慢
RocketMQ的github社區(qū)有250個 個人、公司用戶登記了聯(lián)系方式，QQ群超過1000人。
商業(yè)支持
Kafka原開發(fā)團隊成立新公司，目前暫沒有相關產(chǎn)品看到
RocketMQ在阿里云上已經(jīng)開放公測近半年，目前以云服務形式免費供大家商用，并向用戶承諾99.99%的可靠性，同時徹底解決了用戶自己搭建MQ產(chǎn)品的運維復雜性問題
成熟度
Kafka在日志領域比較成熟
RocketMQ在阿里集團內(nèi)部有大量的應用在使用，每天都產(chǎn)生海量的消息，并且順利支持了多次天貓雙十一海量消息考驗，是數(shù)據(jù)削峰填谷的利器。
