访问权限控制
Zookeeper
不支持
Java，C++，Python
非常好每条10个字节测试：百万条/s
很好每条10个字节测试：单机单broker约7w/s，单机3个broker约12w/s
Broker端消息过滤
所属社区/公司
发送端负载均衡
一套自行设计的基于TCP的二进制协议
1、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有非常好的表现；2、producer端提供缓存、压缩功能，可节省性能，提高效率。3、提供顺序消费能力4、提供多种客户端语言5、生态完善，在大数据处理方面有大量配套的设施。
持久化方式
单机超过64个队列/分区，Load会发生明显的飙高现象，队列越多，load越高，发送消息响应时间变长
功能对比
磁盘文件
1、相比于kafka，使用者较少，生态不够完善。消息堆积、吞吐率上也有所不如。2、不支持主从自动切换，master失效后，消费者需要一定的时间才能感知。3、客户端只支持Java
Alibaba开发，已加入到Apache旗下
一般生产者、消费者正常时，性能表现稳定；消费者不消费时，性能不稳定
主从切换
非常好消息存储在log中，每个分区由一个或多个segment log文件
API完备性
成熟
好producer支持同步／异步ack。支持队列数据持久化，镜像模式中支持主从同步
单机/集群
指定文件保存时间，过期删除
批量发送
数据可靠性
社区活跃度
开源版本仅支持定时Leve
定时消息
C++、Python
无
缺点
消息清理
高主从，采用镜像模式实现，数据量大时可能产生性能瓶颈
RocketMQ
优点
支持根据MessageId查询支持根据MessageKey查询消息
很好支持producer单条发送、同步刷盘、同步复制、异步。
RAM约为RocketMQ的1/2，Disk的性能约为RAM性能的1/3
客户端语言
消息堆积时，性能不稳定、明显下降
内存，文件
可用性
Kafka
Mozilla Public License
Apache
可一次抓取多条一起消费。镜像模式下其实也是从master消费
很好producer单条发送，broker端支持同步刷盘、异步刷盘，同步双写，异步复制。
消费方式
Java
消息写入性能
高
可用性可靠性比较
单机支持的队列数
大数据领域，实时数据处理
非日志的可靠性消息传输
消息投递实时性
设计定位
1、在高吞吐、低延迟、高可用上有非常好的表现；消息堆积时，性能也很好。2、api、系统设计都更加适在业务处理的场景。3、支持多种消费方式。4、支持broker消息过滤。5、支持事务。6、提供消息顺序消费能力；consumer可以水平扩展，消费能力很强。7、集群规模在50台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠。
支持默认producer缓存、压缩，然后批量发送
消费并行度和分区数一致
依赖于内存
队列较多、消息堆积时性能稳定
日志领域成熟
堆积能力
非常高分布式、主从
支持协议
1、erlang 语言难度较大。集群不支持动态扩展。2、不支持事务、消息吞吐能力有限3、消息堆积时，性能会明显降低
中
Scala(Java)
消息查询
基础对比
Consumer ack以后，消息将被标记为删除可用内存少于40%（默认），触发gc，gc时找到相邻的两个文件，合并right文件到left。
支持通过修改offset来重新消费
定位
Broker和partition中自动选举出leader
开发语言
支持顺序消费但是如果发送网络抖动，就会产生消息乱序
不支持失败重试offset存储在consumer中，无法保证。0.8.2版本后支持将offset存储在zk中
集群管理
支持
消费失败重试
支持通过tag过滤，类似于子topic
可自由指定
支持失败重试
顺序消费：消费并行度和分区数一致乱序消费：消费服务器的消费线程数之和
消息先写入leader的log，followers从leader中同步数据，然后写入log中。
顺序消费
支持按照时间来重新消息
支持失败重试offset存储在broker中
支持顺序消费在顺序消息场景下，消费失败时消费队列将会暂停
毫秒级支持pull、push两种模式，延时通常在毫秒级
consumer pull
AMQP
性能的稳定性
最早加入集群的broker为master
单机支持最高5万个队列，Load不会发生明显变化
选主方式
Erlang
成熟度
事务消息
支持顺序消费
普通模式下不复制；镜像模式下：消息先到mster，然后写到slave上。加入集群之前的消息不会被复制到新的slave上。
类似数据库一样，需要配置账号密码
毫秒级
队列/分区多时性能不稳定，明显下降。消息堆积时性能稳定
非常好所有消息存储在同一个commit log中
部署方式
需要单独loadbalancer支持
消费并行度
Name Server
毫秒级具体由consumer轮询间隔时间决定
RabbitMQ
自己定义的一套（社区提供，JMS--不成熟）
consumer pull ／broker push
文档完备性
1、在高吞吐量、高可用上较前两者有所不如。2、支持多种客户端语言；支持amqp协议。3、由于erlang语言的特性，性能也比较好; 使用RAM模式时，性能很好。4、管理界面较丰富，在互联网公司也有较大规模的应用;
Kafka VS RocketMQ VS RabbitMQ
复制备份
1、消费集群数目受到分区数目的限制。2、单机topic多时，性能会明显降低。3、不支持事务
同步双写异步复制：slave启动线程从master中拉数据
自动切换N个副本，允许N-1个失效，然后选举出新的leader
broker push
消息重新消费
总结
