为什么topic数量变多，kafka性能下降这么快，而RocketMQ不会？

RocketMQ和Kafka的存储核心设计有很大的不同，所以其在写入性能方面也有很大的差别，这是16年阿里中间件团队对RocketMQ和Kafka不同Topic下做的性能测试:  从图上可以看出： Kafka在Topic数量由64增长到256时，吞吐量下降了98.37%。 RocketMQ在Topic数量由64增长到256时，吞吐量只下降了16%。 这是为什么呢？ kafka一个topic下面的所有消息都是以partition的方式分布式的存储在多个节点上。同时在kafka的机器上，每个Partition其实都会对应一个日志目录，在目录下面会对应多个日志分段。 所以如果Topic很多的时候Kafka虽然写文件是顺序写，但实际上文件过多，会造成磁盘IO竞争非常激烈。 那RocketMQ为什么在多Topic的情况下，依然还能很好的保持较多的吞吐量呢？我们首先来看一下RocketMQ中比较关键的文件:  rocketmq中的消息主体数据并没有像Kafka一样写入多个文件，而是写入一个文件，这样我们的写入IO竞争就非常小，可以在很多Topic的时候依然保持很高的吞吐量。 有人可能说这里的ConsumeQueue写是在不停的写入呢，并且ConsumeQueue是以Queue维度来创建文件，那么文件数量依然很多，在这里ConsumeQueue的写入的数据量很小，每条消息只有20个字节，30W条数据也才6M左右，所以其实对我们的影响相对Kafka的Topic之间影响是要小很多的。 再顺便提一嘴，一个topic分了一万个partition和一万个topic每个topic都是单partition对于kafka的负载是一样的。