前言
我們在工作中經常會用到非同步訊息，主要使用兩種訊息模式：
- 訊息佇列
- 釋出/訂閱
訊息佇列：多個生產者可以向同一個訊息佇列傳送訊息，但是一個訊息只能被一個消費者消費。
釋出/訂閱：一個訊息可以被多個訂閱者併發的獲取和處理。
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。
小結
本文純屬拋磚引玉，有問題，歡迎批評指正。
希望在兩者的使用選擇上能夠給你帶來一些思路。