荆棘从死亡中来，死亡又包含着新生。
    •  0 回帖  •  1.5K 浏览  •  4 年前
 

Kafka、RabbitMQ、RocketMQ 优劣对比

-- -- kafka RocketMQ RabbitMQ
定位 设计定位 系统间的数据流管道，实时数据处理。 例如：常规的消息系统、网站活性跟踪，监控数据，日志收集、处理等 非日志的可靠消息传输。 例如：订单，交易，充值，流计算，消息推送，日志流式处理，binglog 分发等 可靠消息传输。和 RocketMQ 类似。
基础对比 成熟度 日志领域成熟 成熟 成熟
所属社区／公司 Apache Alibaba 开发，已加入到 Apache 下 Mozilla Public License
社区活跃度 高 中 高
API 完备性 高 高 高
文档完备性 高 高 高
开发语言 Scala Java Erlang
支持协议 一套自行设计的基于 TCP 的二进制协议 自己定义的一套 (社区提供 JMS-- 不成熟) AMQP
客户端语言 C/C++、Python、Go、Erlang、.NET、Ruby、Node.js、PHP 等 Java Java、C、 C++、 Python、 PHP、Perl 等
持久化方式 磁盘文件 磁盘文件 内存、文件
可用性、可靠性比较 顺序消费 支持顺序消费 但是一台 Broker 宕机后，就会产生消息乱序 ( 来自网上，尚未找到原因） 支持顺序消费 在顺序消息场景下，消费失败时消费队列将会暂停 支持顺序消费
定时消息 不支持 开源版本仅支持定时 Leve 不支持
事务消息 不支持 支持 不支持
Broker 端消息过滤 不支持 支持 通过 tag 过滤，类似于子 topic 不支持
消息查询 不支持 支持 根据 MessageId 查询 支持根据 MessageKey 查询消息 不支持
消费失败重试 不支持失败重试 offset 存储在 consumer 中，无法保证。 0.8.2 版本后支持将 offset 存储在 zk 中 支持失败重试 offset 存储在 broker 中 支持失败重试
消息重新消费 支持通过修改 offset 来重新消费 支持按照时间来重新消息 --
发送端负载均衡 可自由指定 可自由指定 需要单独 loadbalancer 支持
消费并行度 消费并行度和分区数一致 顺序消费：消费并行度和分区数一致 乱序消费：消费服务器的消费线程数之和 可一次抓取多条一起消费。 镜像模式下其实也是从 master 消费
消费方式 consumer pull consumer pull ／broker push broker push
批量发送 支持 默认 producer 缓存、压缩，然后批量发送 不支持 不支持
消息清理 指定文件保存时间，过期删除 指定文件保存时间，过期删除 Consumer ack 以后，消息将被标记为删除 可用内存少于 40%（默认），触发 gc，gc 时找到相邻的两个文件，合并 right 文件到 left。
运维 系统维护 Scala 语言开发，维护成本高 java 语言开发，维护成本低 Erlang 语言开发，维护成本高
部署依赖 zookeeper nameserver Erlang 环境
管理后台 官网不提供，第三方开源管理工具可供使用；不用重新开发 官方提供，rocketmq-console 官方提供 rabbitmqadmin
管理后台功能 功能 Kafka Web Conslole Brokers 列表；Kafka 集群中 Topic 列表，及对应的 Partition、LogSize 等信息；Topic 对应的 Consumer Groups、Offset、Lag 等信息； 生产和消费流量图、消息预览 KafkaOffsetMonitor： Kafka 集群状态；Topic、Consumer Group 列表；图形化展示 topic 和 consumer 之间的关系；图形化展示 consumer 的 Offset、Lag 等信息 Kafka Manager 管理几个不同的集群；监控集群的状态 (topics, brokers, 副本分布, 分区分布)；产生分区分配(Generate partition assignments) 基于集群的当前状态；重新分配分区 Cluster、Topic、Connection、NameServ、Message、Broker、Offset、Consumer overview、connections、channels、exchanges、queues、admin
总结 优点 1、在高吞吐、低延迟、高可用、集群热扩展、集群容错上有非常好的表现； 2、producer 端提供缓存、压缩功能，可节省性能，提高效率。 3、提供顺序消费能力 4、提供多种客户端语言 5、生态完善，在大数据处理方面有大量配套的设施。 1、在高吞吐、低延迟、高可用上有非常好的表现；消息堆积时，性能也很好。 2、api、系统设计都更加适在业务处理的场景。 3、支持多种消费方式。 4、支持 broker 消息过滤。 5、支持事务。 6、提供消息顺序消费能力；consumer 可以水平扩展，消费能力很强。 7、集群规模在 50 台左右，单日处理消息上百亿；经历过大数据量的考验，比较稳定可靠。 1、在高吞吐量、高可用上较前两者有所不如。 2、支持多种客户端语言；支持 amqp 协议。 3、由于 erlang 语言的特性，性能也比较好; 使用 RAM 模式时，性能很好。 4、管理界面较丰富，在互联网公司也有较大规模的应用;
缺点 1、消费集群数目受到分区数目的限制。 2、单机 topic 多时，性能会明显降低。 3、不支持事务 1、相比于 kafka，使用者较少，生态不够完善。消息堆积、吞吐率上也有所不如。 2、不支持主从自动切换，master 失效后，消费者需要一定的时间才能感知。 3、客户端只支持 Java 1、erlang 语言难度较大。集群不支持动态扩展。 2、不支持事务、消息吞吐能力有限 3、消息堆积时，性能会明显降低

建站不啰嗦，上手跟我做（二十九）rabbitMQ 安装