| 項目 | kafka | RabbitMQ |說明|
| -------- | -------- | -------- | -------- |
| 消息順序 | 可以保證順序 | 無法保證順序 |因為RabbitMQ處理訊息失敗後，會把消息丟回佇列之中，如果是多個消費者會無法保證順序，但如果只有單個消費者才可以保證順序|
|消息過濾|不可過濾,沒有異常情況下會接受一個分區中的所有消息|可以透過 routing_key 過濾特定路由消息|
|消息時序-TTL|Kafka 也沒用爲消息提供 TTL 的機制，不過我們可以在應用層實現|可以設定TTL | 可以TTL 來限制消息的有效期如果消費者在預期時間內沒有處理該消息，那麼這條消息會自動的從隊列上被移除|
|消息時序-延遲|立即執行|可以透過插件方式延遲或預訂消息;[延遲]生產者可以延遲 RabbitMQ 路由這個消息到消費者隊列的時間||
|消息時序-預定訊息|立即執行|[預定]允許開發者調度將來（future）的命令，也就是在那之前不應該被處理的命令。例如，當生產者遇到限流規則時，我們可能會把這些特定的命令延遲到之後的一個時間執行||
|消息留存|Kafka 會給每個主題配置超時時間，只要沒有達到超時時間的消息都會保留下來。在消息留存方面，Kafka 僅僅把它當做消息日誌來看待，並不關心消費者的消費狀態|當消費者成功消費消息之後，RabbitMQ 就會把對應的消息從存儲中刪除。這種行爲沒法修改|kafka 除非超過主題設定的超時時間不然都會保留訊息|
|容錯處理|需要自己在應用層提供和實現消息重試機制|如交付重試和死信交換器（DLX）來處理消息處理故障||
|效能|Kafka 使用順序磁盤 I / O 來提高性能(每秒百萬級別)|每秒十萬級別|Kafka 使用分區的架構上看，它在橫向擴展上會優於 RabbitMQ，當然 RabbitMQ 在縱向擴展上會有更多的優勢[但是每秒百萬級別的使用情況比較少（對一般使用者來說），所以通常一般使用者頂不到兩者上限]|
|消費者複雜度|傻瓜式代理和智能消費者模式[消費者組中的消費者需要協調他們之間的主題分區租約（以便一個具體的分區只由消費者組中一個消費者監聽）]|智能代理和傻瓜式消費者模式[消費者註冊到消費者隊列，然後 RabbitMQ 把傳進來的消息推送給消費者，管理消息的分發以及隊列上消息的移除（也可能轉移到 DLX）。消費者不需要考慮這塊。]||
|分區|隨着負載增加，我們只需要伸縮消費者組使其消費者的數量等於主題中分區的數量。這就需要我們配置 Kafka 增加額外的分區。但是，隨着負載再次降低，我們不能移除我們之前增加的分區 [但是這些問題可以透過Kafka SDK 處理] | RabbitMQ 結構的設計，當負載增加的時候，一個隊列上的消費者組可以有效的從僅僅一個消費者擴展到多個消費者，並且不需要對系統做任何的改變||

總結：
優先選擇 RabbitMQ 的條件：

高級靈活的路由規則；

消息時序控制（控制消息過期或者消息延遲）；

高級的容錯處理能力，在消費者更有可能處理消息不成功的情景中（瞬時或者持久）；

更簡單的消費者實現。

優先選擇 Kafka 的條件：

嚴格的消息順序；

延長消息留存時間，包括過去消息重放的可能；

傳統解決方案無法滿足的高伸縮能力。