如何选择一个Kafka集群中的主题分区的数量

Kafka集群中分区应该设置多少比较合适，这是一个面对众多开发者共同的难题，这篇文章的目标就是来解释一些重要的因素，同时会提供一些简单的公式。

更多的分区可使吞吐量更大

首先我们要有个认知，那就是分区(partition)是Kafka中的并发单位。
从生产者和Broker层面来说，写入消息到不同的分区是一种完全的并发行为，所以例如压缩等重量级操作，可以使用更多的硬件资源来解决。
在消费者层面，Kafka总是将单个分区的数据交由一个消费线程进行消费，因此，在消费者侧的并发程度是由消费的分区数量约束的。
由上述总结可知，通常情况下在Kafka集群内，更多的partition能够获得更大的吞吐量。

通过如下公式可以根据吞吐量粗略的预估出需要创建多少个分区。首先你需要可以获得单个分区的生产量，我们使用字母p表示，消费量用c表示，比如说你的目标吞吐量为t，那么你则需要至少max(t/p,t/c)个分区。每个分区吞吐量依赖于生产者的配置，如批处理条数、压缩编码、已知的类型。副本因素等等。但是通常一个生产者在基准测试中的表现能达到10MB/sec，消费者的吞吐量取决于应用程序，消费者的速度与每条消息的处理逻辑相关，因此消费者的消费速度需要你自行进行基准测试。

尽管可以随着时间不断增加分区数量，但是如果生成带有key的消息，则必须注意。 发布送带有key的消息时，Kafka根据key的哈希确定将消息映射到哪个分区。 这保证了具有相同key的消息始终被路由到相同的分区。对于某些应用程序，此种特性可能很重要，因为每个分区内消息总是被顺序递送的，也就是同一个分区那么消费者可以做到顺序消费。如果分区数量改变，那么可能会打破原有的顺序消费逻辑，从而这种保证也不再成立。为了避免这种情况，一般采用对分区过度分区，你可以决定未来一两年的吞吐量，从而确定分区数。一开始你可以只拥有一个基于你当前团兔粮的小型kafka集群，随着时间增长，你可以成比例地增加broker到你的现有的及群众，并将部分已存在的分区移动至新的broker中，这个方法在保持你吞吐量增长的同时，不会破坏你在程序中对消息key的使用。

更多的分区需要更多文件句柄

每个分区均会在broker所在的文件系统中映射一个文件目录，在日志目录内，每个日志段将会有个两个文件，一个是索引文件，另一个是实际的数据。当前，在kafka中broker会打开每个日志段的索引文件和数据文件句柄，因此分区越多，则在底层操作系统中配置文件句柄限制就需要越高。

更多的分区增加不可用性

Kafka集群内部支持副本分片，从而达到高可用和持久性，一个分区可以有多个副本，每个都存储在不同的borker上，副本中一个被指定为leader且其他副本将会成为follower，kafka管理所有的那些副本的复制并确保副本之间的同步，所有的生产者和消费者所发送的请求均是由leader副本进行服务的，当broker宕机，在这个broker上的leader副本将短暂不可用，kafka将会自动移动不可用分区的leader角色副本到其他副本上，继续提供服务。这个处理有kafka的broker中控制角色进行制定，它涉及为ZooKeeper中每个受影响的分区读写一些元数据。 当前，对ZooKeeper的操作是在控制器中串行完成的。

更多的分区更高的端到端的延迟

在kafka中我们定义，从生产者发送消息到消费者准备消费所用的时间为端到端延迟。kafka只会在提交(commit)消息之后再想消费者发送消息，也就是当消息在所有副本中同步之后才会提交消息，因此提交一个消息的花费时间可能是端到端延迟的很大一部分时间。默认情况下，对于只有两个broker的所有分区来说，broker仅仅使用一个单线程复制数据到另一个broker的副本中。我们实验表明，从一个broker复制1000个分区到另一个broker会花费大概20ms的时间，这意味着最短就是20ms。

更多的分区需要更多的内存