“永不过期”策略实质是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，否则不同业务互相干扰

逻辑过期不是银弹——它把“击穿风险”换成了“短暂脏读”，得想清楚你的业务能不能接受那几十秒的老数据。