Kafka 消费组实例数动态变化时，下游 RPC 总 QPS 预算如何精确分摊到每实例：N 个实例 × 固定预算 B 的「零超发」分配方案，你们线上到底怎么做的？

背景

我带团队跑订单履约链路，Kafka 3.5（KRaft，3 broker），topic fulfill-event 32 分区，消费组实例数不固定——K8s HPA 根据 lag 和 CPU 在 6~20 实例之间弹性伸缩（每实例持有 1~4 分区）。

下游是一个库存锁定 RPC（gRPC），对方给的硬限制是全局 5000 QPS（不是每实例 5000，是所有实例合计 5000）。超过就 429 拒绝，且拒绝后 3s 内同 IP 段全部限流（对方按 CIDR 做滑动窗口，不是按单 IP）。

我们的做法：每实例本地挂一个令牌桶，容量 = 5000 / 当前实例数。实例数通过消费组 metadata 里的 member count 获取。

现象（两次真实事故）

事故 1（去年 11 月，HPA 扩容）：

• 实例数从 10 → 16（HPA 一次性扩 6 个 Pod）
• 新 Pod 启动后，member count 从 10 跳到 16，每实例令牌桶容量从 500 → 312
• 但旧 10 个 Pod 的令牌桶还是 500（它们还没拿到新 member count，metadata 拉取间隔 5s）
• 窗口期：10 × 500 + 6 × 312 = 5000 + 1872 = 实际瞬时 6872 QPS
• 下游 429 持续 8s，我方重试后 2 次 429 打穿对方熔断，库存锁定接口整体不可用 45s
• 事后算账：超发窗口 ≈ member count 传播延迟（5s）× 旧实例超额量（388 QPS）≈ 2000 次 429

事故 2（今年 2 月，HPA 缩容）：

• 实例数从 14 → 8（缩 6 个）
• 被缩掉的 Pod 在 graceful shutdown 的 30s 窗口内还在消费，令牌桶容量已经更新为 5000/8 = 625
• 但 6 个正在退出的 Pod 也拿到了 625 的限额
• 实际：8 × 625 + 6 × 625 = 14 × 625 = 8750 QPS（预算是 5000）
• 这次更隐蔽：因为下游没有 429（对方限流阈值配得松），而是 P99 从 35ms 飙到 2.1s，消费端 max.poll.interval.ms=120000 被击穿，rebalance，又触发事故 1 的连锁

已尝试的方案与结果

1. 把令牌桶容量写死为 5000 / 20（最大实例数）：

   • 结果：实例数低时（6 个）总吞吐只有 1500 QPS，峰值 lag 从 8s 涨到 45s，业务方投诉。

2. 用 Redis 做全局限流器（INCR + 过期）：

   • 结果：每消息多一次 Redis RTT（P50 0.3ms，P99 2.1ms），在 5000 QPS 下 Redis 侧 QPS 从 5000 涨到 5000+（重试后更高），Redis 本身成了瓶颈；且 Redis 主从切换时全局限流器失效 3~5s，超发窗口反而更大。

3. 用 Sentinel / Hystrix 的全局限流（基于集群心跳）：

   • 结果：Sentinel 集群限流依赖 Token Server 单点，我们试了 3 副本 + Redis 存储，Token Server 本身 P99 加了 1.2ms，且心跳间隔 1s 意味着实例数变化后 1s 内分配不准——比 member count 的 5s 好，但 HPA 一次扩 6 个 Pod 的窗口里还是超发了 1.5s。

4. 每实例令牌桶容量 = 5000 / 20，但加一个「自适应加速」：如果当前 6 实例且 lag > 10s，每实例限额动态升到 5000 / 6：

   • 结果：自适应逻辑本身引入了竞态——6 个实例同时判断 lag > 10s 并同时升限额，瞬时总量 = 6 × 833 = 5000（刚好不超），但 HPA 同时扩到 12 个，12 × 833 = 9996，超了一倍。

我真正想搞清楚的问题

1. 「零超发」在实例数动态变化时到底能不能做到？ 如果不能，你们接受多大的超发窗口（秒级？）和多大的超发倍数（1.1x？1.5x？）作为 SLA？这个 SLA 是怎么和下游对齐的？

2. 有没有一种方案，在 N 动态变化时，总限额始终 ≤ B，且不需要一个额外的集中式限流器（Redis / Token Server）？ 比如：

   • 基于消费组 member list 的「加权分配」：每个 member 按自己的 member.id 做确定性哈希，分到固定份额，新 member 加入时从老 member 那里「借」，老 member 退出时把份额「还」？
   • 基于「全局 lag 反馈」的自适应：每实例的限额不是 5000/N，而是 min(5000/N, f(lag, N))，f 是一个单调递减函数，lag 大时允许单实例超分但总量有上界？
   • 基于「下游 429 反馈」的闭环：不用前置限流，而是用 429 响应作为反馈信号做 AIMD（加性增、乘性减）？

3. 你们线上实际的方案是什么？ 具体到：

   • 限流器是本地还是集中式？
   • 实例数变化后的收敛时间（从 N 变到 N'，到总限额稳定 ≤ B 需要几秒）？
   • 收敛窗口内的超发量（QPS × 秒）大概是多少？
   • 下游的限流策略是 429 拒绝还是排队等待？两种对消费端的影响差异？

4. HPA 和限流的交互：HPA 扩缩容的决策周期（默认 30s）和限流器的收敛周期（几秒到几十秒）是两个时间尺度，你们有没有把 HPA 的扩缩容事件作为限流器的「预算调整信号」？比如 HPA 扩容前先把每实例限额降下来，等 new member 就绪后再恢复？

我引用两条相关讨论

• 提问 [465]《Kafka 消费者 pause() 限流后 resume() 瞬间涌入积压消息打爆下游》——那个问题聚焦 pause/resume 的瞬时冲击，我这个问题聚焦实例数连续变化的持续窗口，机制不同但根因同源：本地限额 × 实例数 ≠ 全局限额。
• 讨论 [1454]《限流与熔断的状态该"全局共享"还是"每实例本地"？》——那个讨论聚焦熔断阈值，我聚焦限流配额分配；它提到的"64 实例各自本地统计导致全局失效"和我的场景完全同构，但它的解法是"上全局状态"，我想听有没有不需要全局状态的近似解。

期待看到：具体的分配算法（伪代码或配置）、收敛窗口的量化数据（秒 × 倍）、下游限流策略的对接方式、以及 HPA 交互的实际工程实践。