訊息佇列MQ選型 - Kafka、RabbitMQ對比
阿新 • • 發佈：2018-11-29
image.png
適應場景
非同步處理，應用解耦，流量削鋒和訊息通訊
對比
| feature | scenario | Kafka | RabbitMQ | 備註 |
|---|---|---|---|---|
| PUB-SUB 釋出訂閱模型 | √ | √ | ||
| 推拉消費 | Consumer消費訊息的動作方式。 | pull | push/pull | push更關注實時性。pull更關注消費者消費能力。 |
| 延遲消費 | Producer產生一條訊息後，並不希望立刻被消費掉。 | X | √ | 高階需求。 |
| consumer group | 同一條Message能同時被多個消費組消費，但同一group中，一條Message只會被一個consumer消費 | √ | √ | KAFKA: 不需要在管理平臺配置。 RabbitMQ：增加需要配置，涉及到內部資料冗餘。 |
| 訊息tag(filter) | 以過濾出tag為keyword的message | X | X | |
| 訊息回溯 | 從歷史中的某個位置重新拉取訊息 | X | X | 只對拉模式，推模式不考慮回溯，支援時間維度offset |
| 事務性 | mq內部邏輯，訊息狀態是否一致 | X | √ | 和訊息中介軟體內部實現相關。 |
| 優先順序 | 訊息優先順序，consumer優先消費高優先順序訊息。 | X | √ | |
| 染色 | 追蹤訊息在mq中的具體耗時 | X | X | |
| 本地讀優化 | Producer\Consumer 不在同一機房。MQ搭建在P端，C端會存在跨機房訪問的問題。 | X | X | 使用資料同步工具，將P所在機房資料同步到C所在機房的叢集。 |
| doubt message(訊息追蹤) | 跨公司，異構系統間，訊息狀態追蹤。 | X | X | |
| 訊息積壓 | 沒有被消費的訊息在MQ中堆積 | √ | √ | 支援程度的區別，不同mq會存在不同。 |
| 負載均衡 | 1：防止單點 2：C端壓力LB在MQ各節點上。 | √ | √ | RMQ：多叢集做負載 |
| 支援的訊息大小 | 每條訊息的大小 | 無限制 | 無限制 | 需要對訊息大小做限制，降低系統不確定性。 |
| 定期回收訊息 | mq中的訊息一旦被消費後，可以被刪除，空間回收。 | √ | √ | |
| 消費語義 | 方式分別為：1、最多消費一次 2、最少消費一次3、僅消費一次 | 2 | 2 | 業務方消費端做冪等 |
| 對全域性序支援 | 訊息在全域性保持時序一致 | X | X | 設計複雜度原因，不考慮支援 |
備註：
“√” 表示目前系統已主持
“X” 表示系統不考慮支援該特性