kafka分区数过多引发的弊端kafka分区越多越好吗理论上, 一个topic的分区越多, 整个集群所能达到的吞吐量就

kafka分区越多越好吗

客户端 producer 有个参数 batch.size 默认为 16KB。它会为每个分区缓存消息, 一旦批次数满了后, 将消息批量发出。
一般来说, 这个设计是用于提升吞吐性能的。但是由于这个参数是partition级别的(topic -> batchSize)如果分区数越多, 这部分缓存所需的内存占用也会越多。
假如有 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。这样的延迟对于一些实时业务来说可能就有些长了。

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%的问题。当然正常情况, 还是得在合理的成本范围内, 进行合理的规划和调优, 上述弊端一般都是能在可控范围内的。