TubeMQ VS Kafka性能对比测试总结

2 测试场景方案

如下是我们根据实际应用场景设计的测试方案：

用”复仇者联盟”里的角色来形容：

具体的数据分析来看：

1. 单Topic单实例配置下，TubeMQ吞吐量要远低于Kafka；单Topic多实例配置下，TubeMQ在4个实例时吞吐量追上Kafka对应5个分区配置，同时TubeMQ的吞吐量随实例数增加而增加，Kafka出现不升反降的情况；TubeMQ可以在系统运行中通过调整各项参数来动态的控制吞吐量的提升；
2. 多Topic多实例配置下，TubeMQ吞吐量维持在一个非常稳定的范围，且资源消耗，包括文件句柄、网络连接句柄数等非常的低；Kafka吞吐量随Topic数增多呈现明显的下降趋势，且资源消耗急剧增大；在SATA盘存储条件下，随着机型的配置提升，TubeMQ吞吐量可以直接压到磁盘瓶颈，而Kafka呈现不稳定状态；在CG1机型SSD盘情况下，Kafka的吞吐量要好于TubeMQ；
3. 在过滤消费时，TubeMQ可以极大地降低服务端的网络出流量，同时还会因过滤消费消耗的资源少于全量消费，反过来促进TubeMQ吞吐量提升；kafka无服务端过滤，出流量与全量消费一致，流量无明显的节约；
4. 资源消耗方面各有差异：TubeMQ由于采用顺序写随机读，CPU消耗很大，Kafka采用顺序写块读，CPU消耗很小，但其他资源，如文件句柄、网络连接等消耗非常的大。在实际的SAAS模式下的运营环境里，Kafka会因为zookeeper依赖出现系统瓶颈，会因生产、消费、Broker众多，受限制的地方会更多，比如文件句柄、网络连接数等，资源消耗会更大；

4 测试环境及配置

4.2 【Broker硬件机型配置】

4.3 【Broker系统配置】

5.1 场景一：基础场景，单topic情况，一入两出模型，分别使用不同的消费模式、不同大小的消息包，分区逐步做横向扩展，对比TubeMQ和Kafka性能

5.1.1 【结论】

在单topic不同分区的情况下：

1. Kafka随着分区增多吞吐量略有下降，CPU使用率很低；
2. TubeMQ分区由于是逻辑分区，增加分区不影响吞吐量；Kafka分区为物理文件的增加，但增加分区入出流量反而会下降；

" class="reference-link">5.1.2 【指标】

5.2 场景二：单topic情况，一入两出模型，固定消费包大小，横向扩展实例数，对比TubeMQ和Kafka性能情况

5.2.1 【结论】

从场景一和场景二的测试数据结合来看：

1. TubeMQ随着实例数增多，吞吐量增长，在4个实例的时候吞吐量与Kafka持平，磁盘IO使用率比Kafka低，CPU使用率比Kafka高；
2. TubeMQ的消费方式影响到系统的吞吐量，内存读取模式（301）性能低于文件读取模式（101），但能降低消息的时延；
3. Kafka随分区实例数增多，没有如期提升系统吞吐量；
4. TubeMQ按照Kafka等同的增加实例（物理文件）后，吞吐量量随之提升，在4个实例的时候测试效果达到并超过Kafka 5个分区的状态；TubeMQ可以根据业务或者系统配置需要，调整数据读取方式，可以动态提升系统的吞吐量；Kafka随着分区增加，入流量有下降；

5.2.2 【指标】

注1 : 如下场景中，均为单Topic测试下不同分区或实例、不同读取模式场景下的测试，单条消息包长均为1K;

5.3.1 【结论】

按照多Topic场景下测试：

