3. Topic与Partition规划
在 Kafka 中，Topic 是逻辑概念，Partition 才是并行与存储的物理单元。分区数一旦确定，后续调整代价很高：增加分区会触发分区重分配与消费者组再平衡，减少分区几乎不可行。因此，分区规划是容量治理中最需要前置决策的一环。本节围绕四个问题展开：分区数怎么估算、分区如何分布、热点如何识别、再平衡为什么影响性能。
一、分区数估算：从吞吐与并行度反推
分区数的本质约束来自两端：生产者端要能并行写入，消费者端要能并行消费。估算时先看单分区吞吐能力。经验上，单个分区在普通机械盘上顺序写可达 50～100 MB/s，SSD 上更高；但真实瓶颈往往在副本同步、网络和页缓存。保守估算可取单分区有效写入 10～30 MB/s 作为规划基线（示例假设值，需按实际压测修正）。
设目标峰值写入吞吐为 T（MB/s），单分区有效吞吐为 t，则分区数下限为：
P_min = ceil(T / t)
示例：T = 600 MB/s，t = 20 MB/s
P_min = ceil(600 / 20) = 30 个分区再看消费者并行度。若消费者线程数为 C，分区数应不小于 C，否则会有线程空闲。通常取 P = max(P_min, C)，并预留 20%～50% 余量应对突发流量。但分区不是越多越好：每个分区对应一组文件句柄、一段索引和一次副本同步开销，分区过多会拉长 Controller 元数据管理和再平衡时间。经验上单 Broker 承载分区数控制在 2000～4000 以内较为稳妥。
二、分区分布策略：副本与 Leader 的均衡
分区分布包含两层：分区在 Broker 间的分配，以及副本的摆放。Kafka 默认使用轮询方式将分区均匀分配到 Broker，并把每个分区的副本分散到不同 Broker 上，避免同一分区的多个副本落在同一台机器。关键原则是：Leader 要均衡、副本要分散、机架要隔离。
如果 Broker 数量为 B，分区数为 P，副本因子为 R，则每个 Broker 平均承载 P/B 个分区、P×R/B 个副本。当 P 不能被 B 整除时，会出现少量 Broker 多承担一两个分区，这属于正常范围。真正需要警惕的是人为指定副本分配导致的倾斜，例如所有分区 Leader 集中在少数 Broker 上。
三、分区热点识别：从指标到根因
分区热点指某些分区的流量、存储或请求量显著高于其他分区。识别热点主要看三类指标：
- 字节速率：用
kafka-log-dirs.sh或 JMX 的BytesInPerSec按分区维度观察，若某分区持续高于均值 3 倍以上，即为写入热点。 - 消息条数：条数不均往往源于 Key 设计问题，例如用用户 ID 做 Key 时大客户集中。
- 请求延迟：热点分区所在 Broker 的
RequestQueueTimeMs会明显升高，拖慢同 Broker 上其他分区。
热点根因通常有三类：一是 Key 分布倾斜，二是分区数过少导致单分区承载过高，三是副本分配不均导致某 Broker 磁盘 IO 饱和。定位时先看分区级指标，再对照 Key 分布和副本分布。
四、再平衡对性能的影响
再平衡分两种：消费者组再平衡和分区重分配。消费者组再平衡由成员增减触发，期间所有消费者暂停消费，分区数越多、成员越多，再平衡耗时越长。分区重分配由运维操作触发，会跨 Broker 迁移副本数据，占用大量网络和磁盘带宽。
再平衡期间典型现象是消费延迟（Lag）快速上升、生产端 P99 延迟抖动。控制影响的手段包括：使用静态成员（group.instance.id）减少非必要再平衡；用 StickyAssignor 或 CooperativeStickyAssignor 减少分区迁移量；分区重分配时用 kafka-reassign-partitions.sh 配合限流参数 --throttle，避免打满带宽。
五、可参考的分区规划检查表
| 检查项 | 判断依据 | 建议动作 |
|---|---|---|
| 分区数下限 | 峰值吞吐 / 单分区有效吞吐 | 向上取整并预留 20%～50% |
| 消费者并行度 | 分区数 ≥ 消费者线程数 | 不足时增加分区 |
| Leader 均衡 | 各 Broker Leader 数差异 ≤ 1 | 用 kafka-preferred-replica-election.sh 修正 |
| 副本分散 | 同一分区副本不在同一 Broker | 调整副本分配策略 |
| 热点分区 | 单分区流量 > 均值 3 倍 | 检查 Key 分布，必要时增加分区 |
| 再平衡频率 | 非计划再平衡频繁发生 | 启用静态成员与协作式分配器 |
分区规划不是一次性的静态决策，而是随业务增长持续校准的过程。建议在容量治理中把分区级指标纳入常规监控，当热点或再平衡频率超过阈值时，及时评估是否需要调整分区数或副本分布，避免问题积累到影响整体吞吐。