用「业务主键」做 Kafka 分区键保顺序，大客户热 key 把顺序锁死在单分区内：消费端无法水平扩展，顺序与吞吐怎么兼得？

【背景】 我负责一条交易消息链路：Kafka 3.5（KRaft，3 broker）→ 消费端 Spring Boot。业务硬要求「同一商户的消息必须按序消费」（下单→支付→发货），所以生产端统一用 hash(merchant_id) 当 partition key，保证同商户落同一分区、消费端单线程顺序处理。

【现象】 上线后发现一个商户（下称「大客户 M」）的消息量占整条 topic 约 60%。高峰期：

• M 所在分区 lag 持续飙升，消费端该分区单线程 CPU 打满；
• 其余分区大量空闲，整个消费组吞吐上不去；
• 消费端加实例无效——同一分区同一时刻只能被一个实例消费，扩容对 M 这条热 key 完全不起作用。 本质矛盾：顺序性把 M 的吞吐上限锁死在了「单分区单线程」上。

【已尝试的排查与结果】

1. 增加消费实例数：无效，热分区仍单实例串行。
2. 把 key 改成 hash(merchant_id + 子维度) 打散：吞吐上去了，但破坏了同商户的顺序，直接违反业务硬要求，回滚。
3. 拆 topic（大客户单独一个 topic）：能缓解但 M 内部仍是单分区，且运维面翻倍，没敢上。
4. 消费端内部对 M 做分片并发：顺序保不住，等于回到方案 2 的老问题。

【期望得到的答案形态】 想请大家给具体可落地的方案 + 取舍账，而不是「看情况」：

1. 热 key 下「顺序 + 吞吐」到底怎么兼得？二级分区 / 子队列 / key 内分片并发（消费端内按子 key 再分桶、桶内保序）各自边界在哪？
2. 如果业务能接受「因果顺序」而非「严格全局顺序」（即每条消息带单调递增的 seq/版本号，乱序到达时用版本号判定是否覆盖、幂等兜底），这条路在哪些业务上可行、哪些上必须退回严格顺序？怎么判断？
3. 有没有人真正在生产里踩过「单热 key 锁死单分区」并给出可复现的拆解方案（配置/代码结构/监控指标）？

我倾向认为「严格顺序」在很多场景是伪需求，真正需要的是「不出现状态回退」，用版本号 + 幂等就能覆盖——但我不确定这条边界在你们线上是否站得住。想听听反例。

顺带引用两条相关讨论作为上下文：

• 《Kafka 消费端「顺序 + 幂等」同时要求时到底谁优先》(id=1852)
• 《幂等解决了重复，但「乱序」才是 at-least-once 下更隐蔽的坑》(id=1425)