RabbitMq與Kafka的比較

原文地址：http://www.quora.com/Which-one-is-better-for-durable-messaging-with-good-query-features-RabbitMQ-or-Kafka。

Kafka和RabbitMq同樣是通用意圖消息代理，他們都是以分佈式部署爲目的。可是他們對消息語義模型的定義的假設是很是不一樣的。我對"AMQP 更成熟"這個論點是持懷疑態度的。讓咱們用事實說話來看看用什麼解決方案來解決你的問題。

a) 如下場景你比較適合使用Kafka。你有大量的事件(10萬以上/秒)、你須要以分區的，順序的，至少傳遞成功一次到混雜了在線和打包消費的消費者、你但願能重讀消息、你能接受目前是有限的節點級別高可用或則說你並不介意經過論壇/IRC工具獲得還在幼兒階段的軟件的支持。

b) 如下場景你比較適合使用RabbitMQ。你有較少的事件（2萬以上/秒）而且須要經過複雜的路由邏輯去找到消費者、你但願消息傳遞是可靠的、你並不關心消息傳遞的順序、你須要如今就支持集羣-節點級別的高可用或則說你須要7*24小時的付費支持（固然也能夠經過論壇/IRC工具）。

他們並不支持複雜的「過濾/查詢」能力。若是你須要，能夠考慮在他們的上層使用Storm來進行過濾、計算、查詢。或則使用相似Cassandra做爲你的查詢緩存。Kafka雖然他已是生產版本，可是他並不成熟。

細節(警告-僅僅是個人意見，由於我並無很深刻的使用Kafka，而我對RabbitMQ更有經驗一些）。

首先Rabbit和Kafka的比較。他們都是很是棒的解決方案，RabbitMQ相對更成熟一點，但二者的設計了理念有很是大的不一樣。

從功能上講，我認爲RabbitMQ是以代理爲中心。它專一於生產者與消費者之間的傳遞保證,而且認爲消息的瞬時性優於持久性。

另外一方面 Kafka是以生產者爲中心，經過分區管道將事件數據轉爲帶有遊標的持久化信息代理。支持打包消費的離線消費者或則但願消息低延遲的在線消費者。

RabbitMQ讓代理本身維護消費狀態（經過消息確認機制）-它使用Erlang的Mnusia 在代理集羣進行傳遞狀態維護。

Kafka沒有消息確認機制，它目前是假設消費者跟蹤了什麼已經被消費。

Kafka的代理和消費者在集羣的模式下經過Zookeeper來可靠的維持他們的狀態。

RabbitMQ假設消費者老是在線的，而且不知道任何消息的「等待」(不管持續與否)（也就是說沒有遊標）。在RabbitMQ pre-2.0（2010）版本若是消費者過於緩慢將會掛掉。不過如今他支持在線和打包消費的消費者-不過一般來說顯然持續的大量消息放在代理中並不符合AMQP的主要設計思想。

Kafka一開始就基於打包消費的在線消費者而且支持生產數據進行打包的。它設計用來分佈保持大量數據卷。

RabbitMQ按照AMQP0.9.1的exchange標準提供豐富的路由能力。支持綁定和隊列化模型。

Kafka只有很是簡單的路由功能-在AMQP來講它僅僅使用話題進行交流。

兩種解決方案都是運行在分佈式集羣中。可是RabbitMQ的思想是集羣透明的，也就是說它是一個動態的代理。

Kafka則是集羣明確的，強制要求生產者知道它的話題的消息是分區到幾個節點中，這種思想的好處是提供一個分區內的有序遞交。這比RabbitMQ暴露出來的基本上是無序遞交來得更好（AMQP 0.9.1模型認爲「單生產通道、單交流、單隊列、單消費者通道」是有序遞交的必要條件）

另外一方面來講，Kafka假設生產者爲他們的時間表生成大量的事件流-沒有任何地方能夠對生產者進行節流。由於若是數據太龐大，消費者就會變慢。Kafka經過在事件洪水和指望用本身的方法去消費的消費者（有些是在線的，有些是平時離線，僅僅一個小時甚至一天一次進行打包消費）之間提供"減震器"。

Kafka能遞交「至少一次」每一個分區（爲了維持有序傳遞），就像RabbitMQ,不過是用了一個很是不一樣的方式。

從性能上來說，若是你須要有序的持久化消息傳遞，目前Kafka看起來沒有任何的競爭對手。《Kafka目前來講在綜合基準的性能條款上遠遠超過RabbitMQ.》這篇文章中使用雙節點集羣，每一個節點使用6-disk RAID 10的狀況下能夠達到每秒發佈50w條消息和每秒消費2.2w條消息。

http://research.microsoft.com/en...

固然它是LinkedIn的員工寫的，他並不須要時RabbitMQ的輸入專家，因此見仁見智吧。

最後提醒一下：Kafka是早期Apache的孵化項目，它並不必定像RabbitMQ那樣難學。

總而言之對於AMQP,坦白來說這個標準就是在亂來。

官方消息1.0提出的規範正在經過OASIS的標準流程。可是在使用來講，它是一個拆分的標準，0.9.1收到廠商所支持而1.0受到工做組的支持。一組通用，普適，產品質量並被主流產品（Redhat的Qpid,RabbitMQ..)所實現的AMQP1.0在2016年之前不會出現，若是它還會出現的話。

做爲一個沒有內部消息的外部觀察者來講，它是這個樣子的：

工做組在一個規範上用了5年的時間，迎來了一個高潮，一個普適的版本發佈（0.9.1)。而後一堆更強大的工做組成員在2011年重訂了標準，婉轉的將標準的重心從消息模型轉移到了傳輸協議（有點像TCP++)，並聲稱它是1.0。所以，咱們就看到了一個奇怪的事情，「成熟的」AMQP標準是非標準版的0.9.1,而「非成熟的」AMQP標準是標準版的1.0.

這並非說1.0不是一個好的技術，他基本上來講是一個好的技術，可是1.0比起AMQP在其的發佈生涯中試圖作到的標準來講低級了不少。而且據我所知，除了它本身的原型和一個GA實現(IIT SwiftMQ)之外並無被普遍的支持。RabbitMQ人有一個原型是在1.0之上加了0.9.1的模型層，可是並無被提交一個GA時間表。

因此，個人意見是，AMQP丟棄了不少他們的亮點,而且通過了這麼多年有充分的證據代表它在各個巨星中是能夠互相操做的。政治拖延了官方標準而且將對它的質疑獲得了普遍的支持。

在積極一面，你能夠爭論說AMQP已經成功的實現了它的目標。到2007年左右，打破了只有TIBCO能提供高性能，低延遲消息的局面。如今有許多的選項。我敢打賭，你選擇使用代理而不是期望在幾年內出現完好陷的交互（若是有的話)