大家好，我是小米，31 岁，写代码快十年了。如果你问我：
后端面试里，被问得最多、但被答得最烂的问题是什么？
我一定投 “缓存” 一票。尤其是这道看起来人畜无害的题：
“什么是热点数据？什么是冷数据？哪些数据适合缓存？”
很多同学第一反应是：热点数据访问多，冷数据访问少。 这话没错，但也几乎等于没说。
先讲个故事：仓库里的“黄金货架”
我先不讲技术，先讲一个仓库的故事。假设你开了一家大型连锁超市，后面有一个总仓库。
- 仓库空间有限
- 拣货员每天要跑来跑去拿货
- 离门口越近的货架，拿货越快
这时候，你会怎么摆货？答案很简单：
- 每天被拿几万次的矿泉水、泡面、可乐， 放在门口
- 一年卖不了几次的高端礼盒， 放最里面，甚至放分仓
在这个故事里：
缓存，本质上就是“黄金货架” 。不是所有货都配得上黄金货架。
热点数据：缓存才有价值
我们先下一个非常重要的结论：只有热点数据，缓存才有价值。
什么是热点数据？一句话版本：
在一段时间内，被大量重复访问的数据。
注意两个关键词：
- 一段时间内
- 重复访问
1. IM 产品里的“生日祝福”故事
我之前参与过一个 IM 产品。有一天，产品经理跑过来，眼睛放光：“我们要做一个生日祝福功能！”
逻辑很简单：
- 每天凌晨，统计今天过生日的用户
- 首页展示“今日寿星”
- 点进去可以一键祝福
技术同学一开始的实现是这样的：
然后：
- 每次打开首页查一次
- 每次点开模块查一次
- 每次下拉刷新再查一次
上线第一天就炸了。为什么？因为这是一个典型的热点数据：
- 数据 一天只变一次
- 但 一天会被访问几十万次
这时候，如果你还每次都查数据库，相当于：
仓库门口空着拣货员天天跑到最里面搬矿泉水
2. 正确姿势：热点数据 + 缓存
正确的做法是：
这一刀下去，数据库直接松了一口气。
3、为什么这个缓存有价值？
冷数据：缓存不仅没用，还浪费内存
接下来讲 冷数据。冷数据的定义也很简单：访问频率极低，甚至只访问一次的数据。
1. 冷数据为什么不适合缓存？
很多同学有个误区：“反正 Redis 很快，放进去也没啥坏处。”这是一个非常危险的想法。
冷数据放缓存，问题有三个：
- 还没再次访问，就被挤出内存
- 占用宝贵的缓存空间
- 增加系统复杂度，却没有收益
2. 一个真实翻车案例
有一次我们排查 Redis 命中率异常低。一看 Key：
这些是什么？
- 历史订单详情
- 用户只会点开一次
- 点完就再也不看
结果就是：
- 写入 Redis
- 没命中
- 被 LRU 淘汰
- 缓存命中率低到 5%
这时候缓存的角色是什么？高价垃圾桶。
3. 冷数据的正确姿势
频繁修改的数据，要不要缓存？
这是面试里最容易拉开差距的一问。很多同学会直接说：“频繁修改的数据不适合缓存。”
这句话 对一半，错一半。
一个最基础的缓存判断策略：
数据在更新前，至少被读取两次，缓存才有意义。
为什么？
- 第一次：写缓存
- 第二次：命中缓存
- 如果只有一次，那缓存等于白写
如果一个 Key：
- 刚写进去
- 立刻被更新或删除
那这个缓存 几乎没有任何价值。
但真的不存在“高频修改 + 必须缓存”的场景吗？
答案是：存在，而且非常常见。
1. 助手产品里的点赞数
我们做过一个助手类产品，有几个核心指标：
- 点赞数
- 收藏数
- 分享数
特点非常明显：
如果你说：“修改频繁，不缓存。”那数据库会第一个不同意。
2. 这类数据的本质是什么？
它们是：
- 热点数据
- 计数型数据
- 允许短暂不一
3. 正确解法：Redis 扛读写，DB 兜底
常见方案：
定时任务落库：
这样做的好处：
- 99% 请求不打 DB
- DB 压力骤降
- 用户体验极好
4. 面试官真正想听的点
你需要说清楚：
- 为什么要缓存
- 接受什么程度的不一致
- 如何保证最终一致
热点数据与冷数据对照表（面试必背）
总结一句“面试金句”
如果你时间不够，面试时可以直接甩这一段：
缓存的核心价值在于服务热点数据。
冷数据即使放入缓存，也很可能在再次访问前就被淘汰，既浪费内存，又增加系统复杂度。
对于高频读取的数据，只要在更新前能被读取多次，缓存就是有意义的；
对于高频修改但又是热点的数据，需要通过 Redis 扛住读写压力，再通过异步或定时方式保证最终一致性。
END
好朋友们，我们下篇见~
我是小米，一个喜欢分享技术的31岁程序员。如果你喜欢我的文章，欢迎关注我的微信公众号“软件求生”，获取更多技术干货！
