消息格式迁移中的兼容性与回滚策略

消息格式迁移这事，表面看就是把 pickle 换成 JSON，实际上真正麻烦的地方在上线那一刻：新旧格式会在队列里短暂共存，一旦切换顺序搞反，或者回滚方案没想清楚，服务要么处理不了消息，要么被迫重新打开风险入口。咱们不妨以旁观者的角度，看看这类迁移里哪些坑最容易踩。

先说切换顺序。靠谱的做法是先把能识别新格式的消费者部署上去，再逐步让生产者改写新格式。原因很直白：消费者先学会"认字"，生产者再开始"写新字"，中间就不会出现消费者看不懂的情况。反过来先改生产者，队列里立刻堆满没人能处理的消息。

过渡期如果真要同时支持两种格式，关键是别偷懒写"先试 JSON，失败就退回 pickle"这种兜底逻辑。看着省事，其实是把解析失败变成了危险分支的入口——有人可以故意构造识别不了的数据，把它引向反序列化执行的那条路。更稳妥的方式是在消息里放一个明确的版本标识，按版本分派到对应解析器，而且版本字段本身也要校验，遇到不认识的版本就隔离或拒绝，绝不靠猜。

回滚该回什么

很多人一想到回滚就是把代码整体退回旧版本，但在这件事上，优先要回滚的是生产者发布或者流量开关，让已经部署好的新消费者继续处理新格式消息。如果非要退消费者，前提是确认它还能安全处理队列里已经写入的新消息。

这里有个判断标准值得记住：假如系统只有靠重新启用不可信 pickle 才能恢复，那说明回滚方案本身就是在重新打开风险口子。真正成熟的做法是提前准备好别的手段，比如暂停生产、隔离消息、从可信业务源重建数据，或者切换到兼容的消费者，而不是故障当口临时放宽反序列化的边界。

灰度期间也别光盯着"有没有报错"。生产者或流量比例一点点切，同时得观察消费者错误、任务积压、重试和死信数量，还要抽查业务结果跟旧流程是否一致。那些重试、死信、缓存回填、历史回放的路径最容易被忽略，因为它们可能还在悄悄处理旧载荷。

说到底，迁移的目标从来不是换个序列化语法那么简单，而是让数据只表达校验过的业务字段。顺序、版本、回滚这三件事想清楚了，这场迁移才算真正落地，而不是把老问题换个姿势留在系统里。