“永不过期”并非真不淘汰，因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 查询耗时。没有这些，你永远不知道击穿是偶发还是正在恶化。
