前言
我們在工作中經常會用到異步消息，主要使用兩種消息模式：
- 消息隊列
- 發布/訂閱
消息隊列：多個生產者可以向同一個消息隊列發送消息，但是一個消息只能被一個消費者消費。
發布/訂閱：一個消息可以被多個訂閱者並發的獲取和處理。
Kafka 和 RabbitMQ 都能滿足如上的特性，那么我們應該如何選擇使用哪一個？這兩個 MQ 有什么差異性？在什么樣的場景下適合使用 Kafka，什么場景下適合使用 RabbitMQ ？你是否有這樣的疑惑？希望這篇文章能夠幫助到你。
如何選擇？
開發語言
Kafka：Scala，支持自定義的協議。
RabbitMQ：Erlang，支持 AMQP、MQTT、STOMP 等協議。
延遲隊列
如果你有以下這樣的需求場景：
- 生成訂單 60 秒后，給用戶發短信。
- 用戶 7 天未登錄給用戶做召回推送。
- 下單 15 分鍾后，未進行付款就關閉訂單。
請選擇 RabbitMQ，官方已提供延遲隊列插件（x-delayed-message），開箱即用。
消息順序性
如果你的需求場景是需要保證消息是有序的，例如：傳遞的消息是 MySQL binlog，這種消息不允許是錯亂的。
請選擇 Kafka，它能夠保證發送到相同主題分區的所有消息都能夠按照順序處理。
優先級隊列
如果你的需求場景是需要保證消息執行的優先級，例如：首先需要處理 VIP 客戶的問題，然后再處理普通客戶的問題。
請選擇 RabbitMQ，創建隊列時可設置 x-max-priority。
消息留存
如果你的需求場景是消費后的消息不馬上刪除而是希望能夠多保留一段時間。
請選擇 Kafka，它能夠給每個主題配置超時時間，只要沒有達到超時時間的消息都會保留下來，請放心 Kafka 的性能不依賴於存儲大小，理論上它存儲消息幾乎不會影響性能。
消息過濾
如果你的需求場景是對接收的消息采取一定的過濾規則進行過濾。
請選擇 RabbitMQ，因為它支持消息路由。不過對於 Kafka 而言，也可以通過其他方式實現。
可伸縮行
如果你的需求場景是對伸縮方面、吞吐量方面有極大的要求。
請選擇 Kafka。
小結
本文純屬拋磚引玉，有問題，歡迎批評指正。
希望在兩者的使用選擇上能夠給你帶來一些思路。