逻辑过期是将过期判断从Redis移至业务代码，Key永不过期，值中携带expireTime时间戳，由业务比对系统时间决定是否重建；需结构化存储、三段式读处理、锁保护重建并二次校验。
逻辑过期不是“让Redis不删key”，而是把过期判断从Redis搬到业务代码里——Key永不过期，但值里自带expireTime字段，由你手动比对系统时间决定是否该重建。
为什么不能直接用Redis的TTL？
因为Redis物理过期是原子事件：一旦key消失，所有并发请求同时miss，击穿就发生了。逻辑过期绕开这个断点，靠业务层控制“假装没过期”——哪怕值已旧，也先顶住流量，再异步刷新。
- Redis的
EXPIRE或SETEX命令无法实现“过期但保留数据”，它一到时间就真删 - 如果只靠
TTL命令查剩余时间，无法解决“查完TTL=0、还没来得及重建就被大量请求穿透”的竞态窗口 - 逻辑过期把判断和动作解耦：读路径不阻塞，写路径（重建）可异步、可限流、可降级
怎么存一个带逻辑过期的缓存值？
关键不是“怎么设key”，而是“怎么组织value”。必须把原始数据和过期时间打包成结构化内容，比如JSON：
{"data":{"id":1001,"name":"iPhone 16"},"expireTime":1757142000000}-
expireTime是毫秒级时间戳（如System.currentTimeMillis() + 30 * 60 * 1000），不是相对秒数 - 不要用
StringRedisTemplate直接存字符串，要用RedisTemplate<String, Object>或手动JSON.toJSONString()序列化 - 写入时不用
set(key, value, timeout, TimeUnit)，timeout传0或干脆用set(key, value)——让key永不过期
读请求怎么判断并处理逻辑过期？
核心是三段式：查缓存 → 解析+比对时间 → 分支处理。重点在“比对后不卡住”：
- 拿到JSON后，先
JSON.parseObject(json, Map.class)，再取map.get("expireTime")转为Long - 若
System.currentTimeMillis() < expireTime，直接返回map.get("data") - 若已逻辑过期，立即尝试
tryLock(lockKey, uuid, 10, TimeUnit.SECONDS)；失败则直接返回旧data，不sleep不重试 - 拿到锁后，必须做**二次检查**：
redis.get(key)再读一次——防止A刚写完，B抢到锁又重建一遍 - 重建成功后，用新
expireTime重新序列化写回，别漏掉更新时间字段
容易被忽略的坑：锁释放和线程安全
逻辑过期看似“无锁”，但重建阶段仍需互斥，而这里的锁只用于防重复重建，不是拦请求——这点常被搞反：
- 锁的
lockKey必须和缓存key一一对应，比如都用"shop:1001"，别写成"lock:shop:1001"导致锁粒度错位 - 异步重建必须用独立线程（如
CompletableFuture.runAsync()），不能在主线程里sleep(100)再查库，否则响应延迟翻倍 - 锁释放不能依赖JVM生命周期——必须显式调用
unlock(lockKey, uuid)，且用Lua脚本保证“判断uuid再del”，否则可能误删别人锁 - 如果重建抛异常，要记录日志并主动
del(lockKey)，否则锁残留，后续所有请求都拿不到锁、永远返回旧数据
最麻烦的其实是时间戳维护：服务器时钟不同步、夏令时切换、NTP校准抖动，都会让expireTime判断失准。生产环境建议统一用SystemClock.now()或接入分布式时间服务，别信本地new Date().getTime()。
