現在的系統已經離不開消息隊列，我們可以用他做異步，做解耦，做流處理，做可靠傳輸。市面上的消息隊列也有很多，比如阿里雲的oss，RocketMQ，ZeroMQ，RabbitMQ，Kafka等，甚至Java中的List也可以稱爲一個簡單的消息隊列，種類如此繁多，我們該如何選擇呢？現在主流的消息隊列可以分爲兩類，一類以kafka爲代表，一類以RabbitMQ爲代表，二者有很多相似的地方，也都有各自的優勢。
那我們平時構建系統的時候，該選擇哪種消息隊列呢？這裏我們將RbbitMQ與kafka做一下對比（因爲他們都是spring默認集成的消息隊列），以便於我們做出最優的選擇。
二者概述
RabbitMQ：關於rabbit的詳細介紹這裏不說，感興趣的可以看我之前的文章，一句話rabbit作爲傳統意義上的消息隊列，基於AMQP協議開發，傾向於做按各種規則的消息轉發。
Kafka：關於kafka的詳細介紹會在以後的文章裏寫，因爲剛開始用，想深入瞭解後再寫出來。kafka更傾向於一個流式管道的概念，消息從一處流向另一處，吞吐量比rabbit更高。
接下來通過倆張圖來理解他倆的設計與區別。
首先來看rabbit，他通過broker來進行統一調配消息去向，生產者通過指定的規則將消息發送到broker，broker再按照規則發送給消費者進行消費，消費者方可以選擇消費方式爲pull或者是broker主動push，支持的消費模式也有多種，點對點，廣播，正則匹配等。
Kafka主要爲高吞吐量的訂閱發佈系統而設計，主要追求速度與持久化。kafka中的消息由鍵、值、時間戳組成，kafka不記錄每個消息被誰使用，只通過偏移量記錄哪些消息是未讀的，kafka中可以指定消費組來實現訂閱發佈的功能。
適用場景
瞭解了二者大體的區別以後，我們再來看具體的適用場景。
Kafka：
1.從A系統到B系統的消息沒有複雜的傳遞規則，並且具有較高的吞吐量要求。
2.需要訪問消息的歷史記錄的場景，因爲kafak是持久化消息的，所以可以通過偏移量訪問到那些已經被消費的消息（前提是磁盤空間足夠，kafka沒有將日誌文件刪除）
3.流處理的場景。處理源源不斷的流式消息，比較典型的是日誌的例子，將系統中源源不斷生成的日誌發送到kafka中。
rabbit：
1.需要對消息進行更加細粒度的控制，包括一些可靠性方面的特性，比如死信隊列。
2.需要多種消費模式（點對點，廣播，訂閱發佈等）
3.消息需要通過複雜的路由到消費者。
性能
最後是關於性能方面，衆所周知，kafka的吞吐量優於rabbit，大約是100k/sec，而rabbit大約是20k/sec，但是這個不應該成爲我們選擇的主要原因，因爲性能方面的瓶頸都是可以通過集羣方案來解決的。
最後要說的是，沒有最好的隊列，只有最合適的隊列。
參考：Understanding When to use RabbitMQ or Apache Kafka