“永不过期”策略实质是Redis key物理永存，逻辑过期时间嵌入value中；安全的get_with_logic_expire需用SETNX抢锁、双重检查、异步更新；必须搭配主动刷新机制防脏数据。
什么是“永不过期”策略的实质
它不是真的把 TTL 设成无穷大，而是让 Redis 的 key 永不物理过期（比如用 SET key value 不带 EX），但把逻辑过期时间藏在 value 里——比如存成 JSON：{"data": "xxx", "expire_at": 1741825620}。访问时只检查这个时间戳，不依赖 Redis 自动淘汰。
怎么写一个安全的 get_with_logic_expire 函数
关键不在“永不过期”，而在“过期了怎么不卡住、不打垮 DB”。常见错误是：一发现逻辑过期就同步查库 + 写缓存，结果高并发下全挤在那条路线上。
- 发现逻辑过期后，立刻尝试用
SETNX lock:xxx 1 EX 10抢锁，失败则直接返回旧数据（哪怕已逻辑过期） - 抢到锁的线程，要再查一次缓存——因为可能别的线程刚更新完，避免重复查库
- 查库成功后，用
SET key {"data":..., "expire_at": ...}写回，不设 TTL；失败则删掉锁，别让锁残留 - 异步更新推荐走轻量队列（如 Redis Stream 或线程池），不要在 HTTP 请求线程里
sleep或阻塞等
为什么不能真设成永久缓存
业务数据会变，DB 更新了但缓存不动，就会一直返回脏数据。所以“永不过期”必须搭配主动刷新机制，否则就是掩耳盗铃。
- 定时任务刷新：适合变更频率低、可容忍分钟级延迟的场景，比如城市配置、运营 banner，用
ScheduledExecutorService或Quartz每 30 分钟 reload 一次 - 写操作联动刷新：DB 更新后，立刻清空或重设对应 key（注意不是 DEL，而是
SET新值 + 新expire_at），避免读写不一致窗口 - 不建议监听 binlog 做实时同步——太重，且容易丢事件；小规模系统用应用层双写更稳
最容易被忽略的三个细节
很多人照着示例写了逻辑过期，上线后还是被打穿，问题往往出在这儿：
-
expire_at必须用绝对时间戳（秒级），别用相对秒数，否则序列化/反序列化时易错 - Redis 返回的 value 是字符串，必须先
json.loads()（Python）或ObjectMapper.readValue()（Java）才能取expire_at，否则比较永远为 false - 锁的 key 要带业务前缀且唯一，比如
lock:product:10086，别只用lock:10086，否则不同业务互相干扰
逻辑过期不是银弹——它把“击穿风险”换成了“短暂脏读”，得想清楚你的业务能不能接受那几十秒的老数据。
