如何决定kafka集群中话题的分区的数量

http://blog.csdn.net/greenappple/article/details/50933872

 

如何决定kafka集群中topic,partition的数量，这是许多kafka用户常常遇到的问题。本文列举阐述几个重要的决定因素，以提供一些参考。

分区多吞吐量更高

    一个话题topic的各个分区partiton之间是并行的。在producer和broker方面，写不一样的分区是彻底并行的。所以一些昂贵的操做好比压缩，能够得到更多的资源，由于有多个进程。在consumer方面，一个分区的数据能够由一个consumer线程在拉去数据。分区多，并行的consumer（同一个消费组）也能够多。所以一般，分区越多吞吐量越高。

    基于吞吐量能够得到一个粗略的计算公式。先测量获得在只有一个分区的状况下，Producer的吞吐量(P)和Consumer的吞吐量(C)。那若是总的目标吞吐量是T的话，max(T/P,T/C)就是须要的最小分区数。在单分区的状况下，Producer的吞吐量能够经过一些配置参数，好比bath的大小、副本的数量、压缩格式、ack类型来测得。而Consumer的吞吐量一般取决于应用程序处理每一天消息逻辑。这些都是须要切合实际测量。

    随着时间推移数据量的增加可能会须要增长分区。有一点须要注意的是，Producer者发布消息经过key取哈希后映射分发到一个指定的分区，当分区数发生变化后，会带来key和分区映射关系发生变化。可能某些应用程序依赖key和分区映射关系，映射关系变化了，程序就须要作相应的调整。为了不这种key和分区关系带来的应用程序修改。因此在分区的时候尽可能提早考虑，将来一年或两年的对分区数据量的要求。

   除了吞吐量，还有一些其余的因素，在定分区的数目时是值得考虑的。在某些状况下，太多的分区也可能会产生负面影响。

 

分区多须要的打开的文件句柄也多

    每一个分区都映射到broker上的一个目录，每一个log片断都会有两个文件（一个是索引文件，另外一个是实际的数据文件）。分区越多所须要的文件句柄也就越多，能够经过配置操做系统的参数增长打开文件句柄数。

 

分区多增长了不可用风险

    kafka支持主备复制，具有更高的可用性和持久性。一个分区（partition）能够有多个副本，这些副本保存在不一样的broker上。每一个分区的副本中都会有一个做为Leader。当一个broker失败时，Leader在这台broker上的分区都会变得不可用，kafka会自动移除Leader，再其余副本中选一个做为新的Leader。Producer和Consumer都只会与Leader相连。

    通常状况下，当一个broker被正常关机时，controller主动地将Leader从正在关机的broker上移除。移动一个Leader只须要几毫秒。然当broker出现异常致使关机时，不可用会与分区数成正比。假设一个boker上有2000个分区，每一个分区有2个副本，那这样一个boker大约有1000个Leader，当boker异常宕机，会同时有1000个分区变得不可用。假设恢复一个分区须要5ms，1000个分区就要5s。

    分区越多，在broker异常宕机的状况，恢复所需时间会越长，不可用风险会增长。

 

分区多会增长点到点的延迟

    这个延迟须要体如今两个boker间主备数据同步。在默认状况下，两个boker只有一个线程负责数据的复制。

    根据经验，每一个boker上的分区限制在100*b*r内（b指集群内boker的数量，r指副本数量）。

 

分区多会增长客户端的内存消耗

    kafka0.8.2后有个比较好的特点，新的Producer能够容许用户设置一个缓冲区，缓存必定量的数据。当缓冲区数据到达设定量或者到时间，数据会从缓存区删除发往broker。若是分区不少，每一个分区都缓存必定量的数据量在缓冲区，极可能会占用大量的内存，甚至超过系统内存。

    Consumer也存在一样的问题，会从每一个分区拉一批数据回来，分区越多，所需内存也就越大。

    根据经验，应该给每一个分区分配至少几十KB的内存。

 

总结

     在一般状况下，增长分区能够提供kafka集群的吞吐量。然而，也应该意识到集群的总分区数或是单台服务器上的分区数过多，会增长不可用及延迟的风险。

 

     http://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/