ZMQ和kafka、RabbitMQ功能對比

RabbitMQ是一個AMQP實現,傳統的messaging queue系統實現,基於Erlang。老牌MQ產品了。AMQP協議更多用在企業系統內,對數據一致性、穩定性和可靠性要求很高的場景,對性能和吞吐量還在其次。

Kafka是linkedin開源的MQ系統,主要特點是基於Pull的模式來處理消息消費,追求高吞吐量,一開始的目的就是用於日誌收集和傳輸,0.8開始支持複製,不支持事務,適合產生大量數據的互聯網服務的數據收集業務。

ZeroMQ只是一個網絡編程的Pattern庫,將常見的網絡請求形式(分組管理,鏈接管理,發佈訂閱等)模式化、組件化,簡而言之socket之上、MQ之下。對於MQ來說,網絡傳輸只是它的一部分,更多需要處理的是消息存儲、路由、Broker服務發現和查找、事務、消費模式(ack、重投等)、集羣服務等。

 

RabbitMQ/Kafka/ZeroMQ 都能提供消息隊列服務,但有很大的區別。

在面向服務架構中通過消息代理(比如 RabbitMQ / Kafka等),使用生產者-消費者模式在服務間進行異步通信是一種比較好的思想。

因爲服務間依賴由強耦合變成了鬆耦合。消息代理都會提供持久化機制,在消費者負載高或者掉線的情況下會把消息保存起來,不會丟失。就是說生產者和消費者不需要同時在線,這是傳統的請求-應答模式比較難做到的,需要一箇中間件來專門做這件事。其次消息代理可以根據消息本身做簡單的路由策略,消費者可以根據這個來做負載均衡,業務分離等。

缺點也有,就是需要額外搭建消息代理集羣(但優點是大於缺點的 ) 。

ZeroMQ 和 RabbitMQ/Kafka 不同,它只是一個異步消息庫,在套接字的基礎上提供了類似於消息代理的機制。使用 ZeroMQ 的話,需要對自己的業務代碼進行改造,不利於服務解耦。

RabbitMQ 支持 AMQP(二進制),STOMP(文本),MQTT(二進制),HTTP(裏面包裝其他協議)等協議。Kafka 使用自己的協議。

Kafka 自身服務和消費者都需要依賴 Zookeeper。

RabbitMQ 在有大量消息堆積的情況下性能會下降,Kafka不會。畢竟AMQP設計的初衷不是用來持久化海量消息的,而Kafka一開始是用來處理海量日誌的。

總的來說,RabbitMQ 和 Kafka 都是十分優秀的分佈式的消息代理服務,只要合理部署,不作,基本上可以滿足生產條件下的任何需求。

ZeroMQ,本地進程之間的coordination
RabbitMQ,工作消息隊列
Kafka, 日誌訂閱,着重數據流處理

處理分佈式事務方面,它們哪個更適合呢?是不是可以理解爲老牌的RabbitMQ對一致性支持更好好一些!

好像很多公司 用zmq 只是用來方便地做socket,閱讀了 ZMQ 的 Guide 文檔後,我的理解是,這是個類似於 Socket 的一系列接口,他跟 Socket 的區別是:普通的 socket 是端到端的(1:1的關係),而 ZMQ 卻是可以N:M 的關係,人們對 BSD 套接字的瞭解較多的是點對點的連接,點對點連接需要顯式地建立連接、銷燬連接、選擇協議(TCP/UDP)和處理錯誤等,而 ZMQ 屏蔽了這些細節,讓你的網絡編程更爲簡單。ZMQ 用於 node 與 node 間的通信,node 可以是主機或者是進程。

但是的確是浪費了zmq 的很多特性。

RabbitMQ和Kafka基本上是一類東西,各有優劣,ZeroMQ只是一個網絡庫,不支持持久化。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章