Kafka vs RocketMQ——多Topic对性能稳定性的影响-转自阿里中间件

引言

上期咱们对比了RocketMQ和Kafka在多Topic场景下，收发消息的对比测试，RocketMQ表现稳定，而Kafka的TPS在64个Topic时能够保持13万，到了128个Topic就跌至0.85万，致使没法完成测试。咱们不由要问：

为何看不到Kafka性能暴跌的趋势呢？

今天的测试，就来排查一下这个问题，而后验证一下两个系统对外服务的稳定性。本次测试，要引入“稳定性测试”这个概念，那什么是稳定性测试呢？咱们先来看一下定义：

稳定性测试：测试系统的长期稳定运行能力。在系统运行过程当中，对系统施压，观察系统的各类性能指标以及服务器的负载指标。

好像有点抽象，咱们仍是看一个例子吧。

下面的测试对比图，是用来评测汗血宝马和蒸汽机车谁快的一组竞速曲线：

图1 汗血宝马和蒸汽火车的速度稳定性对比

上图的横轴表示测试时间，纵轴表示火车和马的速度，能够看到，马的加速和最高速度均好于火车。可是因为体力缘由，15分钟后，马就很难维持最高速度，只能稍做休息再加速，直至体力耗尽；而火车全程达到最高速度就基本不会变了。因此结论很明显，火车的速度稳定性优于汗血宝马。

假想一下：若是测试时间只取15分钟会获得什么结论呢？汗血宝马不管是加速，仍是最高速度，乃至单位时间内经过的路程均完胜火车。因此若是是要对长途运输作一个评测的话，那么正确的测试方式是——拉长测试时间，以观察被测对象的稳定性。

OK，再次回到咱们上次测试留下的疑问——暴跌无趋势。其缘由极可能是，在早期的32Topic，64Topic时，Kafka就已经出现了下跌的趋势，只是咱们压测的时间不够，算做测试经过了。

本期测试，咱们沿用上一期的测试方式，惟一不一样的就是把压测时间从15分钟拉长到1小时，看看在较长的压力时间内，Kafka和RocketMQ哪个产品对外服务更稳定。

测试目的

消息收发端共存的状况下，RocketMQ和Kafka各运行约1个小时，观察不一样Topic数量时，Kafka、RocketMQ性能指标（TPS&响应时间）的波动性。

测试场景

默认每一个Topic的分区数为8，每一个Topic对应一个订阅者，逐步增长Topic的数量，这里性能是否抖动根据趋势图作直观的判断，数据以下：

作彻底部的测试场景后会发现，正如以前的猜想，Kafka在32和64个Topic时，就已经出现了不稳定的状况。下面看一下32和64个Topic的详细数据，以下图所示：

图2. 32个Topic性能曲线对比

蓝色Kafka的TPS曲线在18分钟之后，就开始上下波动，毫无规律，而RocketMQ则表现稳定。下面再看64个Topic的状况，以下图所示：

图3. 64个Topic性能曲线对比

图4. 64个Topic客户端发送响应时间对比

Kafka的TPS在前20分钟保持稳定，并大幅度领先RocketMQ。20分钟后又开始出现不规则波动，这些波动直接致使响应时间的变化（图4），某个时刻Kafka的客户端响应时间会达到25毫秒，而RocketMQ全程都是5毫秒。
此次的对比3个场景中， Kafka胜出一个，就是8个Topic的场景，如图5所示，因为Topic个数和分区数的限制，致使Kafka只适合小规模的业务系统。

图5. 8个Topic性能曲线对比

测试结论

1. Topic数的增长对RocketMQ无影响，长时间运行服务很是稳定。
2. Kafka 的Topic数量建议不要超过8个。8个以上的Topic会致使Kafka响应时间的剧烈波动，形成部分客户端的响应时间过长，影响客户端投递的实时性以及客户端的业务吞吐量。

附录

测试环境

服务端为单机部署，机器配置以下：

CPU	24核
内存	94G
硬盘	Seagate Constellation ES (SATA 6Gb/s) 2.00 TB 7202 rpm
网卡	1000Mb/s

应用版本：

消息中间件	版本
Kafka	0.8.2
RocketMQ	3.4.8

测试脚本:

压力端	Jmeter的java客户端
消息大小	128 字节
并发数	能达到服务端最大TPS的最优并发
Topic分区数量	8
刷盘策略	异步落盘

未完待续

通过本期的测试，RocketMQ在稳定性上也是完胜Kafka，若是只是小规模的业务，Kafka能够知足需求，但要是对业务的复杂度和稳定性有更高的要求，RocketMQ则是更好的选择。