消息队列分区数如何规划？
简化版
分区数至少满足目标吞吐与消费并行度，并为增长留余量，但不是越多越好。可用 max(生产峰值/单分区生产能力, 消费峰值/单分区消费能力) 估算下限，再结合 Broker 资源、顺序 key、故障恢复时间和扩分区迁移风险确定。
详细版
先用与真实消息大小、压缩、acks 和副本数一致的压测得到单分区能力，再按峰值和安全系数计算。消费者实例数超过分区数不会增加同组并行度；热点 key 即使分区多也可能集中在一个分区，需要检查 key 分布。
分区增加会增加文件、复制、选主、元数据和 Rebalance 成本，而且常会改变 hash(key)%N 路由，破坏扩容窗口内同 key 顺序。上线前规划增长区间，扩容采用兼容路由或版本化 Topic，并监控分区吞吐、lag 和倾斜。
完整版教学
一、分区承担什么职责
分区既是日志存储与复制单元，也是消费组的并行单位和局部顺序边界。规划时要同时满足写入、消费和顺序，而不能只按 Broker 磁盘容量决定。
记忆钩子：分区数决定并行上限，也决定运维对象数量和顺序边界。
二、吞吐下限公式
P_write = peak_produce / tested_partition_produce
P_read = peak_consume / tested_partition_consume
P_min = ceil(max(P_write, P_read) * safety_factor)生产峰值 120MB/s，单分区实测 15MB/s，需要 8 个；消费单分区 8000 条/s、峰值 8 万条/s，需要 10 个。取 1.5 安全系数，初始至少约 15 个，再取便于部署的 16。
三、为什么必须真实压测
1KB 与 1MB 消息、acks=1 与多数确认、压缩开关会显著改变能力。压测还要包含副本同步、消费者反序列化和下游写入，不能照搬产品宣传 QPS。
| 因素 | 分区能力影响 |
|---|---|
| 消息变大 | 字节吞吐先饱和 |
| 副本增多 | 网络/磁盘增加 |
| 强 ACK | 延迟上升 |
| 批量压缩 | 吞吐提高、延迟增加 |
四、消费并行与热点
同一消费组 16 个分区最多约 16 个活跃分区消费者；部署 30 个实例会有空闲成员。若 40% 消息使用同一 key，该 key 所在分区仍可能先打满，平均流量正常也不能证明均衡。
应观察分区级 bytes、records、lag、leader CPU 和 key 分布。热点业务 key 只有在不变量允许时才能拆分。
五、分区过多的成本
更多分区意味着更多日志段、索引、复制连接、leader 选举和元数据；Broker 重启与故障恢复可能变慢。客户端也需维护更多 fetch 状态，Rebalance 搬迁对象增多。
容量还要按 N-1 等故障模型核算：一台 Broker 下线后，其 leader 与副本流量会转移到其余节点，正常态刚好够用的集群无法安全恢复。
例如每个 Topic 从 16 扩到 200，而集群有 1000 个 Topic，会从 1.6 万增长到 20 万个分区，控制面压力不是线性“免费容量”。
六、扩分区为何影响顺序
从 8 变 16 后，hash(key)%N 结果可能改变；旧分区尚有消息时，新消息已进新分区，同 key 会并行消费。可停写排空、使用显式路由表，或新建版本 Topic 后迁移。
分区通常只能增加不能无损减少，因此初始要留余量，也不能一次过度配置。变更后核对 key 路由、lag 和消费者分配。
若预计很快跨越当前分区上限，应提前设计新 Topic 迁移和双读对账，避免在峰值到来时才临时改变路由规则。
七、常见误区与追问
- 误区：分区越多吞吐越高。 控制面、文件和复制成本会反噬。
- 误区：消费者数量就是并行度。 活跃并行上限受分区数约束。
- 误区：总流量均衡就没有热点。 单 key 可压满一个分区。
- 误区：扩分区不影响顺序。 取模变化可能让同 key 跨分区。
- 追问：安全系数取多少？ 依据增长、压测波动和故障容量，不能套固定值。
- 追问：为什么不一开始设很大？ 空分区仍消耗 Broker 与控制面资源。
- 追问：如何缩分区？ 通常新建 Topic 并迁移，不能假设原地合并无影响。
八、加强记忆
分区规划沿“吞吐下限—消费并行—顺序 key—热点分布—运维成本—扩容迁移”计算。公式只给起点，真实压测决定单分区能力；最终用分区级指标验证，并为路由变化与版本化迁移预留方案。