RabbitMQ和kafka從幾個角度簡單的對比--轉

業界對於消息的傳遞有多種方案和產品，本文就比較有表明性的兩個MQ(rabbitMQ,kafka)進行闡述和作簡單的對比，

在應用場景方面，

RabbitMQ,遵循AMQP協議，由內在高併發的erlanng語言開發，用在實時的對可靠性要求比較高的消息傳遞上。

kafka是Linkedin於2010年12月份開源的消息發佈訂閱系統,它主要用於處理活躍的流式數據,大數據量的數據處理上。

1)在架構模型方面，

RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer經過鏈接channel和server進行通訊，Consumer從queue獲取消息進行消費（長鏈接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker爲中心；有消息的確認機制。

kafka聽從通常的MQ結構，producer，broker，consumer，以consumer爲中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。

2)在吞吐量，

kafka具備高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操做，具備O(1)的複雜度，消息處理的效率很高。

rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不同，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操做；基於存儲的可靠性的要求存儲能夠採用內存或者硬盤。

3)在可用性方面，

rabbitMQ支持miror的queue，主queue失效，miror queue接管。

kafka的broker支持主備模式。

4)在集羣負載均衡方面，

kafka採用zookeeper對集羣中的broker、consumer進行管理，能夠註冊topic到zookeeper上；經過zookeeper的協調機制，producer保存對應topic的broker信息，能夠隨機或者輪詢發送到broker上；而且producer能夠基於語義指定分片，消息發送到broker的某分片上。

rabbitMQ的負載均衡須要單獨的loadbalancer進行支持。

原文：http://wbj0110.iteye.com/blog/1974988

收集的rabbitmq資料以下：

http://jzhihui.iteye.com/category/195005

http://lynnkong.iteye.com/blog/1699684

http://blog.csdn.net/anzhsoft/article/details/19607841

http://ybbct.iteye.com/blog/1562326