商品上下架需秒级全链路缓存失效，覆盖cdn、redis、本地三层缓存；必须执行“先改库、再清缓存”原子流程，同步更新db、删除多key redis、刷新cdn、广播事件清本地缓存，并防范漏清、错清与限流失败。
商品上下架必须秒级失效缓存，否则用户还能看到已下架商品、或搜到未上架新品。核心不是“删得快”，而是“删得准、删得全、不漏层”。
上下架触发的缓存层必须全部覆盖
电商商品信息通常经过三层缓存，每一层都可能残留旧状态：
- CDN 缓存：边缘节点缓存详情页 HTML，过期时间常设为小时级，下架后若不主动刷新，用户仍能通过分享链接打开页面
-
Redis 分布式缓存：存储商品结构化数据（如 price、stock、status），key 常为
product:1001或带版本号的product:1001:v3 - 本地缓存（如 Caffeine）：应用进程内缓存商品基础字段（如名称、类目），TTL 多为秒级，但若未配合事件通知，重启前可能一直有效
上下架操作必须走“先改库、再清缓存”原子流程
不能只点后台“上架”按钮就完事——系统需在事务内完成以下动作：
- 更新数据库商品表的
status字段（如从 0→1），并确保事务提交成功 - 同步删除 Redis 中所有关联 key：
product:1001、product:1001:detail、product:1001:sku_list - 调用 CDN 刷新接口，按 URL 刷新（如
/product/1001）或按目录刷新（如/product/） - 向消息队列（如 Kafka）发一条
ProductStatusChangedEvent，通知各服务节点清本地缓存
关键细节：避免“清漏”和“清错”
常见失效失败，往往卡在这些环节：
-
列表页缓存没清：商品已下架，但首页推荐、类目列表、搜索结果页仍缓存着它的 ID 和标题，用户点进去才报“商品不存在”。需同时清除
category:shoes:hot、search:running_shoes等聚合类缓存 -
缓存 key 设计无状态标识：若只用
product:1001，上下架时无法区分是价格改了还是下架了。建议 key 带状态维度，例如product:1001:status单独缓存，或采用版本号product:1001:v4（v4 表示已上架） - CDN 刷新被限流失败静默：批量上下架时，CDN 接口可能返回 429。应配置重试 + 降级：首次失败后改用“缓存过期时间强制缩短至 10 秒”，再异步补刷
实战建议：用事件驱动+分级失效提升可靠性
不依赖单次操作“一把清完”，而是构建可追溯、可补偿的失效链：
- 数据库变更后，通过 binlog 监听或应用层发事件，触发多路缓存清理，解耦且可重放
- 对详情页等关键路径，禁用 CDN 缓存（或仅缓存非状态部分），上下架逻辑完全由后端接口控制
- 加一层轻量“状态代理缓存”，如
status:1001 → "online"，TTL 设为 5 秒，所有读取先查它，再决定是否加载完整商品数据——这样即使主缓存延迟，状态也能快速收敛
