“永不过期”并非真不淘汰，因redis内存淘汰策略仍可驱逐无ttl的key；真正可靠的是应用层控制，如逻辑过期或物理永驻+定时刷新。

为什么“永不过期”不是真不设过期时间

很多人一看到“永不过期”，就直接 SET hot_key value 不加 EX 或 PX，以为这就完事了。但实际中，Redis 的内存淘汰策略（如 maxmemory-policy volatile-lru）仍可能把这类 key 清掉——它没 TTL，但不等于不会被驱逐。

真正可靠的“永不过期”，是靠应用层控制生命周期：不依赖 Redis 自动过期，而是把过期逻辑收归业务代码。比如在 value 里嵌入一个逻辑过期时间戳，读取时自己判断是否该刷新。

• PERSIST 命令只移除已存在的 TTL，对原本就没设过期的 key 无效果
• 若用 redis-cli 手动执行 PERSIST hot_product_1001，需确认该 key 当前确实有 ttl，否则返回 (integer) 0，容易误判成功
• 集群模式下，PERSIST 是本地操作，不保证跨节点一致；如果 key 被迁移或重分片，可能丢失状态

怎么安全地让热点数据“物理永驻”又不爆内存

硬扛着不删 key，最怕的是冷热混杂、缓存膨胀。尤其当“热点”其实是伪热点（比如某次营销临时冲高的商品），长期驻留会挤占真实高频数据的空间。

稳妥做法是：用定时任务 + 主动刷新代替被动等待过期，同时配合访问监控做动态保活。

• 启动时用 SCAN 批量预热，避免首次请求集中击穿；不要用 KEYS *，会阻塞主线程
• 后台线程每 5 分钟调用一次 GET + TTL 检查，若 TTL 小于 60 秒，立即触发 REFRESH 并重设为 1 小时
• 给每个热点 key 加业务标签（如 hot:product:1001:202604），方便按批次清理或灰度下线

SETNX 加锁重建时，为什么总卡在“等锁”环节

用 SETNX lock:hot_product_1001 1 EX 5 做互斥锁很常见，但线上常出现大量请求卡在 sleep(50); get(key); 循环里，响应延迟飙升——问题不在锁本身，而在锁释放失败或超时不准。

根本原因是：锁的持有者崩溃了，没来得及删 lock:xxx，导致后续所有请求都只能干等 5 秒后重试，形成“锁雪崩”。

• 必须用 Lua 脚本原子性释放锁，不能分开 GET + DEL，否则可能删错别人的锁
• EX 5 太短，数据库慢查询（如 >800ms）就会导致锁提前释放，多个线程并发回源；建议按 P99 数据库耗时 × 2 设定，至少 3 秒起
• 别在锁内做耗时操作：比如调用第三方 API、写日志文件；只做 DB 查询 + SET 缓存两件事

逻辑过期和物理永不过期，到底选哪个

逻辑过期（value 内带时间戳）看起来更优雅，但上线后才发现：它要求所有读写路径统一解析结构，一旦某个旧接口绕过封装直写 SET hot_key "raw_json"，整个逻辑就失效了。

物理永不过期 + 定时刷新更适合已有系统改造，侵入小、兜底强；逻辑过期更适合新项目，能更好支持渐进式更新。

• 用逻辑过期时，务必统一使用封装好的 setWithLogicalExpire() 和 getWithCheckExpire() 工具方法，禁止裸调 redis.set()
• 物理永不过期要配监控：对 hot: 前缀 key 做 MEMORY USAGE 定期采样，防止某类数据无限堆积
• 两者都不解决“数据变更后缓存未及时更新”的问题——这得靠消息队列或 binlog 订阅，不是靠过期策略

最容易被忽略的一点：无论哪种策略，都要在缓存 miss 后记录日志，包括 key 名、miss 时间、是否抢到锁、DB 查询耗时。没有这些，你永远不知道击穿是偶发还是正在恶化。