Redis 缓存更新策略与热点数据识别
Redis 缓存更新策略与热点数据识别
在高并发系统中，缓存是提升性能的“银弹”，但缓存不是万能的。用得好，系统丝滑流畅；用得不好，反而成为系统瓶颈甚至雪崩源头。
本文将系统性地探讨两个核心问题：
- 哪些数据才是“热点数据”？
- 如何通过更新与淘汰策略，让缓存始终服务于热点？
并进一步解析 缓存预热、穿透、雪崩、击穿 四大经典问题的成因与解决方案，助你构建一个智能、健壮、自适应的缓存体系。
一、热点数据：缓存系统的“心脏”
缓存的本质是空间换时间，但内存资源有限，不可能缓存所有数据。因此，必须精准识别并优先服务“热点数据（Hot Data）”。
那么，如何定义和识别热点数据？
1.1 定期生成：离线统计，适合稳定场景
原理： 周期性（如每日/每周）统计访问频次，筛选出访问量最高的前 N% 数据作为热点。
案例：搜索引擎高频词表
- 用户搜索行为被记录为日志。
- 使用 Hadoop/Spark 等大数据工具进行离线分析。
- 生成“高频词表”并预热到缓存中。
优点：
- 实现简单，资源消耗低。
- 适合访问模式稳定的业务（如电商类目页）。
缺点：
- 实时性差：无法应对突发流量。
- 例如：春节期间“春晚”突然成为高频词，但离线统计无法及时响应。
适用场景：访问模式变化缓慢、可预测的业务。
1.2 实时生成：动态识别，自适应热点
原理： 不预先定义热点，而是让缓存系统在运行过程中自动识别并保留热点数据。
流程：
- 设置缓存容量上限（
maxmemory）。 - 每次查询：
- 命中 → 返回。
- 未命中 → 查 DB → 写入缓存。
- 缓存满时 → 触发淘汰策略，移除“冷数据”。
经过一段时间运行，缓存中自然留存的便是当前的热点数据。
这是一种“数据驱动”的智能缓存策略，是现代系统的主流选择。
二、缓存淘汰策略：谁该被淘汰？
当缓存空间不足时，必须决定“谁走谁留”。以下是通用的淘汰算法，不仅适用于 Redis，也适用于任何缓存系统。
2.1 通用淘汰算法
| 策略 | 原理 | 类比（后宫选秀） |
|---|---|---|
| FIFO (First In First Out) | 淘汰最先进入缓存的数据 | 皇后年老色衰，失宠 |
| LRU (Least Recently Used) | 淘汰最近最少使用的数据 | 华妃一个月前被宠幸，失宠 |
| LFU (Least Frequently Used) | 淘汰访问频率最低的数据 | 安答应一个月只被宠幸1次，失宠 |
| Random | 随机淘汰 | 随机选一位妃子失宠 |
关键区别：
- LRU 关注“最近一次访问时间”
- LFU 关注“历史访问频率”
LFU 更适合识别长期热点，而 LRU 对短期突发访问更敏感。
三、缓存“崩”：问题与解决方案
3.1 缓存预热（Cache Preheating）
问题： Redis 重启或大批 key 失效后，缓存为空，所有请求直达 DB，造成瞬时压力。
解决方案：
- 系统启动时，主动加载热点数据到 Redis。
- 热点数据可来自离线统计或历史访问日志。
- 预热不需完全精确，随着运行，缓存会自动调整。
# 示例：通过脚本预热
redis-cli -x SET hot:user:1001 < user_1001.json
3.2 缓存穿透（Cache Penetration）
问题： 查询一个在 DB 中也不存在的 key，每次都会穿透到 DB。
成因：
- 非法请求（如黑客攻击）
- 数据被误删
- 参数未校验
解决方案：
- 参数校验：对输入进行合法性检查（如手机号格式）。
- 缓存空值：对不存在的结果也缓存
null，设置短 TTL（如 5min）。 - 布隆过滤器（Bloom Filter）：在缓存前加一层过滤，快速判断 key 是否可能存在。
布隆过滤器：用少量空间判断元素“一定不存在”或“可能存在”，误判率可控。
3.3 缓存雪崩（Cache Avalanche）
问题： 大量 key 在同一时间过期，或 Redis 宕机，导致 DB 瞬间压力激增。
成因：
- 批量设置相同过期时间。
- Redis 集群故障。
解决方案：
- 随机过期时间：
TTL = 基础时间 + 随机偏移（如3600 ± 300s）。 - 高可用架构：主从 + 哨兵 + 集群，避免单点故障。
- 服务降级：DB 压力过大时，返回默认值或错误码。
3.4 缓存击穿（Cache Breakdown）
术语澄清： “击穿”易与“穿透”混淆。更准确的描述是“热点 key 突然失效导致的瞬时高并发”。
问题： 某个热点 key 过期，大量并发请求同时涌入，全部打到 DB。
解决方案：
- 永不过期（逻辑过期）：不设置 TTL，由后台线程异步更新。
- 互斥锁（Mutex）：使用
SETNX或 Redlock，确保只有一个线程重建缓存。
# 示例：使用 SETNX 加锁重建缓存
SET lock:hotkey true EX 10 NX
# 成功获取锁的线程查询 DB 并更新缓存