hash分区数必须是2的幂次方，因为底层采用hash(key) & (numpartitions−1)位运算等价取模，仅当numpartitions为2的幂时才成立；否则导致数据严重倾斜，引发kafka/flink/starrocks等系统热点问题。

为什么 hash 分区数必须是 2 的幂次方？

因为大多数分布式系统（如 kafka、flink、spark sql）底层用的是 hash(key) & (numpartitions - 1) 这种位运算取模，它等价于 hash(key) % numpartitions ——但仅当 numpartitions 是 2 的幂次方时才成立。否则结果会严重偏斜，小分区被疯狂写入，大分区长期空闲。

常见错误现象：KafkaProducer 发送后发现某些 partition 消息量是其他 partition 的 3–5 倍；Flink 作业出现 hot key 导致反压集中在少数 subtask。

• 不是所有哈希函数都“均匀”，但位运算本身不修复分布问题，只放大原始不均
• 如果上游 key 本身有长尾（比如 10% 的用户占 90% 的流量），哪怕分区数是 2 的幂，仍需配合 salting 或预聚合
• 选 4/8/16 是权衡：太少易倾斜，太多增加连接数和元数据开销（Kafka 中每个 partition 对应一个 Log 和文件句柄）

怎么验证你当前的分区数是否合规？

直接检查配置项或代码里传入的值，别信文档或注释。尤其注意动态计算逻辑——比如有人用 Math.ceil(totalRecords / 100000) 算出 12，就直接用了，这很危险。

使用场景：排查 Flink keyBy 后吞吐骤降、Kafka Consumer Group lag 突增、StarRocks 表导入时部分 BE 节点 CPU 拉满。

• Kafka：检查 num.partitions 配置或 Admin.createTopics() 时传的 new NewTopic(..., 12, ...) → 12 不合法
• Flink：看 DataStream.keyBy(...).rebalance().map(...) 前的并行度是否设为 2 的幂；若没显式设，查 env.getParallelism() 默认值
• StarRocks：建表语句中 DISTRIBUTED BY HASH(...) BUCKETS 12 → 必须改成 8 或 16

2 的幂次方选 8 还是 16？看吞吐和 key 粒度

没有通用最优解，取决于你的 key cardinality 和单 partition 处理能力。盲目上 128 可能导致小数据量下大量空 partition，浪费资源；死守 4 又扛不住突发流量。

性能影响明显：Kafka 中 partition 数翻倍，consumer group reblance 时间线性增长；Flink 中 state backend 的 checkpoint 大小也会随 keyGroup 数上升（keyGroupCount = parallelism × 128，默认）。

• key 总数
• key 总数 > 500 万，且写入 TPS > 5k → 上 16 或 32，但要同步调高 consumer fetch.size 和 max.poll.records
• 如果 key 带时间戳前缀（如 20240520_user_123），注意高位变化少，可能让低 3 位 hash 结果重复，此时 8 不够，优先换 key 设计而非硬加 partition 数

哪些情况可以破例不用 2 的幂？

极少数场景下，系统明确不依赖位运算，而是走真实取模，比如某些自研中间件或老版本 Spark（HashPartitioner 在 Spark 2.x 中对非 2 幂也做兜底）。但除非你翻过源码确认，否则一律按 2 的幂处理。

容易踩的坑：Redis Cluster 的 slot 数固定是 16384（2^14），但它不让你改；而你在上面模拟分区时自己写 key.hashCode() % 12，这就是典型错误——Redis 本身不参与这个计算，你写的这行代码完全失控。

• 别在客户端层手动 hash 后发往不同实例，除非你控制了全部路由逻辑
• 用 xxHash 或 Murmur3 替代 String.hashCode()，后者在短字符串下冲突率高，会进一步恶化非 2 幂下的倾斜
• 测试阶段一定要用真实 key 样本跑 count group by partition_id，别只看理论均匀性

实际部署时，最常被忽略的是 key 本身的分布质量。再好的分区数，也救不了全站只有 3 个活跃用户的 user_id 字段。