上一篇部落格主要是介紹了MQ，從這篇開始，步入正題，也就是RocketMQ。阿里巴巴有2大核心的分散式技術，一個是OceanBase，另一個就是RocketMQ。之前專案用過ActiveMQ，不論成熟度還是廣泛度，ActiveMQ絕對是彪悍致極。而最近的專案，用的是RocketMQ，有種非一般的體驗。

What is RocketMQ?

RocketMQ作為一款純java、分散式、佇列模型的開源訊息中介軟體（阿里的說法是不遵循任何規範的，所以不能完全用JMS的那一套東西來看它），經歷了淘寶雙十一的洗禮，在功能和效能上據說是遠超ActiveMQ。

Where is RocketMQ from?

RocketMQ的是如何發而來的，也就是三個主要版本迭代：

1. Metaq(Metamorphosis) 1.x

2. Metaq 2.x

於2012年10月份上線，在淘寶內部被廣泛使用。

3. RocketMQ 3.x

Metaq 3.0釋出時，產品名稱改為RocketMQ。基於公司內部開源共建原則，RocketMQ專案只維護核心功能，且去除了所有其他執行時的依賴，核心功能最簡化。每個BU的個性化需求都在RocketMQ專案之上進行深度定製。RocketMQ向其他BU提供的僅僅是jar包，例如要定製一個Broker，那麼只需要依賴rocketmq-broker這個jar包即可，可通過API進行互動，如果定製client,則依賴rocketmq-client這個jar包，對其提供的api進行再封裝。

How is RocketMQ?

下面簡單列舉一下RocketMQ的幾大特性：

• 原生分散式

要知道RocketMQ原生就是支援分散式的，而ActiveMQ原生存在單點性。

• 嚴格訊息順序

RocketMQ可以保證嚴格的訊息順序，而ActiveMQ無法保證！

• 億級訊息堆積

RocketMQ提供億級訊息的堆積能力，這不是重點，重點是堆積了億級的訊息後，依然保持寫入低延遲！

• 兩種訊息拉取

兩種的訊息拉取模式（Push or Pull）。
Push好理解，比如在消費者端設定Listener回撥；而Pull，控制權在於應用，即應用需要主動的呼叫拉訊息方法從Broker獲取訊息，這裡面存在一個消費位置記錄的問題（如果不記錄，會導致訊息重複消費）。

• 特有的分散式協調器

在Metaq1.x/2.x的版本中，分散式協調採用的是Zookeeper，而RocketMQ自己實現了一個NameServer，更加輕量級，效能更好！

• 組（Group）

有了Producer/Consumer Group。
ActiveMQ中並沒有Group這個概念，而在RocketMQ中理解Group的機制很重要。想過沒有，通過Group機制，讓RocketMQ天然的支援訊息負載均衡！比如某個Topic有9條訊息，其中一個Consumer Group有3個例項（3個程序 OR 3臺機器），那麼每個例項將均攤3條訊息！（注意RocketMQ只有一種模式，即釋出訂閱模式。）

• 其他

訊息失敗重試機制、高效的訂閱者水平擴充套件能力、強大的API、事務機制等等（後續詳細介紹）

這裡只作簡述，具體的可參考《RocketMQ 開發指南》這份文件資料。