热点数据怎么缓存不失效

“热点数据怎么缓存不失效”本质上是高并发系统里的一个经典难题：热点数据访问频繁、对一致性要求高，但又不能让它因为过期、淘汰、刷新风暴等问题“失效”。下面从设计原则 → 常见方案 → 实战套路三个层面讲清楚。

一、先明确：什么叫“缓存失效”

通常包括：

1. 过期失效：TTL 到期被清理
2. 淘汰失效：内存不足被 LRU/LFU 挤掉
3. 更新失效：数据变更后缓存没及时更新
4. 雪崩失效：大量 key 同时失效

二、核心设计原则（很重要）

热点数据 ≠ 普通缓存

热点数据要：

• 不过期或超长过期
• 主动更新，而非被动等失效
• 多层防护，避免单点失效

三、常见可靠方案（按推荐程度）

✅ 方案 1：热点数据“永不过期 + 主动刷新”

最常用、最稳

做法：

• 缓存 不设 TTL 或设很长（如 7 天）
• 数据变更时：
  • 写 DB
  • 同步/异步更新缓存
• 后台定时任务兜底刷新

DB 更新 → 清/写 Cache → 定时兜底

✅ 优点：几乎不会“自然失效” ❌ 注意：必须有更新机制，否则是脏数据

✅ 方案 2：逻辑过期（推荐）

解决“物理过期”问题

缓存结构：

{
  "data": "...",
  "expireTime": 1730000000
}

读取时：

• 没到逻辑时间 → 直接返回
• 到了 → 异步刷新，先返回旧数据

✅ 优点：

• 用户无感知
• 避免击穿、雪崩

✅ 方案 3：本地缓存 + 分布式缓存（双层）

扛极端热点（如秒杀、爆款）

架构：

请求 → 本地缓存(Caffeine) → Redis → DB

• 本地缓存：
  • 不过期或短过期
  • 通过 MQ / 配置中心主动推
• Redis：
  • 作为统一真相源

✅ 抗百万 QPS 的热点非常稳

✅ 方案 4：热点探测 + 自动“保活”

大厂常用

流程：

1. 统计访问频率
2. 识别热点 key
3. 自动：
   • 延长 TTL
   • 提升优先级（不被 LRU 淘汰）
   • 多副本缓存

如：

• Redis + 热点监控
• 本地 LFU 保活

✅ 方案 5：写时双写 / 订阅 Binlog

强一致场景

• Canal 监听 MySQL
• 数据变更 → 自动更新 Redis
• 缓存“不依赖过期”

✅ 适合：

• 订单
• 库存
• 用户核心信息

四、防止“看起来没失效但其实坏了”

必须做的安全措施

1. 互斥重建（防击穿）
   • 单飞（singleflight）
2. 降级返回旧值
3. 监控命中率 & 延迟
4. 缓存与 DB 一致性校验

五、一句话总结

热点数据“不失效”的关键不是“设成不过期”，而是：

• 不依赖过期
• 主动更新
• 多层保护
• 异步兜底

如果你愿意，我可以：

• 按 Redis / Caffeine / 多级缓存 给你具体代码
• 或针对 秒杀 / 电商 / 社交 场景细化方案

你现在是哪种业务场景？