Kafka 热 Key 有序消费的单核天花板：CPU 打不满却吞吐上不去的根因与拆 key 方案

先抛一个我想听大家拍砖的问题：你们线上有没有过这种诡异现象——整机 16 核，CPU 只用了 6%，Kafka lag 却在稳定上涨，加机器也救不回来？ 如果是，八成不是 broker 的锅，也不是 rebalance 的锅，而是「有序性」这件事把你钉死在了单核上。

一、现象与背景：不是慢，是「一个核在扛」

去年做订单状态机服务，Kafka 3.5（KRaft 模式，3 broker），order-state topic 16 分区，消费组 8 实例。整体 QPS 约 9.6 万/s，但其中某个大租户的订单 tenantId=T-8821 占了 38% 的流量。

监控上的诡异点：

• 整机 CPU 利用率只有 6%（16 核几乎全空转）；
• 但 order-state 的 lag 从 0 一路涨到 210 万条，且不再回落；
• 把消费组从 8 实例扩到 16 实例，lag 纹丝不动；
• jstack 一抓，只有一个线程在 processRecords 里死循环跑业务逻辑，其余线程全在 poll() 阻塞等数据。

定位命令（很关键，别只盯 broker 端）：

# 1) 看每个分区的当前 lag，找出谁在涨
kafka-consumer-groups.sh --bootstrap-server bk1:9092 \
  --describe --group order-state-cg
# 2) 单独盯那个热分区的生产速率（每秒多少条）
kafka-console-consumer.sh --bootstrap-server bk1:9092 \
  --topic order-state --partition 7 --from-earliest \
  --max-messages 10000 --consumer-property print.timestamp=true
# 3) 用 JFR 确认是不是单线程在干活
jcmd <pid> JFR.start duration=30s filename=/tmp/x.jfr

用 kafka-topics.sh --describe 一验：T-8821 的所有消息因为 partitionBy(tenantId) 全落在 partition 7 上。问题就清楚了——16 个分区用得很满，但其中 1 个分区被单个 key 独占。

二、原理：Kafka 的「有序」是用单分区单线程换来的

这里要把两个「有序」分清楚，很多人混为一谈：

1. 分区内有序：Kafka 只保证「同一分区内 offset 单调递增」。它不保证「同一 key 全局有序」——后者要靠你把同一 key 路由到同一分区（partitionBy / 自定义 Partitioner）。
2. 消费端保序：一个分区在同一个消费组内，同一时刻只会被一个实例消费（这是消费组协议的硬约束，rebalance 期间除外）。

于是链条变成： 同一 key → 同一分区 → 同一分区同一时刻只有一个消费者 → 这个消费者里，处理该 key 的逻辑天然是串行的。

Kafka 帮你保序，代价就是这个 key 的吞吐被限制在「单核 + 单线程」上。 这是设计使然，不是 bug。所以：

• 加 broker、加分区、加消费实例，对这个 key 都无效——它被锁死在一个核上；
• 整机 CPU 空转，是因为其他 15 个分区的消息早就消费完了，没活干；
• 我们实测这个热 key 的单核天花板约 3.2 万 msg/s，正好和它 38% 的流量占比对不上（它需要 ~3.6 万/s），于是 lag 以 ~4000 条/s 的速度稳定上涨。

一个反直觉的点：max.poll.records 调大并不能提吞吐，因为瓶颈在「单线程处理速度」，不在「每次取多少条」。把 max.poll.records 从 500 调到 5000，单核 QPS 反而从 3.2w 掉到 2.9w（单次 poll 处理时间变长，GC 和上下文切换变差），这是我踩的第一个坑。

三、具体做法：把「单 key 单核」拆成「key × 子槽 多核」

核心思路：有序性只需要「同一笔业务」有序，不需要「同一个 key 的所有消息」全局有序。大租户内部其实有 orderId 这一层更细的维度，用它做二次分流即可。

方案 A：生产端拆 key（推荐，改动最小）

把分区键从 tenantId 换成 tenantId + hash(orderId) % N（N=8）：

