Kafka cooperative 增量再均衡后，被暂停分区上的本地缓存如何安全失效与恢复

【背景】 我们的计费服务用 Kafka 3.5（3 节点，topic billing-usage 24 分区）做用量采集，消费组 12 实例（K8s Deployment，滚动发布）。消费逻辑：读消息 → 写入本地 Caffeine 缓存（key=用户ID，value=当日累计用量，TTL 1h，用于合并批量落库）→ 定时 flush 到 MySQL。本地缓存是性能瓶颈的核心设计，去掉它 QPS 直接腰斩。

【现象/卡点】 我们近期从 eager 切到了 cooperative（partition.assignment.strategy=CooperativeStickyAssignor），rebalance 时不再全量暂停，只暂停被迁移走的分区。但这里出现一个微妙问题：

• cooperative 模式下，消费者 A 被暂停分区 P 后，进程还活着，Caffeine 缓存里分区 P 对应的用户 key 仍然在 TTL 内；
• 分区 P 被分配给消费者 B 后，B 的本地缓存是空的（或有过期残留），B 开始消费 P 的消息，但 B 的 flush 批次里缺少 A 之前累积的那部分；
• 结果：同一用户的用量被拆到两个实例分别 flush，MySQL 侧靠 ON DUPLICATE KEY UPDATE 累加，但 flush 时机不同导致中间状态不一致——下游对账系统偶尔读到"半截"数据。

【已尝试的排查与结果】

1. 把 Caffeine TTL 从 1h 缩到 30s，缓解了但没根治（窗口仍非零）；
2. 在 onPartitionsRevoked 回调里手动 flush 被暂停分区的缓存——发现 cooperative 模式下这个回调只在新成员加入时触发一次，且回调里 flush 是同步阻塞的，超时（默认 45s）会直接导致 rebalance 失败；
3. 考虑用 onPartitionsAssigned 时从 Redis 拉取全局状态，但引入了额外网络开销，且 Redis 本身成为新单点。

【期望得到的答案形态】 想请教社区有实际经验的同学：

1. 你们在 cooperative 模式下，被暂停分区上的本地可变状态（缓存/计数器/聚合器）是怎么做"交接"的？有没有比"flush 到外部存储"更轻量的方案？
2. onPartitionsRevoked 里做同步 flush 的超时问题，你们是怎么绕的？有没有用异步 flush + 信号量的实践？
3. 有没有人最终放弃 cooperative 回退 eager，理由是什么？

（注：不是问"如何减少 rebalance"，而是问 rebalance 发生时状态如何安全迁移——这是两个不同的问题。）