从 Apache RocketMQ 和 Kafka 看 Topic 数量对单机性能的影响
摘要: 这次,我们来模拟一个真实的场景: * 消息的发送和订阅一定是共存的 * 要支持多个订阅端订阅自己感兴趣的消息 我们将针对 RocketMQ 和 Kafka,对比在上述场景中,究竟谁更胜一筹。
阿里云消息队列测试小组 出品
上一期我们对比了三类消息产品(Kafka、RabbitMQ、RocketMQ)单纯发送小消息的性能,受到了程序猿们的广泛关注,其中大家对这种单纯的发送场景感到并不过瘾,因为没有任何一个网站的业务只有发送消息。本期,我们就来模拟一个真实的场景:
- 消息的发送和订阅一定是共存的
- 要支持多个订阅端订阅自己感兴趣的消息
本期我们将针对 RocketMQ 和 Kafka,对比在上述场景中,究竟谁更胜一筹。在正式开始测试之前,首先要向大家明确2个概念:
查看上一期文章
1. Topic为何物
Topic是消息中间件里一个重要的概念,每一个Topic代表了一类消息,有了多个Topic,就可以对消息进行归类与隔离。
可以参照下图的动物园喂食模型,每一种动物都只能消费相对应的食品。
2. 分区为何物
Kafka和RocketMQ都是磁盘消息队列的模式,对于同一个消费组,一个分区只支持一个消费线程来消费消息。过少的分区,会导致消费速度大大落后于消息的生产速度。所以在实际生产环境中,一个Topic会设置成多分区的模式,来支持多个消费者,参照下图:
在互联网企业的实际生产环境中,Topic数量和分区都会比较多,这就要求消息中间件在多Topic共存的时候,依然能够保证服务的稳定性。下面就进入测试环节,看看消息发送端,订阅端共存时,Kafka和RocketMQ对多Topic的处理能力。
测试目的
对比发送端、接收端共存情况下,Topic数量对Kafka、RocketMQ的性能影响,分区数采用8个分区。这次压测我们只关注服务端的性能指标,所以压测的退出标准是:
不断增加发送端的压力,直到系统吞吐量不再上升,而响应时间拉长。此时服务端出现性能瓶颈,获取相应的系统最佳吞吐量,整个过程中保证消息没有累积。
测试场景
默认每个Topic的分区数为8,每个Topic对应一个订阅者,逐步增加Topic数量。得到如下数据:
可以看到,不论Topic数量是多少,Kafka和RocketMQ均能保证发送端和消费端的TPS持平,就是说,保证了消息没有累积。
根据Topic数量的变化,画出二者的消息处理能力的对比曲线如下图:
从图上可以看出:
- Kafka在Topic数量由64增长到256时,吞吐量下降了 98.37% 。
- RocketMQ在Topic数量由64增长到256时,吞吐量只下降了 16% 。
为什么两个产品的表现如此悬殊呢?这是因为Kafka的每个Topic、每个分区都会对应一个物理文件。当Topic数量增加时,消息分散的落盘策略会导致磁盘IO竞争激烈成为瓶颈。而RocketMQ所有的消息是保存在同一个物理文件中的,Topic和分区数对RocketMQ也只是逻辑概念上的划分,所以Topic数量的增加对RocketMQ的性能不会造成太大的影响。
测试结论
在消息发送端,消费端共存的场景下,随着Topic数的增加Kafka吞吐量会急剧下降,而RocketMQ则表现稳定。因此Kafka适合Topic和消费端都比较少的业务场景,而RocketMQ更适合多Topic,多消费端的业务场景。
你知道阿里云消息队列(MQ)就是 Apache RocketMQ 的商业版吗?
经过上面的测试,RocketMQ几乎是完胜Kafka,其实这并不奇怪,因为RocketMQ就是针对互联网的生产要求孕育而生的,读者现在也应该明白为什么 RocketMQ 可以支撑阿里集团的海量消息业务了吧。 目前阿里云上的消息队列(MQ)就是RocketMQ的商业版,除了与RocketMQ一样具备极佳的性能,还具备哪些差异和优势呢?我们一起来看一看吧:
安全防护 | 支持 | 不支持 |
主子账号支持 | 支持 | 不支持 |
可靠性 | - 同步刷盘 - 同步双写 - 超3份数据副本 - 99.99999999% | - 同步刷盘 - 异步刷盘 |
可用性 | - 非常好,99.95% - Always Writable | 好 |
横向扩展能力 | - 支持平滑扩展 - 支持百万级 QPS | 支持 |
Low Latency | 支持 | 不支持 |
消费模型 | Push / Pull | Push / Pull |
定时消息 | 支持(可精确到秒级) | 支持(只支持18个固定 Level) |
事务消息 | 支持 | 不支持 |
全链路消息轨迹 | 支持 | 不支持 |
消息堆积能力 | 百亿级别 不影响性能 | 百亿级别 影响性能 |
消息堆积查询 | 支持 | 支持 |
消息回溯 | 支持 | 支持 |
消息重试 | 支持 | 支持 |
死信队列 | 支持 | 支持 |
性能(常规) | 非常好 百万级 QPS | 非常好 十万级 QPS |
性能(万级 Topic 场景) | 非常好 百万级 QPS | 非常好 十万级 QPS |
性能(海量消息堆积场景) | 非常好 百万级 QPS | 非常好 十万级 QPS |
阿里云消息队列Kafka企业级消息服务(MQ-Kafka) VS Apache Kafka
为了拥抱开源生态,阿里云消息队列(MQ)MQ 推出 Kafka 企业级消息服务(MQ-Kafka),全面融合 Kafka 开源生态,兼容 Kafka API,做到无缝迁移,打造更安全、更可靠、更易运维的 Kafka 企业级消息服务。
Apache Kafka和 消息队列 Kafka 企业级消息服务(MQ-Kafka)在性能、可用性、可靠性等方面的对比如下:
安全防护 | × | √ |
主子账号支持 | × | √ |
性能(常规) | 非常好 | 非常好 |
性能(万级Topic情况下) | 低 | 非常好 |
性能(海量消息堆积情况下) | 低 | 非常好 |
可靠性 | 一般 | 非常好,99.99999999% |
可用性 | 好 | 非常好,99.99%,Always Writable |
全链路消息轨迹 | × | √ |
消息堆积查询 | × | √ |
消息回溯 | × | √ |
服务支持 | 用户自己运维 | 阿里云平台统一运维 |