Kafka 顺序消息消费时单实例慢调用触发 rebalance，如何保住顺序又不丢消息

【背景】 我们用 Kafka 2.8（3 broker，ISR=3）承载订单状态流转这条关键链路：topic order-state，8 个分区，消费组 8 实例（1:1 部署，保证每个分区内严格顺序）。下游是 MySQL 8.0 写订单表 + 一次 HTTP 通知（同步阻塞，P99 约 120ms，偶发 800ms）。

【现象】 上周一次慢 SQL（锁等待 6s）把其中 1 个实例的 poll 线程卡住超过 max.poll.interval.ms=30000，触发全组 rebalance。rebalance 期间该分区被重新分配，结果出现两类问题：

1. 顺序被打破：rebalance 前已 fetch 到本地 buffer 但还没 commit 的 37 条消息，在新实例上被「重新消费」，但旧实例的 offset 又没提交，导致这 37 条按「乱序」落库（订单状态从 PAID 跳到了 SHIPPED，再跳回 PAID 的补偿日志里）。
2. 重复消费：rebalance 后旧实例的 in-flight 请求（HTTP 通知）超时但下游已经收到，新实例重发又造成一次。

【已尝试的排查与结果】

• 把 max.poll.interval.ms 从 30s 调到 5min，rebalance 风暴确实少了，但单分区卡住时，整组 8 个实例全部空转等待，QPS 从 1200 掉到 0，不可接受。
• 试过 max.poll.records=1 + 每条消息一个事务，顺序保住了，但吞吐直接掉到 80 QPS，也不可行。
• 想过把顺序性下沉到业务层（按 orderId 分片 + 本地队列串行），但又担心和 Kafka 原生顺序语义打架。

【期望得到的答案形态】 希望有同学能给出一套具体到配置项和代码结构的方案：

1. 在「必须保序 + 至少一次 + 吞吐 ≥500 QPS」这三个约束下，Kafka 消费端应该怎么拆（比如：Kafka 只做粗粒度分片，实例内部用 bounded queue + 单线程 worker 按 orderId 串行）；
2. 慢调用（HTTP 通知）应该同步还是异步？如果异步，怎么避免「下游成功但本地没 commit」造成的重复？
3. rebalance 发生时，如何保证「正在处理的那一批」要么全部成功、要么全部回滚（业务侧幂等键怎么设计）？
4. 有没有人踩过「Kafka 顺序 + 本地线程池乱序」的坑，贴一下你们最终落地的代码骨架或架构图。

最好能给出一个最小可复现的 PoC（比如 8 分区 / 8 实例 / 注入 6s 慢调用），以及对应的 Prometheus 指标（rebalance 次数、in-flight 消息数、顺序违规告警阈值）。