| 估算 | 目标峰值吞吐 ÷ 单分区实测吞吐，向上取整并预留 2 倍余量 |
|---|---|
| 并行 | 消费者并行上限 = 分区数 |
| 成本 | 分区越多，controller 与元数据负担越重，端到端延迟可能上升 |
估算示例
估算示例
目标峰值：200 MB/s
单分区实测：约 10 MB/s（需按消息大小与副本实测）
候选分区数：200 / 10 = 20 → 预留余量取 40
消费者实例按 40 配置，避免超过分区数分区只能增加不能减少；增加会改变 key 到分区的映射，依赖同 key 有序的链路要评估。
分区数规划方法
分区数决定并行上限与元数据成本：按目标吞吐除以单分区参考能力估算，再留冗余；分区过多会拉长选举与元数据同步时间，过少则无法扩展。
易错点
- 照搬他人分区数而不做压测，遇到大消息或同步复制时依然会滞后
- 分区数与消费者实例长期不匹配（实例远多于分区）会造成资源浪费
数据来源与参考
- Apache Kafka 官方文档：Topics and Partitions 与运维实践