為何選擇 RocketMQ
為何選擇 RocketMQ
在 RocketMQ 於阿里巴巴開發的早期階段，我們將其用於多種用途，包括非同步通訊、搜尋、社群網路活動流程、資料管線和交易流程。隨著我們的交易業務成長，我們注意到訊息叢集承受的壓力越來越大。
在觀察和分析 ActiveMQ IO 模組的效能後，我們發現隨著佇列和虛擬主題的增加，瓶頸也隨之增加。我們嘗試透過各種方法來解決這個問題，例如節流、斷路器和服務降級，但都沒有令人滿意的結果。我們也考慮使用 Kafka，這是一個流行的訊息解決方案，但它不符合我們對低延遲和高可靠性的需求，如下所述。因此，我們決定開發一個新的訊息引擎，能夠處理更廣泛的用例，從傳統的發布/訂閱到大量、即時、零錯誤的交易系統。
自推出以來，Apache RocketMQ 因其簡單的架構、豐富的業務功能和極高的可擴充性而被企業開發人員和雲端供應商廣泛採用。經過十多年的廣泛場景驗證，RocketMQ 已成為金融級可靠業務訊息的業界標準，並廣泛用於網際網路、大數據、行動網際網路、物聯網和其他領域。
提示
下表顯示 RocketMQ、ActiveMQ 和 Kafka 之間的比較
RocketMQ vs. ActiveMQ vs. Kafka
| 訊息產品 | 用戶端 SDK | 通訊協定和規格 | 已排序訊息 | 已排程訊息 | 批次訊息 | 廣播訊息 | 訊息篩選 | 伺服器觸發重新傳送 | 訊息儲存 | 訊息追溯 | 訊息優先順序 | 高可用性和故障轉移 | 訊息追蹤 | 組態 | 管理和操作工具 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ActiveMQ | Java、.NET、C++ 等 | 推送模式，支援 OpenWire、STOMP、AMQP、MQTT、JMS | 獨佔消費者或獨佔佇列可以確保排序 | 支援 | 不支援 | 支援 | 支援 | 不支援 | 支援使用 JDBC 以及高性能日誌（例如 levelDB、kahaDB）進行非常快速的持久性 | 支援 | 支援 | 支援，視儲存而定，如果使用 levelDB，則需要 ZooKeeper 伺服器 | 不支援 | 預設組態為低階，使用者需要最佳化組態參數 | 支援 |
| Kafka | Java、Scala 等 | 拉取模式，支援 TCP | 確保分區內訊息的排序 | 不支援 | 支援，使用非同步產生器 | 不支援 | 支援，可以使用 Kafka Streams 篩選訊息 | 不支援 | 高性能檔案儲存 | 支援偏移量指示 | 不支援 | 支援，需要 ZooKeeper 伺服器 | 不支援 | Kafka 使用鍵值對格式進行組態。這些值可以從檔案或以程式方式提供。 | 支援，使用終端機指令公開核心指標 |
| RocketMQ | Java、C++、Go | 拉取模式，支援 TCP、JMS、OpenMessaging | 確保訊息的嚴格排序，並且可以優雅地擴充 | 支援 | 支援，使用同步模式以避免訊息遺失 | 支援 | 支援，基於 SQL92 的屬性篩選表達式 | 支援 | 高性能且低延遲的文件儲存 | 支援時間戳記和偏移量兩個指標 | 不支援 | 支援，主從模式，無需其他套件 | 支援 | 開箱即用，使用者只需要注意一些設定 | 支援，豐富的 Web 和終端命令來公開核心指標 |