商品改价后详情页新了、活动会场还挂着旧价，缓存是只删商品 key 就够了吗？

商品改价后详情页已经更新，活动会场、分类列表或搜索页仍挂着旧价，通常不是数据库没写进去，而是缓存副本分了好几层：商品详情 key、列表聚合 key、会场页整页缓存、搜索索引。按 2026 年常见交付经验，判断顺序是先定位旧值卡在哪一层，再决定写序和失效范围；价格展示可以容忍几十毫秒到几秒延迟，下单校验和优惠计算要以数据库为准。只删商品详情 key 往往不够，得先把一条价格影响哪些 key、哪些入口会改价列清楚。

缓存和数据库为什么会各说各话

后台改价后前台还是老价格，常见原因是页面读的是缓存里的旧副本。同一条商品数据在系统里往往存在两到三份：数据库一份、缓存一份、列表页或会场页的聚合结果又是一份。写入只改了数据库，读路径仍然命中缓存，用户看到的就是过期值。

不一致窗口的长短，取决于两件事：删缓存的动作有没有真正执行成功，以及读请求有没有在删除之前把旧值又写回缓存。后者在并发读较多的列表页和会场页上更常见——删除的瞬间有请求回源查到旧数据，删完再把旧数据塞回去，缓存里就留下了更难清掉的旧值。

• 写库成功、删缓存失败：较常见的一类，网络抖动或缓存集群短暂不可用都会触发。
• 删除与并发读撞车：旧值被回填，只能靠过期时间自然消除。
• key 粒度不一致：详情 key 删了，列表聚合 key、会场整页 key 没删，同一个用户看到两种价格。
• 写入入口分散：后台改价、批量导入、第三方同步各写各的，只有一处做了删缓存。

三看一兜底：先判断旧值卡在哪一层

判断写序不必背结论，按“三看一兜底”过一遍即可：先看读写比，决定缓存要不要承担主读路径；再看数据敏感度，决定谁能做最终依据；再看 key 粒度，决定一次改价要失效几个东西；最后用失败重试和过期时间兜底。这套顺序的价值是把“用哪种写法”变成可核对的问题，而不是凭感觉拍板。

1. 看读写比：读远多于写时，先更库后删缓存的不一致窗口只落在写入瞬间；读写接近时缓存收益本来就有限，不必为它额外增加复杂度。
2. 看数据敏感度：商品标题、价格展示可以容忍几十毫秒到几秒延迟；库存扣减、优惠券核销、余额变动要以数据库条件更新为准，不能拿缓存值做判断。
3. 看 key 粒度：一条商品可能同时被详情 key、列表聚合 key、会场整页 key、搜索索引引用，只删详情 key 是常见的漏删，交付前要列出“一条价格影响哪些 key”的清单。
4. 兜底：无论选哪种写法，都要有删除失败的重试和过期时间；经验区间是热点数据过期 5~30 分钟、冷数据 1~24 小时，按业务能接受的陈旧程度定。

第三步常被跳过。我们在验收时遇到详情页价格已更新、活动会场仍是旧价的工单，查下来不是写序错，而是会场页按活动维度存了整页商品，改单个商品不会触发它失效。

几种常见写法的对比

下面四种在 2026 年的项目里都能见到，差别主要在一致性强弱、实现成本和运维负担，很难一概而论。放在一起看更容易对号入座。

• 先删缓存、再更库：实现简单，但删完到写库成功之间若有读请求，会把旧值回填，不一致窗口可能拉到秒级；写入失败时缓存已被清空，回源压力集中。适合写得少、能接受短时抖动的内部后台。
• 先更库、再删缓存：不一致窗口通常在几十毫秒到几百毫秒（经验区间），是读多写少业务里的常见做法。前提是删除动作可重试、可观测，且商品 key 与列表 key 都要覆盖。
• 延迟双删：更新后删一次，再等一个经验区间（常见 300~1000 毫秒）二次删除，压制并发回填。代价是多一次延迟任务，队列积压时等待会漂移，需要监控。
• 订阅数据库变更日志：由独立消费者按变更流删缓存，业务代码不必关心。一致性较稳，但引入额外组件与长期运维成本，小项目常是不划算的。

