发布新版本时，代码切换和缓存更新并非天然同步：应用可能已读到新结构，缓存里却还留着旧数据；如果先清空缓存，也可能让大量请求同时回源。做好缓存刷新与版本发布的一致性控制，关键是先明确读写顺序，再按可验证的步骤切换。
下面以 PostgreSQL 中的商品库存数据、应用缓存和逐步放量发布为例说明。这是通用操作场景，不依赖特定行业或缓存产品。
先定规则：哪些数据必须一致
先区分“数据正确”和“显示最新”的要求。库存、订单状态等会影响后续操作的数据，通常要从权威数据源校验，不能只依赖可能过期的缓存；允许短暂延迟的展示数据，则可设定可接受的过期窗口。把数据来源、缓存键、更新路径、失效方式和责任服务列成清单，避免只刷新了一个应用节点上的本地缓存，却遗漏其他实例。
按 5 步完成一致性控制
- 盘点依赖并定义一致性边界。记录新版本读取和写入的字段、缓存层级、缓存键及 TTL（生存时间）。例如，库存变更由 PostgreSQL 提交后，哪些接口结果必须立即反映变化，哪些统计展示可以延迟更新，都要先写清楚。若新旧版本对同一字段的含义不同，应明确兼容期限和切换条件。
- 选定缓存失效方案。数据结构兼容时，可在数据库事务成功后发送失效事件，让相关键失效，再由后续读取重建；若事件可能丢失，可用事务发件箱等方式把数据更新和待发送事件一并记录，消费者再重试处理。结构变化不兼容时，可采用版本化键，让新版本读取独立的一组缓存。前者节省重复数据，后者隔离更清楚，但会增加存储占用，并需要管理旧键过期。
- 先部署兼容版本，再切换读写。先发布能识别新旧数据格式的过渡版本，确认实例健康后逐步放量；若数据库改动涉及字段增删，优先采用“先加新字段、迁移并双读或双写、切换后再清理旧字段”的扩展—迁移—收缩方式。不要让旧实例仍在运行时，直接移除它依赖的字段或缓存格式。
- 按范围刷新并控制回源。先对小流量或单个分区执行失效，观察缓存命中、数据库负载、错误率和延迟，再扩大范围。新版本首次读取可能触发集中重建，可分批预热、限制并发，并为热点键设置请求合并或短暂等待，避免缓存击穿。全量刷新只有在范围明确且数据库有承载余量时才考虑。
- 验证结果并保留回滚路径。检查新旧版本读到的数据格式、关键业务结果和失效事件处理情况；抽查刷新前后同一条库存记录是否与数据库一致。出现错误时，先停止继续放量，再回切到兼容版本或旧读路径；确认新旧代码都能安全处理当前数据后，才恢复发布。版本回退不等于数据回退，数据库迁移和缓存内容要分别评估。
按场景取舍，而不是一律清空
选择策略时，可以抓住三点：数据是否允许短暂陈旧、更新事件是否可靠送达、新旧版本能否共用缓存格式。允许短暂延迟且 TTL 有明确上限时，过期后重建较简单；要求变更尽快可见时，应在写入成功后主动失效，并监控失败重试；格式不兼容时，版本隔离通常更稳妥。缓存刷新与版本发布的一致性控制不是把 TTL 调成零，也不是每次发布都清空全部缓存，而是让失效、切流和回退遵循同一套顺序。
常见问题
刷新缓存一定要放在发布前吗？
不一定。若新版本依赖新格式，先准备兼容代码或独立缓存空间，再切流更安全；若只是数据更新，可在数据库提交后触发失效。应根据依赖关系安排顺序。
异步失效会不会让旧值继续被读取？
有可能。需要设定可接受延迟、监控事件积压，并对关键写后读场景提供数据库校验或短期绕过缓存的路径。
发布失败后，能否直接恢复旧版本？
只有旧版本能兼容当前数据库字段和已写入的数据时才适合直接回退。发布前应验证回滚条件，并避免过早删除旧字段或旧格式支持。
怎样判断刷新已经完成？
不要只看刷新命令是否返回成功；还要核对目标键或分区、失效事件积压、缓存命中变化及关键业务读取结果。这样才能让缓存刷新与版本发布的一致性控制形成可检查的闭环。
