面试题：Kafka的吞吐量和性能为什么那么好？以及Topic或者分区多了之后，会有什么问题？

最新推荐文章于 2024-05-12 14:08:32 发布

全球潮人

最新推荐文章于 2024-05-12 14:08:32 发布

阅读量556

点赞数 9

分类专栏：面试题文章标签： kafka 分布式

本文链接：https://blog.csdn.net/qq_26432153/article/details/138010537

版权

面试题专栏收录该内容

7 篇文章 0 订阅

订阅专栏

题目来源

阿里-技术-1面

题目描述

Kafka的单个Broker上的Topic或者分区多了之后，会有什么问题？

我的回答

没了解过

更好的答案

一般来说，我们需要基于单个Broker来评判这个问题，因为在集群中，10个分区分布在10个Broker上，是不会有性能问题的。下面就针对单个Broker来讨论下Topic或者Broker多了，会有什么问题。

结论

Kafka Broker利用了磁盘的顺序读写的特性，以及Linux的Page Cache功能，所有会有很高的QPS和吞吐量。
Kafka的Topic或者分区多了，会导致性能下降。我有在网上查找相应的测试数据，当分区数在1000至2000的时候，消费者和生产者的TPS都会处于比较高的水平，生产者的TPS比10W低一点，消费者的速度会比10W高很多，如下图所示
在这里插入图片描述

为什么会这样呢？

Kafka的每一个分区对应着一个文件，当分区数少的时候，没有产生消息积压的情况下，生产者发送消息之后，Kafka使用零拷贝技术，直接将该消息持久化到磁盘，但是不是直接写入到磁盘，而是写入到Linux的Page Cache，Page Cahe还是操作系统的内存，如果此时消费者来消费消息，Kafka向操作系统请求读取该消息，操作系统发现该消息还在Page Cache中，就直接将该消息返回给Kafka，在上述流程中，消息没有经过磁盘，就直接到达消费者，速度非常快。
在这里插入图片描述

Linux操作系统的Page Cache是使用的内存，但是如果Partition的数量过多，使用的Page Cache就会变多，Linux在使用Page Cache的时候，一般不会超过操作系统的的总内存的10%，超过10%了，就会采取LRU的淘汰策略对某些Page进行淘汰，将淘汰的Page刷到磁盘上面去。这时性能就下降了。