一个头部商家吃满 68% 流量：Kafka 单热 key 把消费组打挂的根因与拆分方案

结论先行：Kafka 消费组"加机器"失效、消费延迟雪崩，最常见的根因不是消费者太慢，而是热 key 把所有流量钉死在同一个分区、同一个消费者实例上。分区并行度再高，对单个 key 来说永远是 1。

一、现象与背景

去年双 11 前压测，我们支付通知链路（Kafka 3.5.x，topic pay-notify，32 分区，消费组 12 实例，日均 4200 万条、单条约 1.2KB）出现一个非常反直觉的现象：

• 12 个消费者实例里，11 个 CPU 稳定在 8%~15%，唯独 1 个实例 CPU 打满 98%；
• 该实例消费速率被压在 6.2 万条/秒（单机上限），其余实例基本在空转；
• 消费 lag 从平时的 2000 以内飙到 380 万条，通知到达延迟 P99 从 800ms 恶化到 26 分钟；
• 运维第一反应是"扩机器"，把消费组从 12 实例扩到 24 实例，lag 一秒没降——因为多出来的实例分不到任何分区。

事后用 kafka-consumer-groups --describe 和 producer 端埋点统计，发现根因：头部商家 M001 一家占全 topic 消息量的 67.6%（日均 2840 万条），双 11 大促叠加后瞬时峰值到 19 万条/秒。这 2840 万条消息的 key 全是 M001，被 hash 后全部落在 partition-7，由 12 个实例中的某一个独吞。

二、根因分析：Kafka 的并行度模型对热 key 失效

把机制拆开看，三层原因叠加：

1. 分区是 Kafka 唯一的并行单元，而 key→分区是确定性映射。partition = murmur2(key) % 32，同一个 key 永远落同一个分区。分区数从 32 扩到 64，M001 依然只占 1 个分区——扩容对单 key 完全无效，这就是扩 24 实例 lag 不动的原因。
2. 消费组协议里一个分区同一时刻只能被一个消费者持有（rebalance 除外）。所以 partition-7 的吞吐上限 = 单实例处理能力（我们的 6.2 万条/秒），而不是集群能力。
3. Kafka 的背压是"分区级"的：partition-7 积压 380 万条，但 consumer lag 监控是按组汇总的，其他 31 个分区 lag≈0，汇总 lag 被稀释，告警阈值迟迟不触发。这是这次事故拖了 40 分钟才被发现的关键。

一句话：热 key 把"分布式问题"退化成了"单机问题"，而你所有的扩容手段都作用在分布式层面。

三、具体做法：两级拆分 + 生产者侧热 key 探测

方案分三层，全部在生产者侧完成，消费侧只加实例：

1. 生产者侧热 key 探测与拆分（核心）

对超过阈值的 key，把 M001 改写为 M001#0 ~ M001#7 共 8 个子 key，8 个子 key hash 后散落到 8 个不同分区：

// 阈值 2 万条/秒 触发热拆分，窗口 1s 滑动统计
int sub = random.nextInt(8);
String newKey = hotKeyManager.isHot(merchantId)
    ? merchantId + "#" + sub
    : merchantId;
producer.send(new ProducerRecord<>(TOPIC, newKey, body));

消费侧对应把路由逻辑从 key 改为 split(key, '#')[0] 取商家号。8 路拆分后 partition-7 压力降为 1/8，消费组 12 实例刚好每人一个"份额"，lag 在 90 秒内清零（实测峰值 19 万条/秒，P99 延迟回到 1.1s）。

2. 监控改为"分区级 lag"

把告警从"消费组总 lag > N"改成"任一分区 lag > 50 万条持续 60s 即 P1"，同时上 bytes-in 按分区 top5 看板。这次事故里 partition-7 的 lag 曲线在总 lag 曲线上完全不可见，分区级告警是第一道防线。

3. 兜底：热点隔离 topic

对可预见的确定性热点（大促、头部商家），提前把 M001 路由到独立 topic pay-notify-hot（16 分区），与常规流量物理隔离，避免互相拖累。

四、踩过的坑 / 反直觉点

1. "扩分区 + 扩实例"对热 key 是零收益，而且扩分区本身有风险：分区数变更会让原有 key 的分区归属整体重排，rebalance 期间出现短暂重复消费，我们靠业务幂等表（唯一索引建在 MySQL 而不是 Redis）兜住的——幂等表必须能扛住"分区重排级别的重复"。
2. 拆分 key 会破坏单商家内消息顺序。M001#0 和 M001#3 天然乱序。我们的业务是"通知最终一致 + 幂等"，可以接受；如果你的场景要求单 key 严格有序（比如账务流水），热拆分方案直接不可用，只能走"单分区 + 提单机吞吐"或"队列内顺序号 + 消费侧重排"。
3. 热 key 探测阈值别设太低。我们最初设 1000 条/秒，结果把 200 多个正常大商家都拆了，消费侧路由分支变宽、日志排查成本翻倍；调到 2 万条/秒后只有 3 个 key 触发，收益/代价比最健康。
4. lag 汇总监控是"稀释型告警"，31 个健康分区会把 1 个爆炸分区的信号完全淹没。任何按组聚合的 Kafka 指标，在存在热 key 时都不可信。

五、结论与可复用清单

热 key 是消费型系统的"单点"，治理动作要落在生产者侧，而不是消费侧扩机器。可复用清单：

1. 上线前用 producer 埋点统计 key 的流量分布 top10，top1 占比 > 30% 就要有预案；
2. 热 key 拆分：key#sub 散列到 N 个分区，N 从 4/8 起步，消费侧路由按 # 前缀归一；
3. 监控从"组级 lag"升级为"分区级 lag + 分区级 bytes-in top5"；
4. 确认你的业务能否接受单 key 乱序，不能则热拆分不可用，改走顺序号重排或独立 topic；
5. 确定性热点（大促、头部客户）提前路由到隔离 topic；
6. 任何 key 拆分/扩分区动作前，确认业务幂等能扛 rebalance 与分区重排带来的重复消费。