Kafka KIP-848 新消费组协议（group.protocol=consumer）生产灰度：classic 与 consumer 协议能否同组混跑、offset 位点是否兼容、回滚会不会丢位点，你们线上怎么切？

背景

我负责一条订单履约事件链：Kafka 3.5（KRaft，3 broker，ISR=3），topic order-event 按 order_id 哈希到 64 分区，消费组 32 实例（K8s Deployment，每实例 2 分区），当前用的是 CooperativeStickyAssignor + static membership（rebalance 增量分配，这是我们的现状基线，参考站内 id=968 的做法）。

Kafka 3.3 起引入了 KIP-848 新消费组协议（group.protocol=consumer），官方叙事是「更平滑的增量 rebalance、支持 server-side 分配、为未来的 share group 铺路」。我们想评估把这条核心链路从 classic 协议切到 consumer 协议，但灰度切换这一层没有标准答案，所以来问各位真正在线上切过的同学。

现象（我担心的三个点）

1. 同组混跑：灰度期间必然出现「一部分实例还是 classic 协议、一部分已切 consumer 协议」的窗口。KIP-848 的 group coordinator 是按 group.protocol 分组的，我怀疑同一 group.id 下 classic 和 consumer 协议实例不能并存（coordinator 会按协议把成员分到不同的 group 上下文），如果是这样，「逐实例灰度」这条路根本走不通，只能整组一次性切换。
2. offset 位点兼容性：切换前后 __consumer_offsets 里存的位点格式是否一致？从 classic → consumer 切换，会不会因为协议差异导致位点重置 / 重复消费 / 位点丢失？
3. 回滚路径：如果 consumer 协议上线后发现某版本的回归 bug，回退到 classic 协议，位点还在吗？回滚 RTO 是多少？

已尝试的排查与结果

1. 单 broker 本地验证：起一个 3.5 单 broker，一个 4 分区 topic，2 个 consumer 实例都设 group.protocol=consumer，rebalance 行为正常、位点正常提交——但这是「全新组」，没覆盖「从 classic 组切过去」的迁移场景。
2. 查官方 KIP-848 文档：文档只讲了新协议的设计目标与语义，对「从 classic 协议存量组如何灰度迁移、位点是否兼容、回滚代价」只字未提，这块完全是空白。
3. 对比现状基线：我们用 cooperative sticky 已经稳定跑了 8 个月，rebalance 中断基本压到 0（参考 id=968），所以切 KIP-848 必须有可量化的额外收益才值得动这条核心链路，否则风险 > 收益。

卡点（想问的，期望贴线上真实切过的方案）

1. 灰度策略：你们从 classic 协议切到 KIP-848（consumer 协议），是「整组一次性切换」还是「逐实例灰度」？如果同一 group.id 下两种协议不能混跑，你们怎么做到「先切 1 个实例验证、再全量」而不触发整组 rebalance 风暴？有没有用「临时 group.id 双跑 + 位点对齐」的做法？
2. 位点兼容验证：切换前后你们怎么可复现地验证 __consumer_offsets 位点没有丢/重？是切完跑一段对账，还是有 kafka-consumer-groups --describe 的 offset 对比脚本？贴一下你们验证用的命令或脚本片段。
3. 回滚预案与 RTO：consumer 协议上线后回退 classic，位点保得住吗？你们的回滚 RTO（从发现问题到切回 classic 且位点无损）实测是多少？踩过「切回去位点丢了、只能从头消费」的坑吗？
4. 量化收益：从 cooperative sticky 换到 KIP-848，rebalance 中断时间、重复投递量、lag 峰值这三项有没有切换前后的对比数据？如果没有明显收益，你们为什么还切？

参考（站内我先读过的）

• 《Kafka 消费组扩容即停摆：从 eager 全停再均衡切到 cooperative 增量 + static membership》（id=968）——这是我们现状基线，也是切 KIP-848 的「要不要动」的对照；
• 《中间件大版本升级：「一把梭」还是「长期双版本并存」》（id=1615）——协议切换本质也是一次「中间件行为变更」，割接窗口与双版本并存的取舍在这里同样适用。

期望的回答形态：你们线上从 classic 切 KIP-848 的完整灰度方案（含是否同组混跑、位点兼容验证脚本、回滚 RTO 实测值、切换前后量化对比）。空对空的「KIP-848 未来会更好」请先回答上面四个具体问题再谈方向；如果你们只切过全新组、没做过存量组迁移，也请明确说，这对判断同样有价值。