| 1.资料文档 |
网络资料多 |
多，比较新的书比如《RabbitMQ实战指南》 |
有kafka作者自己写的书，较新的书有《Kafka并不难学》 |
网络资料良莠不齐，官方文档比较简洁 |
网络只有代码实现和简单介绍 |
| 2.开发语言 |
java |
Erlang |
Scala |
java |
c |
| 3.支持的协议 |
OpenWire、STOMP、REST、XMPP、AMQP |
AMQP |
基于TCP 自己定义的一套 |
自己定义的一套 |
TCP、UDP |
| 4.消息存储 |
内存、磁盘、数据库，支持少量堆积 |
内存、磁盘、支持少量堆积 |
内存、磁盘、数据库。支持大量堆积 |
磁盘，支持大量堆积（commitLog文件） 高并发写性能突出（累积4K才强制从pagecache中刷到磁盘） |
消息发送端的内存或者磁盘中，不支持持久化 |
| 5.消息事务 |
支持 |
支持 |
支持（客户端将信道设置为事务模式） |
支持 |
不支持 |
| 6.负载均衡 |
支持负载均衡，可基于zookeeper实现负载均衡 |
负载均衡支持不是很好 1.通过交换器和绑定机制可以决定投递的队列，这些多需要手动创建，镜像队列机制可以解决broker负载过大的问题 2.多消费者采用轮询机制，basicQos可以限制信道上的消费者能保持的最大未确认消息数量 3.可借助HAProxy、LVS技术，或者在客户端使用算法实现负载均衡 |
支持负载均衡（大部分是自动完成） |
支持 |
去中心化，不支持负载均衡。本身只是一个多线程网络库 |
| 7.集群方式 |
支持简单集群模式，简单主备，对高级集群模式支持不好 |
支持简单集群，对高级集群模式支持不好（个人理解：网络是个严重问题，最好部署同一局域网），需要至少一个磁盘节点 |
天然的leader-slave无状态集群，每台服务器既是Master也是Slave。依靠zookeeper |
常用 多对’Master-Slave’ 模式，开源版本需手动切换Slave变成Master。Broker部署相对复杂， slave会从master拉取数据备份 |
去中心化，不支持 |
| 8.管理界面 |
一般 |
好，自带可视化控制台，亲测操作非常完备 |
一般，有开源工具kafka-eagle |
一搬，有控制台 |
无 |
| 9.可用性 |
高（主从） |
高（主从） |
非常高（分布式） |
非常高（分布式） |
高 |
| 10.消息重复 |
支持 at least once |
支持 at least once ，at most once |
支持 at least once ，at most once |
支持 at least once |
只有重传机制，没有持久化，消息丢了重传也没用 |
| 11.吞吐量 |
比较大 |
比较大 |
极大，按批次发送消息和消费消息 |
大（可以批量消费，不批量发送） |
极大 |
| 12.订阅形式和消息分发 |
点对点、广播 |
direct, topic ,Headers和fanout |
基于topic及按照topic进行正则匹配的发布订阅模式 |
基于topic/messageTag以及按照消息类型、属性进行正则匹配的发布订阅模式 |
点对点 p2p |
| 13.顺序消息 |
不支持 |
不支持 |
支持 |
支持 |
不支持 |
| 14.消息确认 |
支持 |
支持 autoAck : false true |
支持 ack : 0,1,all |
支持 |
支持 |
| 15.消息回溯 |
不支持 |
不支持 |
支持指定分区okkset位置的回溯 |
支持指定时间点的回溯 |
不支持 |
| 16.消息重试 |
不支持 |
不支持，但是可以利用消息确认机制实现 |
不支持，但是可以实现（支持指定分区offset位置的回溯，可以实现消息重试） |
支持，策略是在消费失败时定时重试，每次时间间隔相同 发送端的send方法的内部重试逻辑： a）至多重试三次 b）如果发送失败，则轮转到下一个broker c）这个方法的总耗时不超过sendMsgTimeout设置的值，默认10s，超过时间不再重试 |
不支持 |
| 17.并发度 |
高 |
极高（Erlang语言） |
高（消费者中再开启多线程可进一步提高） |
高（基本同kafka） |
高 |