MQ选型比较

-- -- Kafka RocketMQ RabbitMQ
定位 设计定位 系统之间的数据流管道，实时数据处理。例如：常规消息系统、网站活动跟踪、监控数据、日志收集、处理等 非日志可靠消息传输。例如：订单、交易、充值、流计算、消息推送、日志流处理、binglog分发等 可靠的消息传输。类似于RocketMQ
基本比较 成熟度 成熟 成熟 成熟
-- 社区/公司 Apache Alibaba，后Apache Mozilla Public License
-- 社区活跃度 高 一般 高
-- API完成性 高 高 高
-- 文档完成性 高 高 高
-- 开发语言 Scala Java Erlang
-- 支持协议 一套自行设计的基于TCP的二进制协议 自定义集(社区提供JMS--未成熟) AMQP
可用性和可靠性 持久化 磁盘文件 磁盘文件 内存、磁盘文件
-- 部署访问 单机、集群 单机、集群 单机、集群
-- 集群管理器 zookeeper/kraft name server -
-- Master节点选择策略 自动从ISR中选举领导者 不支持自动主选。通过设置brokername和brokerId实现，brokername相同，brokerid=0时为master，其他为slave 最早加入集群的broker
-- 可用性 非常高分布式，主从 非常高分布式，主从 高主从，镜像方式实现，数据量大时可能出现性能瓶颈
-- 主从切换方式 主动切换N个副本，允许N-1个故障；master失败后，自动从ISR中选择一个master 不支持自动切换master失败，无法向master发送信息。消费者可以感知这个时间大约30s(默认)，然后从slave消费；如果master无法恢复，异步复制过程中可能丢失一些消息。 自动切换先加入集群的slave会成为master；因为新添加的slave没有在master之间同步数据，可能会丢失部分数据
-- 数据可靠性 非常好支持生产者单发、同步刷机、同步复制、异步 很好的producer单发，broker端支持同步刷盘，异步刷盘，同步双写，异步复制 好的生产者支持同步/异步确认。支持队列数据持久化，支持镜像主从同步
-- 消息写入性能 测试10字节：数百万条目/秒 测试10字节：单机机器和单个broker约7w/s，单机和3个broker约12w/s RAM约RocketMQ的1/2，磁盘约RAM的1/3
-- 性能稳定性 队列/分区的性能波动明显，性能明显下降。消息累计时性能稳定 多队列，消息堆积时性能稳定 消息堆积时，性能不稳定，显著下降
-- 单台计算机支持的队列数量 如果一台机器有超过64个队列/分区，负载将显著增加。队列越多，负载越高，发送消息的响应时间越长 单机支持最多50000个队列，负载不会发生显著变化 取决于内存
-- 存储方式 非常好，消息存储在日志中，每个分区由一个或多个段日志文件组成 很好，所有消息都存储在同一个提交日志中 通常，当生产者和消费者正常时，性能时稳定的；当消费者不消费时，性能是不稳定的
-- 复制备份 消息首先被写入领导者的日志。追随者从领导者那里读取数据。提取数据后，将确认领导者，然后将其写入日志。维护与ISR中的领导者同步的列表。落后太多的追随者将被删除 同步双写异步复制：从启动线程从主服务器提取数据 在正常模式下无副本；在镜像模式下：消息先到达master，然后写入Slave。加入集群之前将不会复制新的从站
-- 实时消息传递 毫秒级别 由消费者的轮询间隔决定 毫秒级别 支持拉和推模式，延迟通常毫秒级 毫秒
功能比较 顺序消费 支持 支持，当顺序消费失败时，消费队列将被挂起 支持，但是很麻烦
-- 定时消息 不支持 开源版本仅支持定时级别 不支持
-- 交易消息 不支持 支持 不支持
-- Broker Message Filtering 不支持 支持按标签过滤，类似于子主题 不支持
-- Message Query 不支持 支持基于MessageId/MessageKey查询 不支持
-- 消费失败后重试 不支持失败的重试。偏移量存储在消费者中，无法保证。在0.8.2版本之后，支持将偏移量存储在zk中 支持失败重试，存储在代理中的偏移量 支持
-- 消息重新消费 通过修改偏移量支持重复消费 支持根据时间重新发送消息 支持
-- 发送方的负载均衡 可自由指定 可自由指定 需要单独的负载均衡器支持
-- 消费并行性 消费并行性与分区数一致 顺序消费：消费并行性和分区数相同； 无序消费：消费服务器的消费线程之和 可以一次抓取多个物品并一起消费。在镜像模式下，它实际上是从主服务器上消费
-- 消费模式 pull pull/push push
-- 批量发送 支持默认生产者缓存、压缩，然后批量发送 支持 不支持
-- 消息清理 指定文件保留时间，过期后删除 指定文件保留时间，过期后删除 消费者确认后，消息将被标记为已删除。可用内存小于40%(默认值)。触发GC时会找到两个相邻文件，并将右侧文件合并到左侧
操作和维护 系统维护 Scala语言开发，维护成本高 Java语言开发，维护成本低 Erlang语言开发，维护成本高
-- 部署依赖关系 zk/kraft name server Erlang environment
-- 后台管理 官方网站不提供，提供第三方开源管理工具；无需重新开发 官方提供，消息队列rocketmq-控制台 官方提供Rabbitmqadmin
-- 管理后台功能 kafka web console broker队列；kafka集群主题列表，以及对应的分区、LogSize等信息；与主题对应的消费者组、偏移量、滞后等消息；生产和消费流图，消息预览kafkaOffsetMonitor；kafka集群状态；主题、消费者组列表；主题与消费者关系的图形显示等 集群、主题、连接、名称服务器、消息、代理、偏移、消费者 概述、连接、渠道、交换、队列、管理
总结 优势 1. 高吞吐量、低延迟、高可用性、集群热扩展和集群容错方面具有很好的性能。 2. 生产者提供缓存和压缩功能，以节省性能并提高效率。 3. 提供顺序消费能力 4. 提供多种客服端语言 5. 生态完备，有大量的大数据处理配套设施 1. 在高吞吐、低延迟和高可用性方面性能非常好；当消息堆积时性能也非常好。 2. api和系统设计更适合业务处理场景。 3. 支持多种消费方式。 4. 支持代理消息过滤。 5. 支持事务 6. 提供消息顺序消费能力；消费者可以水平扩展，有很强的消费能力。 7. 集群规模约为50台，一天处理数百亿条消息；经历了大数据量的测试，相对稳定可靠 1.支持多种客户端语言；支持amqp协议。 2. 由于erlang语言的特点，性能相对较好；当使用RAM模式时，性能非常好。 3. 管理界面丰富，互联网公司也有大规模的应用；
-- 缺点 1.消费者集群的数量受分区数量限制。 2. 当一台机器上有很多主题时，性能会大大降低。 3.不支持事务 1.与kafka相比，用户更少，生态也不完善。消息的积累和吞吐量也较低。 2.它不支持主从自动切换。在master失败后，消费者需要一定的时间来感知它。 1.Erlang语言比较难。集群不支持动态扩展。 2.不支持事务，有限消息吞吐量。 3.当消息堆积时，性能将大大降低
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容