缓存击穿是热点key过期瞬间大量并发请求穿透至数据库，须用redis分布式互斥锁（set key val nx ex）、lua校验删锁、指数退避重试及倒计时前主动刷新缓存来彻底解决。
倒计时结束那一秒，Redis 缓存还没来得及刷新，所有请求同时发现 GET 返回 null，立刻涌向数据库——这就是缓存击穿的典型爆发点。单靠 setnx 或简单互斥锁，在百万级并发下会严重阻塞，接口平均响应直接从 85ms 拉到 2s+，甚至触发 502。
为什么倒计时结束瞬间特别危险
秒杀倒计时结束 ≠ 商品开售时间点，而是业务逻辑中「缓存过期」和「流量洪峰」强耦合的时刻。常见错误是把缓存 TTL 硬设为倒计时剩余时间（比如倒计时还剩 60 秒，就 SET key value EX 60），导致所有节点在整点同时失效。
- Redis 集群各节点时钟存在毫秒级偏差，
EX过期不是原子广播，可能分批失效，反而放大穿透压力 - 前端轮询或 WebSocket 推送倒计时，用户习惯性在最后 3 秒疯狂刷新，请求实际在倒计时归零前已积压
- MySQL 连接池默认 maxActive=20，1000 并发请求穿透后，98% 请求排队超时，触发 HikariCP 的
Connection is not available报错
用 Redisson 可重入锁 + 二次校验防穿透
不能等 GET 为空才加锁，必须把锁前置到缓存读取路径中，并严格控制锁持有时间。重点不是“谁来查 DB”，而是“谁都不该查 DB”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 锁 key 必须带业务上下文，例如
lock:seckill:goods:666，避免不同商品共用一把锁 -
tryLock(100, 10, TimeUnit.MILLISECONDS)：最多等待 100ms，锁超时 10ms，防止长尾请求拖垮整体 P99 - 加锁成功后必须二次
redisTemplate.opsForValue().get(cacheKey)，因为可能有其他线程在你等待锁期间已回写缓存 - 未抢到锁的请求，不返回空，而是降级读取本地兜底缓存（如 Guava Cache 中保留 1 分钟的 stale 数据）
倒计时前主动刷新缓存，消灭过期真空期
真正的防护不在击穿发生时，而在它发生前。把缓存过期视为一个“窗口”，而不是一个“时间点”。
- 后台定时任务每 3 分钟扫描
seckill:goods:*key，用PTTL获取剩余 TTL，当PTTL （即不足 10 分钟）时，主动调用 <code>refreshSeckillGoods(goodsId) - 刷新逻辑复用和主接口相同的查库 + 写缓存流程，但跳过锁逻辑（此时无并发风险），并设置新 TTL = 原 TTL + 300000（+5 分钟缓冲）
- 关键点：刷新动作本身要幂等，且不依赖倒计时服务状态——哪怕倒计时服务宕机，缓存仍能续命
别忽略客户端和网关层的协同过滤
Redis 层再强，也扛不住无效请求。倒计时结束瞬间的请求里，至少 40% 是重复提交、脚本刷量或已失败用户的重试。
- 网关层按
uid + goodsId维度限流，例如rate-limit:seckill:12345:666，1 秒内只放行 1 次 - 前端按钮置灰后，禁止 JS 主动发起第二次
fetch('/seckill')，同时服务端校验请求头是否含X-Request-ID（由网关注入） - 对
GET /seckill/count?goodsId=666这类纯查询接口，直接走 L1 本地缓存（Caffeine），TTL 设为 100ms，完全不碰 Redis
真正难的不是写对那段 tryLock 代码，而是确认「倒计时服务推送时间」、「Redis 各节点时钟漂移」、「前端 JS 执行延迟」、「网关限流生效延迟」这四者之间的误差边界。线上压测时，这个边界值往往比预想的小 3 倍——建议用 PTTL 日志 + 全链路 trace 对齐各环节时间戳，否则补丁永远打不准。
