幾款消息中間的調研（轉）

消息隊列調研

消息系統簡介

本次主要調研業界使用普遍的兩款消息隊列——RabbitMQ, Kafka， 以及阿里雲的提供的兩個服務， MNS和ONS.

RabbitMQ

RabbitMQ 是使用Erlang編寫的一個開源的消息隊列，自己支持不少的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它很是重量級，更適合於企業級的開發。同時實現了Broker構架，這意味着消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

阿里雲MNS

• MNS產品介紹

阿里雲消息服務（Message Service，原MQS）是阿里雲惟一商用的消息中間件服務。與傳統的消息中間件不一樣，消息服務一開始就是基於阿里雲自主研發的飛天分佈式系統來設計和實現，具備大規模，高可靠、高併發訪問和超強消息堆積能力的特色。消息服務API採用HTTP RESTful標準，接入方便，跨網絡能力強；已全面接入資源訪問控制服務（RAM）、專有網絡（VPC），支持各類安全訪問控制；接入雲監控，提供完善的監控及報警機制。消息服務提供豐富的SDK、解決方案、最佳實踐和7x24小時的技術支持，幫助應用開發者在應用組件之間自由地傳遞數據和構建鬆耦合、分佈式、高可用系統。

阿里雲ONS / RocketMQ

• ONS產品介紹
• ONS開源社區對應產品——RocketMQ

消息隊列（Message Queue，簡稱MQ）是企業級互聯網架構的核心服務，基於高可用分佈式集羣技術，搭建了包括髮布訂閱、接入、管理、監控報警等一套完整的高性能消息雲服務，幫您實現分佈式計算場景中全部異步解耦功能。通過多年積累，在交易、商品、營銷等核心鏈路包括在雙11場景下都有普遍使用，服務於阿里內部上千個核心應用，天天消息量達上千億條，MQ由阿里巴巴集團中間件技術部自主研發，是原汁原味的阿里集團中間件技術精華之沉澱。

Kafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式發佈/訂閱消息隊列系統。具備如下特性：快速持久化，能夠在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既能夠達到10W/s的吞吐速率；徹底的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現負載均衡.

Kafka的用戶中包括LinkedIn, Yahoo, Twitter, Uber, PayPal, Airbnb, Tumblr等, 被用於日誌收集， 離線分析， 實時分析, 消息管道等, 詳情見 Powerd By Kafka

Kafka官方提供了Java版本的客戶端API, Kafka社區產生了多種語言的客戶端, 包括PHP, Python, Go, C/C++, Ruby, NodeJS等, 詳情見 Kafka 客戶端列表

Kafka Broker較爲輕量, 不保存consumer的消費進度, 由consumer本身控制。 所以使用起來很是靈活， 能夠針對不一樣場景定製不一樣的消費服務.

• Exactly Once: 消費且僅消費一次
• 回溯數據, 進行重複消費

目前Kafka的管理界面不友好, 官方只給了命令行工具. 經過命令行工具能簡單地查看和操做Topic. Yahoo開源了本身的Kafka Web管理界面 Kafka-Manager, 但不支持最新的0.9.0版本的部分功能.

Kafka, RabbitMQ, MNS, ONS對比

