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。 比 Twisted 還方便。（比如我們）
但是的確是浪費了zmq 的很多特性。
RabbitMQ和Kafka基本上是一類東西，各有優劣，ZeroMQ只是一個網絡庫，不支持持久化。