Kafka 单条消息处理 8s 打爆 max.poll.interval.ms 导致 evict + 40s 一轮 rebalance，如何调参

【背景】 生产环境 Kafka 3.4（3 broker，KRaft），topic user-event，24 分区，消费组 8 实例（1:3 分区/实例），峰值 1.8 万 msg/s。消费者内部要做一次下游 RPC 落库（P99 约 800ms，但 P999 偶发到 3~8s，主要是下游 DB 慢查询 + 网络抖动）。当前 consumer 关键参数：max.poll.interval.ms=30000、max.poll.records=200、session.timeout.ms=10000、heartbeat.interval.ms=3000。

【现象】

• 每周 2~3 次，consumer 日志出现 MemberId xxx generation 42 has expired，紧跟着 Rebalance 开始；
• 单次 rebalance 持续 35~55s（Coordinator 选举 + partition 重新分配 + 各实例 onPartitionsRevoked 提交 offset），期间整组消费停摆，lag 峰值冲到 6 万；
• rebalance 结束后，被 evict 的实例重新加入，又拿到一批 partition，但下游 DB 那边重复写（因为我们没做幂等键），业务侧告警 2~5 条；
• 频率与下游 P999 强相关：下游慢查询一多，必触发。

【已尝试的排查】

1. 把 max.poll.interval.ms 从 30s 提到 90s——rebalance 频率降了，但单次 rebalance 的"停摆窗口"反而变长（Coordinator 等心跳超时时间也变长），整体没改善；
2. 把 max.poll.records 从 200 降到 50——单批处理时间确实降了，但吞吐从 1.8 万/s 掉到 1.1 万/s，lag 慢慢涨回来；
3. 下游 RPC 加了 3s 超时 + 重试 2 次——P999 从 8s 降到 2s，但极端情况（DB 慢查询堆积）还是会被打穿；
4. 没动 session.timeout.ms，怕一调大 rebalance 检测更慢。

【期望得到的答案形态】

1. 参数组合：在「慢调用偶发 8s、不能改下游」的约束下，max.poll.interval.ms / max.poll.records / session.timeout.ms / heartbeat.interval.ms 应该怎么配才既不打爆 evict、又不让 rebalance 检测太慢？请给出具体数值和推导逻辑（比如按 P999 × 安全系数算）；
2. 代码层：是否应该在 poll() 循环里加「单条消息处理耗时熔断」（超过阈值就 skip 或投递到重试队列），而不是靠参数硬扛？如果做，阈值怎么定？
3. 幂等：rebalance 期间重复消费是常态，下游幂等键应该用消息的什么字段（offset？业务 id？）？用 offset 做幂等键在「rebalance 后 offset 重新分配」场景下是否可靠？
4. 有没有更稳的消费模式：比如把「拉取」和「处理」解耦（拉取端只负责 ack，处理端用本地队列 + 独立 worker），这种拆法在 24 分区 / 8 实例的规模下值不值得做？

我倾向用具体数字说话，欢迎贴你线上跑过的参数组合 + 数据。