【问题标题】：How to choose the no of partitions for a kafka topic?如何选择 kafka 主题的分区数？
【发布时间】：2018-10-20 15:39:21
【问题描述】：

我们有 3 个 zk 节点集群和 7 个代理。现在我们必须创建一个主题，并且必须为这个主题创建分区。

但是我没有找到任何公式来决定我应该为这个主题创建多少分区。生产者速率为 5k 消息/秒，每条消息大小为 130 字节。

提前致谢

【问题讨论】：

5k 消息/秒来自单个生产者？还是来自所有可能的生产者的所有线程（假设不止一个）？
@cricket_007 感谢您的回复。我们有 5 个生产者，每秒产生 5k 条消息。
那么你的密钥分配呢？空键？一些已知值？
@cricket_007 感谢您的回复。先生，我们没有为分区指定任何键。是的.. 空键。
所以，5 个生产者将只是轮询，无论多少分区都可以，这意味着，如果您运行网络基准测试，假设您从生产者网卡获得 1Gbps 输出，那么您可以发送到每秒 1G/(5k*130) 字节...如果您想优化生产吞吐量，请继续使用该数学运算，请记住主题的消耗量比生产量多，因此您不想使代理饱和仅产生消息的网络接口

标签： apache-kafka kafka-consumer-api kafka-producer-api

【解决方案1】：

例如，如果您希望能够读取 1000MB/秒，但您的消费者只能处理 50MB/秒，那么您需要至少 20 个分区和 20 个消费者组中的消费者。同样，如果要为生产者实现相同的目标，而 1 个生产者只能以 100 MB/秒的速度写入，则需要 10 个分区。在这种情况下，如果您有 20 个分区，则可以维持 1 GB/秒的速度来生产和消费消息。您应该根据消费者或生产者的数量调整确切的分区数，以使每个消费者和生产者都达到其目标吞吐量。

所以一个简单的公式可以是：

#Partitions = max(NP, NC) 其中：

NP 是通过计算确定的所需生产者数量：TT/TP

NC 是通过计算确定的所需消费者数量：TT/TC

TT 是我们系统的总预期吞吐量

TP 是单个生产者对单个分区的最大吞吐量

TC 是单个分区中单个消费者的最大吞吐量

来源：https://docs.cloudera.com/runtime/7.2.10/kafka-performance-tuning/topics/kafka-tune-sizing-partition-number.html

【讨论】：

【解决方案2】：

您可以选择分区数等于 {throughput/#producer ;吞吐量/#consumer}。吞吐量按每秒消息量计算。在这里你有：吞吐量 = 5k * 130bytes = 650MB/s

【讨论】：

这是 650 KB/s，而不是 650 MB/s。

【解决方案3】：

Kafka 联合创始人的这个旧基准非常适合理解规模的大小 - https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines

由此得出的直接结论，如 Vanlightly said here，是消费者处理时间是决定分区数量的最重要因素（因为您无法挑战生产者吞吐量）。

消费的最大并发是分区的数量，所以你要确保：

（（一条消息的处理时间，以秒为单位 x 每秒的消息数） / 分区数）

如果它等于 1，你不能读比写快，这还不包括消息的爆发和消费者的失败\停机时间。所以你需要它显着低于 1，显着程度取决于你的系统可以承受的延迟。

【讨论】：

【解决方案4】：

分区 = 最大值（NP，NC）

地点：

NP 是通过计算确定的所需生产者数量：TT/TP NC 是通过计算确定的所需消费者数量：TT/TC TT 是我们系统的总预期吞吐量 TP 是单个生产者对单个分区的最大吞吐量 TC 是单个分区中单个消费者的最大吞吐量

【讨论】：

【解决方案5】：

这取决于您所需的吞吐量、集群大小、硬件规格：

Confluent 的 Jun Rao 写了一个明确的博客： How to choose the number of topics/partitions in a Kafka cluster?

这可能有助于深入了解： Apache Kafka Supports 200K Partitions Per Cluster

【讨论】：

【解决方案6】：

我不能给你一个明确的答案，有很多模式和限制会影响答案，但这里有一些你可能需要考虑的事情：

并行度的单位是分区，所以如果你知道每条消息的平均处理时间，那么你应该能够计算出要跟上所需的分区数。例如，如果每条消息需要 100 毫秒来处理，而您每秒收到 5k，那么您至少需要 50 个分区。再增加一个百分比，以应对峰值和可变的基础架构性能。排队论可以为您提供计算并行需求的数学方法。
您的流量有多突发，您有哪些延迟限制？考虑到最后一点，如果您也有延迟要求，那么您可能需要扩展分区以应对峰值流量。
如果您使用任何数据位置模式或需要对消息进行排序，那么您需要考虑未来的流量增长。例如，您处理客户数据并使用您的客户 ID 作为分区键，并依赖于每个客户始终被路由到同一个分区。也许是为了事件溯源，或者只是为了确保以正确的顺序应用每个更改。好吧，如果您稍后添加新分区以应对更高的消息率，那么每个客户现在可能会被路由到不同的分区。由于客户存在于两个分区上，这可能会带来一些关于保证消息排序的问题。所以你想为未来的增长创建足够的分区。请记住，这很容易向外扩展和在消费者中使用，但分区需要一些规划，因此请注意安全并面向未来。
拥有数千个分区会增加整体延迟。

【讨论】：

是50个分区还是500个？
根据数学应该是 500。