1. TubeMQ随着Topic数增加，生产和消费性能维持在一个均线上，没有特别大的流量波动，占用的文件句柄、内存量、网络连接数不多（1k topic下文件句柄约7500个，网络连接150个），但CPU占用比较大；
2. TubeMQ通过调整消费方式由内存消费转为文件消费方式后，吞吐量有比较大的增长，CPU占用率有下降，对不同性能要求的业务可以进行区别服务；
3. Kafka随着Topic数的增加，吞吐量有明显的下降，同时Kafka流量波动较为剧烈，长时间运行存消费滞后，以及吞吐量明显下降的趋势，以及内存、文件句柄、网络连接数量非常大(在1K Topic配置时，网络连接达到了1.2W，文件句柄达到了4.5W)等问题；
4. 数据对比来看，TubeMQ相比Kafka运行更稳定，吞吐量以稳定形势呈现，长时间跑吞吐量不下降，资源占用少，但CPU的占用需要后续版本解决；

5.3.2 【指标】

注： 如下场景中，包长均为1K，分区数均为10。

5.4 场景四：100个topic，一入一全量出五份部分过滤出：一份全量Topic的Pull消费；过滤消费采用5个不同的消费组，从同样的20个Topic中过滤出10%消息内容

5.4.1 【结论】

1. TubeMQ采用服务端过滤的模式，出流量指标与入流量存在明显差异；
2. TubeMQ服务端过滤提供了更多的资源给到生产，生产性能比非过滤情况有提升；
3. Kafka采用客户端过滤模式，入流量没有提升，出流量差不多是入流量的2倍，同时入出流量不稳定；

5.4.2 【指标】

注： 如下场景中，topic为100，包长均为1K，分区数均为10

5.5 场景五：TubeMQ、Kafka数据消费时延比对

备注：TubeMQ的消费端存在一个等待队列处理消息追平生产时的数据未找到的情况，缺省有200ms的等待时延。测试该项时，TubeMQ消费端要调整拉取时延（ConsumerConfig.setMsgNotFoundWaitPeriodMs()）为10ms，或者设置频控策略为10ms。

5.6 场景六：调整Topic配置的内存缓存大小（memCacheMsgSizeInMB）对吞吐量的影响

5.6.1 【结论】

1. TubeMQ调整Topic的内存缓存大小能对吞吐量形成正面影响，实际使用时可以根据机器情况合理调整；
2. 从实际使用情况看，内存大小设置并不是越大越好，需要合理设置该值；

5.6.2 【指标】

注： 如下场景中，消费方式均为读取内存（301）的PULL消费，单条消息包长均为1K

5.7 场景七：消费严重滞后情况下两系统的表现

5.7.1 【结论】

1. 消费严重滞后情况下，TubeMQ和Kafka都会因磁盘IO飙升使得生产消费受阻；
2. 在带SSD系统里，TubeMQ可以通过SSD转存储消费来换取部分生产和消费入流量；
3. 按照版本计划，目前TubeMQ的SSD消费转存储特性不是最终实现，后续版本中将进一步改进，使其达到最合适的运行方式；

5.7.2 【指标】

5.8.1【结论】

1. TubeMQ在BX1机型下较TS60机型有更高的吞吐量，同时因IO util达到瓶颈无法再提升，吞吐量在CG1机型下又较BX1达到更高的指标值；
2. Kafka在BX1机型下系统吞吐量不稳定，且较TS60下测试的要低，在CG1机型下系统吞吐量达到最高，万兆网卡跑满；
3. 在SATA盘存储条件下，TubeMQ性能指标随着硬件配置的改善有明显的提升；Kafka性能指标随硬件机型的改善存在不升反降的情况;
4. CG1机型数据存储盘较小(仅2.2T)，RAID 10配置下90分钟以内磁盘即被写满，无法测试两系统长时间运行情况。

5.8.2 【指标】

注2: TubeMQ采用的是301内存读取模式消费；

6 附录

6.1.1 【BX1机型测试】

6.1.2 【CG1机型测试】

6.2 附录2 多Topic测试时的资源占用情况图：

6.2.1 【100个topic】

6.2.2 【200个topic】

6.2.4 【1000个topic】