我们经常会面临这样的问题，在确定某个topic下应该设置多少分区数，有时并不知道应该如何设置，如何评估等。或者别人问你当前kafka集群中，具体的业务topic中分区数是多少，是如何知道需要多少分区或怎么选择比较适合的分区数。

1.结合业务场景和非业务条件

那么我们应该如何选择合适的分区数呢?

具体的业务具体分析。

但是前期我们可以根据这些条件：实际业务场景(消息总量，消息生产或消费频率，要求的吞吐量等)、软件条件、硬件条件、负载情况等，进行大致的评估我们可以设置topic多少分区数。

2.使用压测工具，得出最佳分区数

kafka官方也提供了脚本方便我们针对我们的kafka集群做测试，我们可以测试当前提供的硬件条件进行压测，得出当前机器环境到底能支持多少分区数，从而达到尽量最优的方案。

生产者性能测试脚本：kafka-producer-perf-test.sh

消费者性能测试脚本：kafka-consumer-perf-test.sh

设置好topic的某个分区数，之后我们可以选择不同的参数：比如消息发送总量、单条消息大小、吞吐量、acks、消费线程数等等，这样压测之后就能得出一份测试报告，报告包含的数据有：50%/90%/95%/99%的消息处理耗时、平均处理耗时、每秒消息发送吞吐量、每秒拉取的消息的字节大小/消息数量、消费总数、再平衡时间、按消息计数/消息大小计算的吞吐量等等。

合适的增加分区数是可以提高吞吐量，但超过一定的阈值之后，吞吐量也会随之下降。如果生产上对吞吐量有一定的要求，可以在生产机器硬件条件下进行压测，得出适合你的最优分区数。

3.吞吐量越高并不会一直与分区数有关

对kafka生产者而言，数据写入每个分区是可以并行进行的。对kafka消费者而言，每个分区只能给一个消费者线程消费，所以消费组的消费并行度依赖于分区数。这样看来好像分区数越多，理论上吞吐量应该越高。

但是，事实真的是这样吗?

消息中间件kafka的吞吐量并不只是跟分区有关。

消息写入(生产)的吞吐量与这些有关：消息大小、消息压缩方式、消息发送方式(同步或异步)、消息确认类型acks、副本因子等。

同样，消息消费的吞吐量与业务逻辑消费速度等有关。

4.分区数与操作系统有关

分区数也不能无限制的增加，因为其占用了文件描述符，进程可支配的文件描述符是有限的。

一般如果要设置比较大的分区数，要特别留意是否超过系统的最的大描述符文件。虽然可以通过改系统配置，但是应尽量避免这种，毕竟文件句柄也是有开销的。

5.注意消息写入分区策略

我们知道消费写入哪个分区，默认或者有些会根据Key计算其应写入哪个分区，这个时候就要考虑与Key较强关联的应用是否会影响你的使用场景。

比如有些应用场景可能只是要求某个分区内消息有序，如果一旦调整分区数，就有可能影响这种使用场景。

所以我们一般会尽量配置较好的分区数，尽量满足未来2年内目标的吞吐量。

如果与Key关联较弱的应用，我们可以在未来根据实际情况进行增加分区数。