缓存击穿最易发生在高热+刚过期场景，如秒杀商品详情页、热搜榜单首页、明星动态/突发新闻、用户vip权限状态等；其核心是热点key物理过期后并发请求直击数据库。
哪些业务场景最容易触发缓存击穿
缓存击穿不是随机发生的，它总在「高热 + 刚好过期」的组合下爆发。典型场景包括：
• 秒杀商品详情页：活动开始前缓存已预热，但 TTL 到点失效，瞬间 10k+ 请求涌向 product:10086
• 热搜榜单首页：每小时刷新一次，hotlist:20260713 在整点过期，大量用户同时刷新
• 明星动态/突发新闻：事件爆发后流量陡增，对应 post:9527 缓存未及时续期，过期后并发查库
• 用户中心核心数据：如 VIP 权限状态 vip_status:123456，若设固定 24h 过期且无兜底，到期即成单点瓶颈
用逻辑过期替代物理过期是关键一步
物理过期（EXPIRE）会让 key 真实消失，触发所有请求同时打库；逻辑过期则把过期判断移到值内部，key 始终存在。
具体做法：
• 序列化时往 value 里嵌入一个 expireAt 时间戳字段（如 JSON 中加 "expireAt": 1720847100000）
• 读取时先解析 JSON，检查 expireAt 是否已过期
• 若已过期，不删 key，而是用 SETNX 尝试获取重建锁，仅首个线程查 DB 并更新整个 value（含新 expireAt）
• 其他线程直接返回旧数据，避免雪崩式等待
注意：必须确保写入时带完整结构，不能只更新部分字段，否则 expireAt 可能被覆盖丢失
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
分布式互斥锁必须带超时和自动释放
用 SETNX 加锁本身简单，但生产环境常见错误是锁没释放或永久阻塞：
• 锁 key 必须设置过期时间（如 SET lock:product:10086 "1" EX 30 NX），否则服务异常崩溃会导致锁残留
• 不要用 DEL 直接删锁——得用 Lua 脚本保证“判断+删除”原子性，防止误删他人锁
• 等待锁的线程建议设最大重试次数（如 3 次）和间隔（如 50ms），超时后降级返回或抛异常，别无限自旋
• 如果用 Redisson，直接调 RLock.lock(30, TimeUnit.SECONDS)，它内置看门狗机制，不用手动续期
永不过期 + 主动刷新适合强一致性要求的场景
对秒杀库存、账户余额这类数据，逻辑过期可能造成短暂脏读，这时更适合永不过期 + 定时刷新：
• 初始化时用 SET product:10086 "{...}"（不带 EX 参数）
• 启动定时任务（如 Quartz 或 XXL-JOB），每 5 分钟查一次 DB，仅当数据变更才更新缓存
• 更新前先比对版本号或 updated_at 字段，避免无效写入
• 配合监听 Binlog（如 Canal）做实时同步，延迟可压到 200ms 内
这个方案真正难点不在代码，而在刷新频率与 DB 压力的平衡——刷太勤拖垮数据库，刷太懒缓存滞后，得靠监控 cache_age_seconds 指标动态调参
