面试考察点
- 是否把分区与生产吞吐、消费并行度联系起来。
- 能否说明分区过多的控制面和恢复成本。
- 是否考虑扩分区对 Key 顺序和路由的影响。
核心答案
分区数至少要支撑目标生产吞吐和消费者并行度，可分别用总吞吐除以单分区实测能力估算并取较大值，再留合理增长余量。分区并非越多越好，过多会增加文件、元数据、选举、复制和故障恢复成本。
同一消费者组内，一个分区同一时刻最多分配给一个消费者；消费者数量超过分区数不会增加并行度。
规划维度
用接近生产的消息大小、压缩、acks、副本数和磁盘配置压测单分区能力。还要考虑峰值、保留周期、Broker 数量、每节点分区与副本分布以及故障时剩余容量。
用容量模型做初步估算
假设目标生产峰值为 200 MB/s，实测单分区在同等 acks、压缩和副本条件下可稳定写 10 MB/s，则生产维度至少需要 20 个分区；若消费组每个分区稳定处理 5 MB/s，消费维度需要至少 40 个分区。取较大值后再预留增长与故障余量，而不是照搬固定“每台机器 N 个分区”的经验。
这个模型只是起点。实际还会受消息大小分布、热点 key、Broker 磁盘、网络、复制、保留时长和消费者业务耗时影响，必须通过压测和线上监控持续校正。
分区过多的成本
每个分区和副本都有日志文件、索引、内存状态、复制 fetch、选举和恢复成本。大量小分区会增加 controller 元数据、Broker 启动时间、故障恢复时长和文件句柄压力；一次 broker 故障后，成千上万分区同时迁移或选举也会造成控制面风暴。
分区规划要保证任意一台 Broker 故障后，剩余节点仍能承受副本流量与分区数量。只按正常状态平均分布设计，故障时往往出现磁盘或网络过载。
消费者并行与业务耗时
消费者数上限受分区数约束，但增加消费者不一定提高吞吐：如果下游数据库连接池只有 20 个、每条消息需调用慢 HTTP，40 个消费者可能只会增加竞争和超时。并发规划需同时包含每分区拉取、应用处理线程、下游连接与限流。
若单个 key 极热，增加总分区无效，因为该 key 仍落在一个分区。需要拆分业务 key、分段聚合、单独 Topic 或改变处理模型。
扩分区前的检查清单
- 该 Topic 是否强依赖同 key 的历史顺序？
- 默认分区器扩容后 key 映射变化是否可接受？
- 客户端、ACL、配额、监控和副本均衡是否已准备？
- 新分区创建后消费者组如何再均衡，是否会造成短暂停顿？
- 是否有更直接的瓶颈，例如慢消费者、下游连接池或热点 key？
分区只能增加不能轻易减少，预留应适度而不是无限大。需要改变分区模型时，创建新 Topic、双写/回放并切换消费者通常更安全。
运维监控
持续观察每分区 bytes in/out、records、Lag、leader 分布、under-replicated partitions、磁盘、网络和请求延迟。平均 Topic Lag 健康不代表没有一个热点分区持续积压；应该按分区看 max、分位数与倾斜度。
扩容影响
Kafka 可以增加分区但通常不能直接减少。默认 Key 哈希取模在分区数变化后会重新映射，新旧消息可能不再处于同一分区，影响按 Key 顺序；需要版本化 Topic 或业务版本控制。
常见误区
只按当前消费者数量定分区会忽略生产吞吐和增长，预设极大分区数又会制造长期运维成本。分区不均还可能来自 Key 倾斜，单纯加分区不一定修复热点。
高频追问与参考回答
追问：积压时临时增加消费者为什么没效果？
如果消费者数已达到分区数，新增实例没有分区可分；还需评估单条处理耗时、下游容量，必要时增加分区并调整 Key 与顺序策略。
追问：分区数应该等于消费者数吗？
不必相等。分区还受生产吞吐、未来扩容、故障恢复和多个消费者组影响；消费者数可按当前处理能力伸缩，分区是更长期的存储与并行边界。
追问：为什么大消息会降低单分区吞吐？
大消息占用网络、页缓存、批处理和 GC，复制与重试成本也更高。应控制消息大小，把大对象放对象存储并发送引用，或调整批量与限制。
追问：如何处理分区倾斜？
分析 key 分布和分区流量，必要时给热点实体加二级分片、独立 Topic 或异步聚合；不能只反复重平衡 Broker，因为同 key 路由仍会形成热点。
总结
分区规划是吞吐、并行、顺序和运维成本的平衡，必须基于实测并提前设计扩容后的路由语义。
机制全景图
下面把「Kafka 分区数应该如何规划和扩容？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["估算目标吞吐"]
A --> B["测量单分区生产消费能力"]
B --> C["考虑消费者并行度"]
C --> D["加入故障与增长余量"]
D --> E["创建并监控分区分布"]
完整链路：从输入到结果
沿着「估算目标吞吐 → 测量单分区生产消费能力 → 考虑消费者并行度 → 加入故障与增长余量 → 创建并监控分区分布」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 估算目标吞吐
分区数下限取决于目标吞吐除以单分区生产或消费能力的较大需求。
2. 测量单分区生产消费能力
单分区能力必须用真实消息大小、压缩、acks 和磁盘网络测量，不能引用固定经验值。
3. 考虑消费者并行度
同组消费者并行上限受分区数限制，但分区过多会增加文件句柄、控制器和选举负担。
4. 加入故障与增长余量
需要为单 Broker 故障、流量增长和再分配保留余量，同时评估副本网络放大。
5. 创建并监控分区分布
上线后观察 Key 倾斜、分区字节和 Lag；增加分区不会自动重平衡历史数据，也可能影响 Key 顺序。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| kafka-log-dirs.sh | 分区字节分布 |
| BrokerTopicMetrics | 分区吞吐 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
partitions >= max(target_produce/single_partition_produce, target_consume/single_partition_consume)
用真实消息大小、压缩与 acks 测单分区上限，再注入单 Broker 故障。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「最大/平均分区流量」为主基线，记录值应满足「记录分区基线」；同时保存 单分区 bytes/sec、分区 Lag 偏斜，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「kafka-log-dirs.sh」确认请求确实进入「分区字节分布」对应的实现，再沿「BrokerTopicMetrics」观察「分区吞吐」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「按峰值 QPS 除经验常数拍分区数」，并把单一变量逐级放大，直到「最大/平均分区流量」越过「超过基线 2 倍」。随后再分别验证「Key 倾斜让平均容量失真」和「增加分区破坏既有顺序映射」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「按实测规划并留故障余量」，确认它能控制影响范围；第二轮应用「顺序 Topic 扩容前迁移」，验证核心链路恢复；最后落实「Leader 均衡」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「最大/平均分区流量」回到「记录分区基线」、「P99 延迟」回到「小于业务预算」、「端到端差异」回到「0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| 最大/平均分区流量 | 记录分区基线 | 超过基线 2 倍 | 倾斜 |
| P99 延迟 | 小于业务预算 | 突破预算 | 倾斜 |
| 端到端差异 | 0 | 任意非零 | 停止并对账 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：Topic 分区翻倍后同用户顺序被打乱
默认哈希取模因分区数变化而改变 user_id 映射，新消息进入新分区，与旧消息并行消费。扩容前应评估顺序域、使用版本裁决或新 Topic 迁移。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 按峰值 QPS 除经验常数拍分区数 | 单分区 bytes/sec | 按实测规划并留故障余量 |
| Key 倾斜让平均容量失真 | 分区 Lag 偏斜 | 顺序 Topic 扩容前迁移 |
| 增加分区破坏既有顺序映射 | Broker 网络/磁盘 | Leader 均衡 |
发布与回滚检查点
- 发布前：确认「kafka-log-dirs.sh」对应实现和上述配置在目标版本仍然有效，并保存「最大/平均分区流量」基线。
- 灰度中：同时观察 单分区 bytes/sec、分区 Lag 偏斜、Broker 网络/磁盘；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「按实测规划并留故障余量」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「按峰值 QPS 除经验常数拍分区数」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 少量大分区 | 吞吐不高且顺序域集中 | 管理简单 | 扩容和并行余量小 |
| 按容量预留分区 | 增长可预估 | 减少频繁扩分区 | 空分区和元数据成本 |
| 新 Topic 迁移 | 需改变分区策略或大幅扩容 | 可灰度并保持旧规则 | 双写、切换与回放复杂 |
选型至少带上 消息速率、峰值带宽、分区数、消息大小和积压恢复时间，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
分区是吞吐、顺序和运维开销的共同单位；规划要保留增长余量，但不能把“越多越好”当成扩展策略。
工程落地遵循：可靠性来自生产、Broker、消费和业务幂等的完整闭环。回答时直接引用「kafka-log-dirs.sh」、配置实验和事故数据，比复述固定模板更有说服力。