缓存冷热数据分离：让服务器响应更快的实用技巧
你有没有遇到过这种情况：用户一查历史订单，系统就卡一下？或者后台报表一跑，线上接口全变慢？问题可能不在数据库，而在于你的缓存没分清楚“谁热谁冷”。
在实际运维中，不是所有数据都值得放在 Redis 里拼命读写。比如用户最近三天的登录记录，访问频繁，这是“热数据”；而三年前的订单日志，几乎没人查，却和热门商品一起挤在缓存里——这就是典型的资源浪费。
什么是冷热数据？
简单说，热数据是被高频访问的，比如当前热门商品信息、登录会话、实时库存；冷数据则是低频甚至几乎不访问的，比如历史日志、归档订单、旧用户行为记录。
把它们混在一起，会导致两个后果：一是缓存空间被冷数据占满，真正需要的数据反而被淘汰；二是冷数据偶尔被访问时，可能触发缓存穿透或雪崩，拖垮服务。
怎么实现分离？
常见的做法是在业务层做数据路由。比如在查询时判断时间维度或访问频率：
if (request.isRecentData()) {
// 走 Redis 缓存
data = redis.get(key);
} else {
// 直接查数据库或走本地缓存 + 异步加载
data = db.queryArchive(key);
}也可以用多级缓存策略。一级缓存放热数据，TTL 设置短一些，比如 5 分钟；二级缓存放温数据，TTL 设为几小时；冷数据干脆不缓存，或者用压缩格式存到磁盘缓存里。
有些团队还会加一个“热度计数器”，记录 key 的访问次数。超过阈值自动升级为热数据，长时间不访问就降级。就像超市货架，畅销品摆在入口，滞销的挪到仓库去。
别忘了清理机制
分离之后更关键的是清理。比如每天凌晨跑个定时任务，扫描 Redis 中超过一周未访问的 key，迁移到低优先级存储或直接删除：
SCAN 0 MATCH user:log:* COUNT 1000
FOR each key in results:
if (ttl(key) > 604800 && last_access(key) < one_week_ago) {
migrateToColdStorage(key);
}
ENDFOR这样做下来，Redis 内存占用能降 30% 以上，响应速度也更稳定。特别是大促期间，不会因为有人翻老订单就把缓存池打爆。
冷热分离不是什么高深技术，更像是种运维习惯。就像整理衣柜，常穿的衣服挂外面，过季的收进收纳箱。系统也一样，分清主次，才能跑得轻快。