MQ框架非常之多，今天簡單說一下有代表性的兩個MQ(rabbitmq和kafka)。經常會有人問rabbitmq和kafka到底哪個好呢？其實沒有好與不好之分，只有哪個更合適，首先要根據自己項目的業務場景和需求來選擇更合適的一個MQ。

在應用場景方面

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

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

在架構模型方面

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數據；無消息確認機制。

在吞吐量方面

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

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

在可用性方面

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

kafka的broker支持主備模式。

在集群負載均衡方面

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

rabbitmq的負載均衡需要單獨做，它本身不支持。

rabbitmq該怎麽用

1. rabbitmq的消息應當盡可能的小，並且只用來處理實時且要高可靠性的消息。

2. 消費者和生產者的能力盡量對等，否則消息堆積會嚴重影響RabbitMQ的性能。

3. 集群部署，使用熱備，保證消息的可靠性。

rabbitmq

Kafka該怎麽用

1. 應當有一個非常好的運維監控系統，不單單要監控Kafka本身，還要監控Zookeeper。

2. 對消息順序不依賴，且不是那麽實時的系統。

3. 對消息丟失並不那麽敏感的系統。

kafka

轉自

http://www.toutiao.com/i6461528581989204493/

rabbitmq和kafka怎麽選？【轉】