Appearance
Kafka 分区键怎么设计更稳
Kafka 分区键看起来像一个 producer 参数细节，实际上它几乎同时影响三件事：
- 顺序性
- 并行度
- 热点倾斜
所以分区键设计错了，线上常见问题会一起冒出来：
- 某个分区 lag 特别高
- 明明分区很多，但消费并行度上不去
- 业务要求同一订单顺序消费，却被打散了
先说结论
- 分区键设计本质上是在顺序性和负载均衡之间做权衡
- 同一个 key 会稳定落到同一分区，这能保证局部顺序，也会带来局部热点
- 最稳的分区键通常是“业务上必须串行的最小单位”
- 如果业务既要顺序又要高并行，往往要重构消息模型，而不是指望一个万能 key
分区键到底在决定什么
Producer 发送消息时，如果指定了 key，Kafka 通常会根据 key 做哈希并选择分区。
这意味着：
- 相同 key 的消息会落到同一分区
- 同一分区内消息有序
- 不同分区之间天然无全局顺序
所以分区键不是“路由细节”，而是消息顺序边界。
一个最关键的判断
你先问自己：
“哪些消息必须串行处理，乱序会出业务问题？”
这个答案，通常就是分区键设计的起点。
例子一: 订单状态流转
如果同一订单的创建、支付、取消必须顺序处理，那分区键可以选 orderId。
例子二: 用户行为埋点
如果没有强顺序要求，只需要整体吞吐均衡，那可以不强调强业务 key，甚至走默认均衡策略。
为什么分区键不能只看顺序
因为一旦你把 key 选得太集中，顺序是有了，并行度可能就没了。
例如用 shopId 做 key：
- 某个大商家流量极高
- 所有消息都进同一个分区
- 该分区 consumer lag 持续升高
这时候你会看到：
- 明明 topic 有很多分区
- 但真正被打满的只有少数几个
这就是典型的分区倾斜。
一个常见错误: 用过粗的业务维度做 key
很多人图省事，会选：
- 城市 ID
- 店铺 ID
- 渠道 ID
- 业务类型
如果这些维度天然分布不均，就很容易形成热点分区。
所以分区键不能只看“业务上有关联”，还要看“分布是否均匀”。
什么时候应该用细粒度 key
如果业务顺序要求是局部的，通常更适合选最小串行单元：
- 订单消息选
orderId - 账户流水选
accountId - 库存扣减选
skuId
这样既保留局部顺序，又尽量避免把不必要的消息挤进同一个分区。
什么时候不该强行指定业务 key
如果消息本身没有顺序依赖，强行指定业务 key 反而可能带来负担。
例如：
- 指标上报
- 日志采集
- 普通通知投递
这类场景更重要的是吞吐均衡，而不是局部顺序。
顺序性和扩容之间的一个现实问题
很多团队上线时按 orderId 分区，后面业务量上来想扩分区。
这时要意识到：
- 分区数变化后，key 到分区的映射可能变化
- 同一业务实体的新旧消息可能落到不同分区
如果系统对顺序极度敏感，扩分区就不是单纯运维动作，而是业务语义变更。
一个更实用的设计思路
可以把分区键设计分成三步：
- 找出必须保证顺序的业务实体
- 评估这个实体维度的数据分布是否均匀
- 判断未来扩容时是否能接受映射变化
这三步都过了，这个 key 才算比较稳。
热点分区怎么缓解
如果已经出现分区倾斜，常见思路有：
- 调整 key 维度
- 做 key 打散
- 将超热点业务拆 topic
- 把需要绝对顺序的链路和普通链路分开
注意，key 打散会影响顺序保证。
所以不能一边要求“同一订单全局顺序”，一边又随意把 orderId 加随机后缀打散。
常见误区
1. 以为 key 越细越好
太细会让消息几乎随机分布，顺序语义可能丢失。
2. 以为 key 越粗越稳
太粗会造成热点倾斜，吞吐能力被少数分区卡死。
3. 只看 producer，不看 consumer 处理模型
分区键的设计最终是服务消费端的。
如果 consumer 侧本身还有线程池乱序处理，上游分区顺序也可能白费。
总结
Kafka 分区键设计的本质，不是哈希技巧，而是业务顺序边界设计。
真正稳的 key，通常是：
- 刚好覆盖必须串行的最小业务单元
- 分布相对均匀
- 在扩容和演进时仍然可控