消息队列大版本升级：原地滚动、双实例并存，还是干脆不升？

背景

社区里 K8s 版本升级的姿势已经聊过一轮（滚动 / 蓝绿 / 双集群并存），但消息队列这类有状态中间件的大版本升级，我观察到的分歧远比 K8s 大，而且很少有人正面摊开讲。

我 5 年中间件研发，经历过三次 MQ 大版本切换：一次 RocketMQ 4.x → 5.x（Protobuf 协议变更），一次 Kafka 2.x → 3.x（ZooKeeper → KRaft），一次 Pulsar 2.x → 3.x（BookKeeper 依赖收敛）。三次下来我的体感是：MQ 升级和 Web 服务升级根本不是一个物种——消费端逻辑、事务状态（__transaction_state）、offset 语义、压缩格式、ACL 模型，任何一处行为差异都可能变成静默数据事故，而且这类事故往往延迟几周才暴露（比如事务补偿任务偶发重放）。

常见的三种做法，分歧点各不相同

1. 原地滚动升级：逐 broker 停掉 → 升级 → 拉起，依赖 ISR / 副本机制兜底。

   • 支持者：成本最低、无数据搬迁；
   • 反对者：滚动窗口内新旧 broker 混跑，协议/日志格式不兼容的窗口期是黑盒，且 min.isr 在混跑期间语义会漂移。

2. 双实例并存 + 双写 / 镜像：新建一套目标版本集群，用 MirrorMaker 2 / republish / 双 producer 并行，跑一段时间对账后再切读、最后切写。

   • 支持者：切换窗口可控、可回滚、可对账；
   • 反对者：成本翻倍、双写期一致性窗口复杂（尤其事务型 producer）、offset 迁移的映射规则要人工维护。

3. 干脆不升 / 等 EOL 再被动升：能不动就不动，等安全基线逼到头上再一次性切。

   • 支持者：避免"为升而升"引入的无谓风险；
   • 反对者：EOL 后安全补丁断供，事故概率随时间指数上升。

我的倾向与理由

我倾向 双实例并存 + 分阶段切流，理由有三：

• 可对账：MQ 升级最大的风险不是切换瞬间，而是切换后 2~4 周内的"静默行为差异"（事务重放、消息顺序、compact 语义）。双实例并行期是天然的影子环境，可以在真实流量下对账。
• 可回滚：原地滚动一旦升到一半发现兼容问题，回滚路径非常脏（日志格式已变）；双实例的回滚只是把 producer 指回旧集群。
• 可演练：双实例并存期本身就是一次免费的故障演练窗口。

但我也承认双实例的成本压力是真实的，尤其小团队——所以我特别想听听大家在不同规模、不同 MQ 类型下的取舍。

想听大家聊聊

1. 你最近一次 MQ 大版本升级（Kafka / RocketMQ / Pulsar / RabbitMQ 都算），用的是哪种姿势？花了多久？踩了什么坑？
2. 事务型 producer / 顺序消息 / compact topic 这几类，你们在切换期是怎么保证语义不变的？有没有具体的对账脚本或指标？
3. 有没有人真的走过"不升"这条路？最后被什么事件逼着升的？
4. 双实例并存期，双写一致性你们怎么兜底——幂等键、offset 映射表、还是干脆接受重复？

欢迎贴具体的参数、脚本、事故时间线，空谈"要看情况"我就不点赞了（谢望舒式威胁）。