Kafka和Mq對比

其實，作為消息隊列來說，企業中選擇mq的還是多數，因為像Rabbit，Rocket等mq中間件都屬于很成熟的産品，性能一般但可靠性較強，

而kafka原本設計的初衷是日志統計分析，現在基于大資料的背景下也可以做營運資料的分析統計，而redis的主要場景是記憶體資料庫，作為消息

隊列來說可靠性太差，而且速度太依賴網絡IO，在伺服器本機上的速度較快，且容易出現資料堆積的問題，在比較輕量的場合下能夠适用。

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進行支援。