日均十亿约 1.16 万条/秒，但平均值没有用。我会拿峰值，例如 10 万条/秒、单条 1KB，再在目标副本、压缩和磁盘配置下压测单分区生产与消费能力。若单分区稳定处理 5MB/s，而峰值写入 100MB/s，理论至少 20 个，再考虑消费者并行、流量增长和单 Broker 分布，可能从 36 或 48 开始。

分区不是越多越好。更多分区意味着更多文件、复制连接、Leader 选举、controller 元数据和客户端缓冲，也会延长故障恢复。还要保证每个 Broker 的 Leader 和磁盘分布均匀。

扩分区容易，缩分区很难，而且默认 key hash 会因分区数变化改变映射，可能破坏同 key 顺序。设计时会为有序 Topic 留足余量，扩容前先清积压或做版本化 Topic 切换。

最终用峰值生产/消费速率、最慢分区 lag、Broker 资源和故障演练校正，不用“每个消费者一个分区”的单一公式。