双过期时间策略需主备key成对更新、原子读取与定期刷新，避免误删和陈旧；主key设业务可接受最大陈旧窗口，备key须防淘汰并监控一致性。
双过期时间策略（即「主 key + 备 key」）能有效缓解缓存击穿，但不是开箱即用的银弹——它依赖业务层对读写路径的精确控制，且容易因 key 冗余、更新不一致或误删备 key 导致数据错乱。
主 key 和备 key 的设计边界在哪
主 key 是业务正常访问的入口，带 EXPIRE，比如 product:1001:info；备 key 是兜底副本，不设过期，比如 product:1001:info:backup。二者 value 完全一致，但 Redis 不会自动同步——必须在每次写操作中显式 SET 两个 key。
- 主 key 过期时间建议设为业务可接受的「最大陈旧窗口」，例如 30 分钟，而非固定 1 小时
- 备 key 不能被任何后台清理脚本、
SCAN+DEL逻辑误删，否则击穿时无 fallback - 如果业务有「多级缓存」（如本地缓存 + Redis），备 key 仅用于 Redis 层兜底，不参与本地缓存刷新逻辑
读请求如何安全 fallback 到备 key
读流程不能简单判断「主 key 不存在就查备 key」——因为 GET 返回 null 可能是 key 真不存在（穿透），也可能是刚过期（击穿）。必须结合业务语义区分：
- 先
GET主 key，若返回非空值，直接返回 - 若返回
null，立刻GET备 key；仅当备 key 也为空时，才走数据库查询（防穿透） - 绝不能对备 key 做
EXISTS判断后才读——EXISTS+GET有竞态，两次命令间备 key 可能被删 - 推荐用 Lua 脚本原子执行：
EVAL "if redis.call('exists', KEYS[1]) == 1 then return redis.call('get', KEYS[1]) else return redis.call('get', KEYS[2]) end" 2 product:1001:info product:1001:info:backup
写操作必须同时更新两个 key
写路径一旦漏掉备 key，击穿发生时就会返回脏数据或空值。常见疏漏点：
- 数据库更新成功但 Redis 写失败（网络抖动、连接池满）→ 主备 key 不一致 → 后续所有击穿请求都返回旧数据
- 使用 pipeline 批量写入时，未把备 key 的
SET命令包含进去 - 延迟双删场景下，只删了主 key，忘了删备 key，导致新老数据混杂
- 示例正确写法：
SET product:1001:info "{...}" EX 1800和SET product:1001:info:backup "{...}"必须成对出现，最好封装进 DAO 方法
为什么不能只靠备 key 永不过期
备 key 永不过期看似省事，但会引发内存泄漏和数据陈旧问题：
- Redis 内存淘汰策略（如
allkeys-lru）仍可能淘汰备 key，尤其当实例长期高水位运行时 - 业务数据已变更多次，但备 key 始终是首次写入的旧值，击穿时用户看到的是数小时甚至数天前的数据
- 真正可控的做法是：用定时任务或消息队列定期刷新备 key（比如每 2 小时重刷一次），而不是放任其「永生」
- 刷新时机应避开流量高峰，且需加分布式锁防止多个实例重复刷
双 key 策略的关键不在「多一个 key」，而在于把「过期不可控」转为「更新可控」。最容易被忽略的其实是监控——你得实时知道主 key 的过期命中率、备 key 的读取占比、以及二者 value 的 MD5 是否一致，否则等于裸奔。
