kafka 分区数过多引发的弊端

点击上方蓝字“极客运维”一起运筹帷幄

上篇文章我们了解到，如果一个 topic 分区越多，理论上整个集群所能达到的吞吐量就越大。那么，分区数越多就越好吗？显然不是。今天我们来聊下 kafka 在分区数过多的情况下，会带来哪些弊端。

内存开销

客户端 producer 有个参数 batch.size 默认为 16KB。它会为每个分区缓存消息，一旦批次数满了后，将消息批量发出。一般来说，这个设计是用于提升吞吐性能的。但是由于这个参数是 partition 级别的，如果分区数越多，这部分缓存所需的内存占用也会越多。

假如有 10000 个分区，按照默认配置，这部分缓存就要占用约 157MB 的内存。而 consumer 端呢？抛开拉取数据所需的内存不说，单说线程的开销。如果还是 10000 个分区，同时 consumer 线程数要匹配分区数的话(大部分情况下是最佳的消费吞吐量配置)，那么在 consumer client 就要创建 10000 个线程，也需要创建大约 10000 个 Socket 去获取分区数据，这里面的线程切换的开销本身就已经不容小觑了。

服务器端的开销也不小，如果阅读 kafka 源码的话就会发现，服务器端的很多组件在内存中维护了 partition 级别的缓存，比如 controller ， FetcherManager 等，因此分区数越多，这种缓存的成本就越大。

文件句柄开销

每个分区在文件系统上会对应一个目录，用于存储维护 kafka 数据日志。该目录通常会有 3 个文件， .log ， .index ， .timeindex ，对应 kafka 的日志数据文件和索引文件(老版本 kafka 没有 timeindex 文件)。 broker 会一直保持打开这 3 个文件句柄( file handler )。因此，如果分区数越多，所需要保持打开状态的文件句柄数也就越多，最终可能会突破单台 broker 的 ulimit -n 的上限。

链路延迟

kafka 的链路延迟也就是 producer 端发布消息到 consumer 端接收消息所需要的时间。 kafka 只有在消息提交之后，才会将消息暴露给消费者，期间消息需要在 in-sync 副本列表中完成同步复制，这是耗时的主要部分。默认情况下，每个 broker 从其他 broker 节点进行数据副本同步时，该节点只会为此分配一个线程，该线程需要完成该 broker 上所有 partition 数据的复制。我查到数据显示，将 1000 个 partition 从一个 broker 到另一个 broker 所需时间延迟约为 20ms，这意味着链路延迟至少是 20ms。这样的延迟对于一些实时业务来说可能就有些长了。

SLA

kafka 是通过副本机制(replica)提供高可用，来保障 SLA 的。每个 partition 都会有多个副本，每个副本分别存在于不同的 broker 。所有的数据副本中，有一个数据副本被选举为 leader ，负责处理 producer 和 consumer 请求。其他的数据副本为 follower ，由 Kafka controller 负责保证与 leader 的同步。

当 leader 不可用时，会从 follower 中重新选出新的 leader ，这中间会有短暂的不可用时间，虽然大部分情况下可能只是几毫秒级别。但是假如，一个 2 节点的 kafka 集群中存在 2000 个 partition ，每个 partition 拥有 2 个副本。当其中一个 broker 意外宕机，所有 1000 个 partition 同时变得不可用。假设每一个 partition 恢复时间是 5ms，那么 1000 个 partition 的恢复时间将会花费 5 秒钟，这可能对用户来说就会有一个明显的感知了。如果宕机的是 controller 节点，不可用时间将会更严重。

上述问题，通常情况下，都可以通过扩容集群来缓解，毕竟在不考虑成本的情况下，堆机器可以解决 90%的问题。当然正常情况，还是得在合理的成本范围内，进行合理的规划和调优，上述弊端一般都是能在可控范围内的。

相关推荐：