合理规划topic分区数需兼顾broker负载均衡、消费者并发能力与业务峰值，推荐分区数为broker数整数倍、≥消费者线程总数，并预留20%~50%余量，配合副本因子≥3及roundrobin分配策略。
合理规划 Topic 分区数，核心是让分区在 Broker 间均匀分布、在消费者间均衡分配，同时预留扩展空间。光设个数字不够，得结合集群、消费端和业务节奏来定。
分区数要匹配 Broker 数量
分区不是越多越好，也不是越少越省事。如果集群有 6 个 Broker，但 Topic 只设了 4 个分区，那最多只有 4 个 Broker 能分到数据，剩下 2 个始终空转——负载天然不均。更糟的是，后续扩容 Broker 后，旧分区不会自动迁移过去，新节点长期“吃不饱”。
- 推荐把分区数设为 Broker 数量的整数倍（如 6 Broker → 12 或 18 分区）
- 创建 Topic 时显式指定
--partitions，别依赖默认值（通常只有 1） - 扩容 Broker 后，需配合
kafka-reassign-partitions.sh手动触发分区重平衡，否则分区仍卡在老节点上
分区数要支撑消费者并发能力
一个分区同一时间只能被一个消费者线程消费。如果消费者组里有 12 个实例（比如 3 台机器 × 每台 4 个线程），但 Topic 只有 8 个分区，那最多只有 8 个线程能干活，剩下 4 个永远闲置——这不是资源浪费，是人为制造瓶颈。
- 分区数 ≥ 消费者实例总数（含线程数），理想情况是整数倍关系
- 例如：ClickHouse 配了
consumer_num=120（10 节点 × 12 线程），Topic 至少要 120 分区，且最好设为 120、240 这类整数倍值 - 注意：分区数不能 runtime 动态增加太多（虽支持扩分区），但扩完后消息不会自动重分布，历史堆积仍卡在原分区
按业务峰值预设，别等压测再调
很多团队习惯“先设小点，扛不住再加”。但 Kafka 的分区数是 Topic 的静态属性，临时扩容分区只能缓解新增流量，对已堆积的消息无济于事——那些积压全堆在原有分区里，新分区根本分不到老消息。
- 按业务高峰期预期的最大消费者并发数来设分区（比如大促预计 200 消费线程，Topic 就设 200+ 分区）
- 预留 20%~50% 余量，避免未来微增需求又要改配置
- 对关键业务 Topic，可结合业务维度做哈希分区（如按用户 ID、订单 ID），既保证顺序性，又天然分散热点
配合副本与分配策略一起看
分区数只是起点。如果副本因子（replication factor）设得太低（如生产环境用 1），某个 Broker 故障就丢数据；如果分配策略选错（比如多 Topic 订阅下用了 Range 策略），也可能导致消费者实际负载不均。
- 生产环境副本建议设为 3（≥5 节点集群）或 5（金融级）
- 多 Topic 场景优先用 RoundRobin 分配策略，确保各消费者拿到的总分区数接近平均
- 用
kafka-topics.sh --describe定期检查分区是否真正在各 Broker 上均匀分布
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
