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