Apache RocketMQ是一個分佈式消息和流式數據處理平臺,具備低延遲,高性能和高可靠性等特性。 其官方網站上的介紹有如下特色:編程
如上圖所示,它由四部分組成:名稱服務器,代理服務器,生產者和消費者。它們中的每個均可以水平擴展,而不會出現單點故障。服務器
名稱服務器集羣網絡
名稱服務器提供輕量級服務發現和路由。每一個名稱服務器記錄完整的路由信息,提供相應的讀寫服務,支持快速的存儲擴展。架構
代理集羣異步
代理關注的是消息存儲,它經過提供輕量級主題和隊列機制來處理消息存儲,他們支持推,拉模型,包含容錯機制(容許2個副本或3個副本),可以抵禦強峯值,而且按序積壓千億條消息的的功能。此外,代理還提供容災,豐富的度量統計數據和報警機制,這些都是傳統消息系統所缺乏的。分佈式
生產者集羣工具
生產者支持分佈式部署,分佈式生產者經過多種負載平衡模式向代理集羣發送消息,發送進程支持快速故障和低延遲。post
消費者集羣性能
消費者集羣也支持推拉模式中的分佈式部署。它還支持集羣消息和消息廣播。它提供了實時消息訂閱機制,能夠知足大多數用戶的需求。大數據
名稱服務器是一個功能齊全的服務器,主要包含該兩個功能:
代理服務器負責消息存儲和傳遞,消息查詢,高可用保證等。
以下圖所示, 代理服務器有幾個重要的子模塊:
如何快速上手RocketMQ,將其服務搭建在本地計算機中,請看這裏
RocketMQ事務性消息中是如何設計的請看這裏
爲何RocketMQ可以支持更多的隊列?請看這裏
在早期階段,阿里構建了基於ActiveMQ5.x(早於5.3)的分佈式消息中間件。使用它進行異步通訊,搜索,社交網絡活動流,數據管道,甚至在交易中使用。隨着業務吞吐量增長,來自消息系統集羣的壓力也變得緊迫。
隨着隊列的增長和虛擬主題的使用,ActiceMQ IO模塊遇到了瓶頸。儘管經過節流。斷路或退化來解決這個問題,可是效果並很差。阿里開始關注流行的消息傳遞解決方案Kafka。不幸的是,Kafka不能知足他們的要求,特別是在低延遲和高可靠性方面。
下面的表中是RocketMQ,ActiveMQ和Kafka解決方案的比較。
比較項目 | ActiveMQ | Kafka | RocketMQ |
---|---|---|---|
客戶端SDK | Java, .NET, C++ etc. | Java, Scala etc. | Java, C++, Go |
協議和規範 | 推送模型, 支持OpenWire,STOMP, AMQP, MQTT, JMS | 推送模型, 支持TCP協議 | 推送模型,支TCP,JMS, 開放消息 |
順序消息 | 專有消費者或專有隊列 | 確保分區內的消息的順序 | 確保嚴格的消息順序,並能優雅的擴展 |
定時消息 | 支持 | 不支持 | 支持 |
批量消息 | 不支持. | 支持,異步生產 | 支持,使用同步的模式以免消息丟失 |
廣播消息 | 支持 | 不支持 | 支持 |
消息過濾 | 支持 | 支持, 可使用Kafka流來篩選消息 | 支持,基於SQL92的屬性篩選表達式 |
服務器端觸發的重試 | 不支持 | 不支持 | 支持 |
消息存儲 | 支持使用JDB和高性能日誌(如LEVELDB, KAHADB) 快速持久化 | 高性能問價存儲 | 高性能和低延遲文件存儲 |
消息可追溯 | 支持 | 支持 | 支持,時間戳和偏移量 |
消息優先級 | 支持 | 不支持 | 不支持 |
高可用和災備 | 支持,根據存儲狀況,若是使用kahad, 則須要一個ZooKeeper服務器 | 支持,須要ZooKeeper服務 | |
消息追蹤 | 不支持 | 不支持 | 主從模型.不帶有其餘套件 |
配置 | 默認配置爲低級別,用戶須要優化配置參數 | Kafk經過配置key value的形式在配置文件中進行配置,也支持編程方式配置. | 支持 |
管理和操做工具 | 支持 | 支持,經過終端命令能夠進行配置 | 開箱即用, 用戶只須要注意一些配置 |