–	Kafka	RabbitMQ	MNS	ONS
所屬社區/公司	Apache	Mozilla Public License	Alibaba	Alibaba
成熟度	成熟	成熟	成熟	比較成熟,公測中
特色	充分考慮消息堆積因素,認爲 consumer 不必定處於 alive 狀態;考慮各個角色的分佈式; 爲追求吞吐量設計;被多家公司和多個開源項目使用	因爲Erlang語言的併發能力，性能很好, 支持多種協議，重量級系統	消息服務API採用HTTP RESTful標準，接入方便，跨網絡能力強	高性能, 支持數據海量堆積, 支持主動推送
受權方式	開源	開源	商業	商業，有對應的開源項目RocketMQ
開發語言	Scala&Java	Erlang	Java	Java
客戶端支持語言	官方支持Java, 開源社區有多語言版本, 如PHP, Python, Go, C/C++, Ruby, NodeJS等編程語言, 詳見 Kafka 客戶端列表	官方支持Erlang, Java, Ruby等, 社區產出多種語言API，詳見RabbitMQ客戶端&開發工具	Java, C++, Python, C#, PHP, Node.js(非官方), Golang(非官方)	Java, C/C++, C#, PHP
協議支持	自有協議，社區封裝了HTTP協議支持	多協議支持:AMQP，XMPP, SMTP, STOMP	HTTP	ONS私有協議
消息批量操做	支持	不支持	支持	不支持
消息推拉模式	Pull	多協議, Pull/Push均有支持	Pull	Pull, Push
保證消息至少消費一次	默認保證	保證	在消息有效期內，確保消息至少能被成功消費一次。	不保證(消費失敗16次後丟棄)
消息回溯	支持	消費完即刪除, 不支持回溯	消費完即刪除, 不支持回溯	支持
HA	支持replica機制, leader宕掉後, 備份自動頂替， 並從新選舉leader(基於Zookeeper)	master/slave模式, master提供服務, slave僅做備份	–	–
數據可靠性	上週的測試中, 使用Kafka做爲消息中間件， 數據可靠， 而且有replica機制, 有容錯容災能力	能夠保證數據不丟, 有slave用做備份	數據三重備份, 可靠性達10個9 (官方數據)	99.99% (官方數據)
QPS	性能卓越, 詳見下文Linkedin團隊的測試	性能優秀， 詳見下文Linkedin團隊的測試	默認4000	默認5000
持久化能力	磁盤文件, 只要磁盤容量夠， 能夠作到無限消息堆積	內存、文件，支持數據堆積,但數據堆積反過來影響生產速率	消息持久化默認有期限, 支持海量堆積	ONS消息默認保留三天，支持海量堆積
是否有序	多Client保證有序	若想有序，只能使用一個Client	不保證有序	不保證有序
事務	不支持, 但能夠經過Low Level API保證僅消費一次	不支持	不支持	支持
集羣	支持	支持	支持	支持
負載均衡	支持	支持	支持	支持
管理界面	官方只提供了命令行版, Yahoo開源本身的Kafka Web管理界面Kafka-Manager	較好	好	好
部署方式	獨立	獨立	Aliyun提供服務	Aliyun提供服務,能夠獨立部署

總結

1. 事務支持方面，ONS/RocketMQ較爲優秀，可是不支持消息批量操做, 不保證消息至少被消費一次.
2. Kafka提供徹底分佈式架構, 並有replica機制, 擁有較高的可用性和可靠性, 理論上支持消息無限堆積, 支持批量操做, 消費者採用Pull方式獲取消息, 消息有序, 經過控制可以保證全部消息被消費且僅被消費一次. 可是官方提供的運維工具不友好，開源社區的運維工具支持的版本通常落後於最新版本的Kafka.
3. 目前使用的MNS服務，擁有HTTP REST API, 使用簡單, 數據可靠性高, 可是不保證消息有序，不能回溯數據.
4. RabbitMQ爲重量級消息系統， 支持多協議(不少協議是目前業務用不到的), 可是不支持回溯數據, master掛掉以後， 須要手動從slave恢復, 可用性略遜一籌.

附: LinkedIn團隊對Kafka, RabbitMQ, ActiveMQ的性能研究

生產者測試

LinkedIn團隊在全部系統中配置代理，異步將消息刷入其持久化庫。對每一個系統，運行一個生產者，總共發佈1000萬條消息，每條消息200字節。Kafka生產者以1和50批量方式發送消息。ActiveMQ和RabbitMQ彷佛沒有簡單的辦法來批量發送消息，LinkedIn假定它的批量值爲1。結果以下圖所示：

消費者測試

爲了作消費者測試，LinkedIn使用一個消費者獲取總共1000萬條消息。LinkedIn讓全部系統每次拉請求都預獲取大約相同數量的數據，最多1000條消息或者200KB。對ActiveMQ和RabbitMQ，LinkedIn設置消費者確認模型爲自動。結果以下圖所示