成本维度上，前两种在常规后台通常是 1~3 人日量级（经验区间），延迟双删再加半天到一天，变更流方案视团队熟悉程度可能要一周以上，并附带长期运维。周期数字只作量级参考，实际取决于现有中间件是否已经就位。

交付现场：会场页旧价怎么落地

在项目里常见的约束是：运营要求改价后几分钟内生效，但活动期间会场页 QPS 是平时的数倍，缓存又不能停。做法上一般把详情 key 与会场 key 分开管理，写库成功后同步删详情 key，会场页和列表页按批次合并删除，并给页面层留一个较短过期时间；删除失败进重试队列，由定时任务补删。结果是改价在常见区间几十秒到几分钟内可见，代价是活动开始或批量改价后会出现一次集中回源，需要在网关侧留出余量。

另一个坑是批量改价。运营一次导入几百条，若逐条删缓存，删除请求量会瞬时放大；按企业项目交付习惯，通常改成按批次合并删除，并在导入任务结束后统一触发一次刷新，避免把缓存集群打成瓶颈。这个做法不能消除所有延迟，但能把回源尖峰压到可控范围，具体余量要按活动峰值 QPS 和缓存集群容量实测。

验收口径：做到什么算合格

判断一套缓存写序能不能用，不看有没有引入缓存组件，而看几件可核对的事。下面几条可以直接当验收清单，任一条不达标都建议先补再上线。

• 生效时间可量化：后台改一条数据，前台能在约定的经验区间内看到新值，并把这个区间写进验收单。
• 删除失败有痕迹：删除缓存失败要进重试或告警，不能只打一行日志就结束。
• key 清单齐全：一条价格影响哪些缓存 key 有明确清单，改字段时同步检查详情、列表、会场和搜索侧。
• 抽样对账：定期抽样比对缓存值与库中值，差异一旦反复出现，就说明某个写入入口漏了失效。

反例也很典型：只在后台保存接口里删详情缓存，批量导入和第三方同步接口各写各的，运营从导入入口改价，会场页照样不更新。这类问题加上过期时间能缓解，却会反复出现在工单里。

适用场景与边界

适合按上面的思路做的是：商品、文章、配置展示类数据，读多写少，允许几十毫秒到几秒延迟，且已有稳定的缓存与重试机制。反过来，强一致要求的数据不该让缓存做最终判断——库存扣减、优惠券核销、账户余额这类，直接以数据库条件更新为准，缓存只用于展示或前置拦截。

• 适合：详情页、列表页、活动会场、字典与配置类数据；写频率低、读频率高的 C 端页面。
• 不必上：日活很小、数据库压力本就不大的内部系统，直接读库配合索引通常更省心。
• 不适合：金额计算、库存判定、风控规则，这些以数据库为准，缓存值只能作提示。
• 慎用：一次改价要跨服务改多份数据时，先确认补偿和重试由谁负责，再谈缓存写序。

常见问题

商品改价后详情页新了，活动会场还是旧价，先查哪一层？

先看会场页是否整页缓存或列表聚合 key；详情新、会场旧通常说明只失效了商品 key，未清页面维度 key。

只删商品详情 key，列表页会不会自己恢复？

不一定。列表页若按分类或会场维度缓存整页结果，删单商品 key 不触发失效，常见要等 5~30 分钟过期，关键页面建议主动清。

先更库再删缓存，删除失败怎么办？

删除失败要进重试队列并留告警，同时靠过期时间兜底；经验区间是热点数据 5~30 分钟，不能只打日志结束。

延迟双删等多久比较合适？

常见区间 300~1000 毫秒，按回源查询加写回缓存的实际耗时定；太短压不住并发回填，太长只是把删除延后。

价格、库存这类数据能不能只靠缓存刷新？

展示可读缓存，扣减和优惠计算要以数据库条件更新为准；缓存只做提示，不宜作为库存判定或金额计算的最终依据。

下一步建议先做一件事：把“一条价格影响哪些缓存 key”列成表，再逐个写入入口核对是否都触发了失效。若业务本身是强一致场景，或团队暂时没有缓存重试与监控能力，先不上缓存、靠索引与读写分离扛，通常比带病上线更省事。