【第345期】面试官：对比RocketMQ和Kafka，谈谈两者的区别

2022年5月17日 4:16 pm • 面试问题 • 阅读 15 围观者： 推荐一位大神朋友 淘宝内部交易系统采用淘宝自主研发的Notify消息中间件，并使用MySQL作为消息存储介质，可以完全水平扩展。为了进一步降低成本，我们认为存储部分可以进一步优化。 2011年初，Linkin开源了优秀的Kafka，经过淘宝中间件团队对Kafka的彻底审核，我们被Kafka无限的消息积累和高效的持久速度所吸引。但我们也发现，这套消息系统主要针对的是日志传输，并不适合在淘宝交易中使用，并且在下单、充值等场景中仍然存在很多功能不能令人满意的情况。为此，我们用Java语言重新编写了RocketMQ，定位于非日志，实现消息的可靠传输（日志场景也可以）。目前，RocketMQ在阿里巴巴集团广泛用于订单处理。 、交易、充值、流计算、消息推送、日志流式传输、binglog分发等场景。 为了方便大家选择，我们整理了一份RocketMQ和Kafka的对比文档。如果文章中有任何错误，欢迎来信指正。 support@www.gsm-guard.net 数据可靠性 RocketMQ支持异步实时磁盘刷新、同步磁盘刷新、同步Replication、异步Replication Kafka使用异步磁盘刷新和异步复制 总结：RocketMQ的同步刷盘比Kafka具有更高的单机可靠性，并且不会因为操作系统崩溃而造成数据丢失。同时，同步Replication比Kafka异步Replication更加可靠，数据不存在单点。 另外，Kafka的Replication是基于主题的，支持主机宕机时自动切换备机。然而，这里有一个问题。由于是异步Replication，切换后会有数据丢失。同时，如果重新启动Leader，则会与现有的Leader一起丢失。发生数据冲突。 RocketMQ开源版本不支持Master故障，Slave自动切换到Master。阿里云版RocketMQ支持自动切换功能。 性能对比 Kafka的单机写入TPS约为100万条消息/秒，消息大小为10字节。 RocketMQ每秒向单台机器上的单个TPS实例写入大约70,000条消息。单机部署3个Broker，最高可达12万条消息/秒。消息大小为 10 字节。总结：Kafka单机TPS达到百万，主要是Producer合并多个小消息，批量发送给Broker。 推荐：Java进阶视频资源 为什么RocketMQ没有这样做呢？ 生产者通常使用Java语言，缓存过多的消息。 GC是一个严重的问题。 Producer调用消息发送接口，但消息并没有发送到Broker，而是返回成功给业务。这时候Producer宕机了，就会导致消息丢失，业务出错。 生产者通常是分布式系统，每台机器由多个线程发送。我们认为在线系统中单个Producer每秒产生的数据量是有限的，不可能达到几万。 缓存功能完全可以由上层业务来完成。 单机支持的队列数量 如果Kafka单机上的队列/分区超过64个，负载显然会暴涨。队列越多，负载越高，发送消息的响应时间也会变长。 RocketMQ单机最多支持5万个队列，负载不会有明显变化。 多排队有什么好处？ 单台机器可以创建多个Topic，因为每个Topic都是由一批队列组成的 Consumer集群的大小与队列数量成正比。队列越多，Consumer 集群就可以越大。 实时消息传递 Kafka采用短轮询，实时性能取决于轮询间隔。 RocketMQ采用长轮询的方式，这与Push的实时性是一致的。消息传递延迟通常为几毫秒。 消费失败重试 Kafka消费失败不支持重试 RocketMQ消费失败支持定时重试，每次重试的间隔时间推迟。 总结：比如当前时刻有充值应用调用运营商网关，充值失败，可能是因为对方压力太大。稍后调用就会成功。例如，支付宝对于从银行借钱也有类似的要求。 这里的重试需要可靠重试，即重试失败的消息不会因为Consumer宕机而丢失。 严格的消息顺序 Kafka支持消息顺序，但是当Broker宕机时，消息就会乱序。 RocketMQ支持严格的消息顺序。在顺序消息场景中，Broker宕机后，发送消息会失败，但不会乱序。 Mysql Binlog 分发需要严格的消息排序 定时消息 Kafka 不支持预定消息 RocketMQ支持两种类型的定时消息 RocketMQ开源版本仅支持定时Level 阿里云ONS支持定时级别和指定毫秒级的延迟时间。 分布式交易消息 Kafka不支持分布式事务消息 阿里云ONS支持分布式定时消息，未来开源版本的RocketMQ也计划支持分布式事务消息。 留言查询Kafka不支持消息查询 RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息（发送消息时指定一个Message Key，任意字符串，比如指定订单ID） 总结：消息查询对于定位消息丢失问题非常有帮助。例如，订单处理失败，无论是未收到消息还是接收处理中出现错误。 消息回溯 Kafka理论上可以根据偏移量追溯消息 RocketMQ支持基于时间的消息回溯，精确到毫秒级，例如从一天前的某时某分某秒开始，重新消费消息。 总结：典型的业务场景是消费者进行订单分析，但是由于程序逻辑或者依赖系统故障，今天消费的所有消息都失效了，需要从昨天的零开始重新消费，那么消息重放功能就从时间开始。对生意很有帮助。 消费并行性 Kafka的消费并行度取决于Topic中配置的分区数量。如果分区数为10，那么最多可以有10台机器并行消费（每台机器只能启动1个线程），也可以一台机器消费（10个线程并行消费）。即消费并行度与分区数量一致。 RocketMQ消费并行度分为两种情况： 顺序消费法的并行度和Kafka的一模一样 乱序模式下的并行度取决于Consumer线程的数量。例如，Topic配置了10个队列，10台机器消费，每台机器100个线程，那么并行度为1000。 留言轨迹 Kafka不支持消息路径 阿里云ONS支持消息追踪 开发语言友好性 Kafka用 Scala 编写 RocketMQ是用Java语言编写的 Broker端消息过滤 Kafka不支持Broker端的消息过滤 RocketMQ支持两种broker端消息过滤方式 基于Message Tag的过滤相当于子主题的概念 通过上传一段Java代码到服务器，你可以过滤任何形式的消息，甚至可以过滤和拆分Message Body。 消息积累能力 理论上，Kafka 的堆叠能力比 RocketMQ 更强，但 RocketMQ 也可以支持单机数亿条消息的堆叠能力。我们相信这种堆叠能力完全可以满足业务需求。 开源社区活动 Kafka社区更新缓慢 RocketMQ的github社区有注册联系方式的个人和企业用户250人，QQ群1000多人。 商业支持 Kafka原开发团队成立了新公司，但目前还没有相关产品上市。RocketMQ在阿里云公测已经近半年了。目前它作为免费云服务可供商业使用，并向用户承诺99.99%的可靠性。同时彻底解决了用户自建MQ产品运维的复杂性。 到期 Kafka在伐木领域相对成熟 RocketMQ在阿里巴巴集团内部被大量应用使用，每天产生海量消息，并已成功支持多个天猫双十一群发消息测试。是数据削峰填谷的有力工具。推荐：Java进阶视频资源 感谢您的阅读，希望对您有所帮助：） 来源：www.gsm-guard.net/alibaba/RocketMQ/wiki/rmq_vs_kafka 主流Java进阶技术（学习资料分享） 而不是在网上搜索问题？还不赶快关注我们吧~ PS：因为公众号平台改变了推送规则，如果不想错过内容，记得看完后点击“阅读”并加个“星”，这样每次推送新文章，它将尽快出现在您的订阅中。在列表中。点击“关注”即可支持我们！ 版权声明：本文内容由网友自愿贡献，本文所表达的观点仅代表作者自己的观点。本网站仅提供信息存储空间服务，不拥有任何所有权，也不承担相关法律责任。如果您发现本站有任何涉嫌侵权/非法内容，请发送邮件举报。一经核实，该网站将立即删除。 本文由斑马博客整理。本文链接为：https://www.gsm-guard.net/index.php/post/8671.html