Kafka的partition数量过多有什么问题

原文：https://www.confluent.io/blog/how-choose-number-topics-partitions-kafka-cluster/

为了提高kafka的吞吐量，增加parition的数量，提升生产消费并行数是个不错的选择。但partition数量也不是越多越好，以下是partition数量太多可能导致的问题，供大家选择partition数量时参考。

1、partition数量该如何选择：

假设一个partition的生产速度是p， 消费速度是c。而你预期的消息吞吐速度是t。则partition的数量至少为max(t/p, t/c) 。

生产速度取决于你的config参数，比如linger_ms, batch_size,  replication factor, type of ack。 而消费速度则取决于你自身的消费逻辑。

 

2、太多的partition需要打开更多文件句柄

每个partition在broker的文件系统上都映射着对于的文件夹。 在文件夹里面，每个segment（partition下的存储单位）会有两个文件，一个是索引，另一个是消息数据。  每个broker都会为每个segment打开两个文件句柄。所以如果parition太多的话，你就需要在操作系统里配置下可以同时打开的文件句柄数以使得可以支撑如此之多的segment。曾经见过一个kafka集群，里面的broker平均同时打开了30000多个句柄（约15000个分区）。

 

3、太多的partition导致可用性降低

一个partition对应着多个副本。在一个broker优雅退出时，集群的controller会提前地将该broker上的leader迁移到其他broker上。 迁移一个leader只需要几毫秒的时间，所以从客户端角度来说，这只会有一小段时间不可用（只在迁移时的时间不可用，毫秒级）

然而如果一台broker是被粗暴的退出了，那不可用时间就取决于partition的数量了。 假设现在有个broker有2000个partition， 每个partition有两个副本，那这个broker大概有1000个leader。 如果这个broker被粗暴退出了，那这1000个partition马上不可用。如果每个分区需要花5ms的时间去选择一个新的leader，则1000个分区需要花费5s。所以，对于其中的partition来说，他们之中最长的不可用时间是5s加上检测出broker挂的时间。

如果更加不幸，这个挂了的broker是集群的controller，那它还需要先在集群里选举一个新的controller后才能进行leader迁移。新的controller还需要从zookeeper（新版kafka已经不从zk里读取）读取metadata。如果一个分区需要2ms，假设一个集群里有10000个partition，那这里将有20s的不可用时间。

建议：一个broker下的partition数量限制在2000-4000，整个集群的partition数量不高于一万。

4、太多的partition增加了消息的延迟

消息的延迟指的是一条消息从生产者发送到被消费者消费的时间差。 Kafka只会把已经被所有副本复制成功的消息下发给消费者。而kafka的broker只使用单线程去从其他broker里复制消息。 我们实验表明从一个broker复制1000个partition到另一个broker会增加约20ms的延时。 如果复制因子设置为2，那这个问题在一个大集群里不会很明显。 假设现在有一个broker里有1000个leader， 集群里还有另外10个broker。 其他的10个broker平均只需要从第一个broker里获取100个partition的信息，因此，这种情况下的延时就非常小，一般只有几ms。

建议：每个broker下的partition数量应该限制为100*b*r，b是集群里的broker数量，r是复制因子。

5、太多的partition使得客户端需要占用更多的内存

生产者会给每个partition申请一份内存空间用以缓存将要发送但还没发送的数据。这种批量发送的方式能够减少网络交换次数，提高发送的效率。但如果你的partition太多，则生产者需要更多个内存来缓存将要发送的消息。

消费者也一样，消费者也可以从partition里批量拉取消息，分区越多，则拉取消息占用的内存越多。