// 自定义 Partitioner：先保 tenant 隔离，再用 orderId 打散到 N 个子槽
public class OrderKeyPartitioner implements Partitioner {
  static final int SLOTS = 8;
  @Override
  public int partition(String topic, Object key, byte[] value,
                       Object serializedKey, byte[] serializedValue, Cluster cluster) {
    String orderId = JsonUtil.get(value, "orderId");
    String tenant = JsonUtil.get(value, "tenantId");
    int slot = (Math.abs(orderId.hashCode()) % SLOTS);      // 0..7
    String subKey = tenant + "#" + slot;
    return murmur2(subKey) % cluster.partitionCountForTopic(topic).size();
  }
}

效果：原来 1 个 key 打 1 个分区 → 现在 8 个子槽分散到 8 个分区，单核吞吐上限从 3.2w 变成 ~8 × 3.2w ≈ 25w/s，lag 20 分钟清零。

方案 B：消费端单分区内并发（不改 topic，但牺牲严格全局序）

如果「同一 orderId 有序、不同 orderId 无序」可接受，就在消费端对单分区做「按 orderId 分桶 + 桶内单线程」：

// 伪代码：poll 一批后按 orderId 分 8 桶，每桶一个 worker 串行
Map<String, Queue<Msg>> buckets = partitionBy(hash(orderId) % 8);
8 个 worker 线程各自串行消费自己的桶

配套参数（我调过的组合，供参考）：

max.poll.records=500          # 别贪大，见上文坑 1
fetch.min.bytes=65536         # 攒够再取，减少空 poll
fetch.max.wait.ms=500
# 消费端线程池：8 个 worker，每 worker 严格串行

方案 C：换更细的分区键（架构层）

如果 orderId 维度天然存在，长期方案就是让 topic 的分区键直接用 orderId，分区数提到 32，让热点被业务维度自然摊平。代价是「同租户跨订单」的局部序没了，需要业务确认能否接受。

四、踩过的坑与反直觉之处

1. 加机器没用：瓶颈在单核，不在资源。扩到 16 实例 lag 不动，就是被这条约束锁死的。
2. max.poll.records 不是越大越好：调到 5000 后 QPS 反而掉 9%，因为单批处理时间拉长、GC 压力上来。
3. 别把「分区内有序」当成「key 全局有序」：Kafka 从没承诺过后者，是你自己用 partitionBy 加上去的。这个「加上去」的代价，正是单核天花板。
4. 监控要盯「单分区速率」而不是「总 QPS」：总 QPS 看着 9.6 万很健康，但 partition 7 单独看是 3.6 万/s 的需求 vs 3.2 万/s 的产能，缺口只有看单分区才暴露。
5. 拆 key 后要做「顺序性回归」：拆完务必验证「同一 orderId 的状态流转仍然单调」，别为了吞吐把状态机打乱——这是这类改造最容易翻车的地方。

五、结论与可复用清单

结论：Kafka 的有序性是「分区内有序」，一旦你靠 partitionBy 把业务有序性压到单一 key 上，就等于把该 key 的吞吐永久锁定在单核单线程。当出现「CPU 空转 + lag 稳定上涨 + 加机器无效」三连，第一反应应该是热 key / 热分区，而不是 broker 或 rebalance。

可复用清单（下次直接照做）：

• [ ] 出现「CPU 低 + lag 涨 + 扩容无效」→ 先 kafka-consumer-groups --describe 找涨的分区；
• [ ] kafka-topics --describe + jstack 确认是否单分区 / 单线程在扛；
• [ ] 判断业务真正需要的是「key 全局有序」还是「更细维度（如 orderId）有序」；
• [ ] 优先生产端拆 key（tenantId + hash(orderId) % N），改动最小、风险最低；
• [ ] 改 max.poll.records 前先在灰度环境量 QPS，别想当然调大；
• [ ] 拆 key 后必须做顺序性回归测试，验证细粒度有序没被破坏。

留一个开放问题想听大家讨论：当「业务有序性」和「吞吐」冲突时，你们更倾向在「生产端拆 key」还是「消费端分桶并发」？两者对下游（比如依赖消息顺序做幂等的服务）的影响，有没有谁踩过更隐蔽的坑？