redis热点key过期瞬间，互斥锁必须用set key value ex seconds nx原子操作，因setnx不设过期时间易致死锁，先setnx再expire非原子，中间宕机将导致锁残留；该命令一次性完成“不存在才设值+自动过期”，杜绝竞态与死锁。
Redis热点Key过期瞬间，为什么互斥锁必须用setnx+expire原子操作
直接用 SETNX 加锁但不设过期时间，等于埋雷：锁进程崩溃或网络中断后锁永远不释放，后续所有请求卡死。反过来，先 SETNX 再 EXPIRE 也不是原子的，中间若服务宕机，锁就“有头无尾”。
正确做法是用 Redis 2.6.12+ 的 SET key value EX seconds NX 命令——一次完成“不存在才设值+自动过期”，避免竞态和死锁。
- 锁超时时间建议设为「数据库查询耗时 × 2～3」，比如查库平均 150ms，锁设 500ms；太短会导致锁提前释放、多个线程同时加载；太长会拖慢失败恢复
- 不要用
DEL直接删锁，得用 Lua 脚本比对 value（随机 UUID）再删，防止 A 线程锁过期被 B 拿走，A 还误删了 B 的锁 - Java 中推荐用 Redisson 的
RLock.tryLock(3, 10, TimeUnit.SECONDS)，它已封装原子加锁、看门狗续期、安全释放
本地缓存（Caffeine）怎么配才不和Redis抢一致性
本地缓存不是 Redis 的镜像，而是它的“减速带”：它不主动同步，只在读缺失时被动参与 reload 流程。配错参数会导致冷 key 占满内存，或 stale 数据久不更新。
-
expireAfterWrite(10, TimeUnit.MINUTES)必须启用，禁用expireAfterAccess——否则用户零星访问某个低频 key，它就一直活在内存里 -
maximumSize(10000)要设硬上限，尤其当 key 是用户 ID 类无限增长型，不设限等于给 OOM 开绿灯 - 本地缓存不接受写操作：业务层更新数据库后，只发 MQ 清除指令（如
cache-invalidate:product:123），本地监听后调invalidate()；绝不允许直接put()新值
二级缓存失效时，如何让等待线程不狂刷Redis
锁没抢到的线程如果立刻重试 get(key)，会在毫秒级内形成“自旋风暴”，把 Redis QPS 推高数倍。这不是降压，是加压。
- 必须引入退避策略：第一次等
50ms，第二次100ms，最多重试 3 次，之后直接 fallback 到数据库（需兜底逻辑） - 不要递归调用自身方法（如示例里的
return get_data(key)），容易栈溢出；改用 while 循环 + 计数控制 - 等待期间可记录日志埋点：
"wait_for_cache_reload:product:123, retry=2, elapsed=120ms"，方便事后分析击穿毛刺是否集中于某几个 key
MQ 清除本地缓存那条消息，为什么必须幂等且至少投递一次
消息丢了，某台机器的本地缓存就永久 stale；消息重复了，invalidate() 多调几次倒没事，但若清除逻辑里混了非幂等操作（比如发告警、记审计日志），就会引发误报或数据污染。
真正危险的是“清除动作本身不可逆”：比如你用 Cache.asMap().remove(key) 是安全的，但若误写成 cache.put(key, null)，下次 get() 就返回 null，触发无效 reload，白刷数据库。
所以清除端必须校验 key 是否真存在于本地缓存中再删，且 MQ 消费方要实现 ack before process 或至少一次语义（如 Kafka enable.idempotence=true + 事务 producer）。
