分区数决定什么
分区数同时决定三件事：主题的并行上限（消费组内有效消费者数不会超过分区数）、单分区顺序性的边界（同 key 落同一分区才有序），以及集群的元数据成本。分区太少，消费者加机器也上不去；分区太多，controller 与元数据同步负担加重，故障时的 leader 选举、副本重平衡都会变慢。所以分区数要按实测吞吐估算并留余量，而不是照抄别人的数字。
基本信息
| 估算方法 | 目标峰值吞吐 ÷ 单分区实测吞吐，向上取整并预留 2 倍余量 |
|---|---|
| 并行上限 | 消费组内有效并行度 = 分区数 |
| 成本侧 | 分区越多，元数据与 controller 负担越重 |
| 变更限制 | 分区只能增加不能减少 |
典型使用场景
- 新主题上线前的容量规划：按预期峰值与压测结果定分区数
- 消费者扩容无效时排查：先确认分区数是否已成为上限
- 压测验证：用 kafka-producer-perf-test 测单分区真实吞吐
- 链路扩容前评估：分区变更会影响 key 分布，需评估下游排序依赖
- 集群治理：盘点分区规模，控制元数据总量与运维复杂度
估算与创建
估算与创建
# 1) 先压测单分区真实吞吐（消息大小与副本数都会影响结果）
kafka-producer-perf-test.sh --topic bench --num-records 1000000 \
--record-size 1024 --throughput -1 --producer-props bootstrap.servers=localhost:9092
# 2) 按估算结果创建主题：目标峰值 200MB/s ÷ 单分区约 10MB/s = 20，留余量取 40
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders \
--partitions 40 --replication-factor 3
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders # 核对分区与副本分布规划参考
| 维度 | 偏小时的表现 | 偏大时的表现 |
|---|---|---|
| 吞吐能力 | 消费积压，加消费者无效 | 单分区负载低，资源利用率差 |
| 元数据开销 | 负担轻，操作快 | controller 与元数据同步变慢 |
| 故障恢复 | 重平衡快 | leader 选举与恢复时间变长 |
| 顺序性 | 同 key 更集中，易热点 | key 分散，单分区有序性更细 |
分区只能增加不能减少；增加分区会改变 key 到分区的映射，依赖「同 key 有序」的链路（如按订单号聚合）必须重新评估，否则会出现同一 key 的历史与新增数据落在不同分区。
单分区吞吐没有通用数字：消息大小、是否压缩、副本数与确认级别都会显著影响结果，容量规划必须用接近生产特征的数据压测，参考值只能作为起点。