你有没有发现，刷同一个新闻网站，第二次打开时总比第一次快？这背后大概率是缓存机制在起作用。简单说，缓存就像把常用数据先“抄一份”放在离你更近的地方，比如内存或浏览器里，下次取的时候不用再跑一趟数据库。
缓存让系统变快，但也可能出“幻觉”
举个例子，你在电商网站下单买了一件T恤，付款成功后页面显示“库存还剩99件”。可这时候，另一个用户刚刷新页面，看到的还是“库存100件”——明明已经被你买走一件了。这种情况，往往就是缓存没及时更新导致的。
数据库里的数据是最准的，但读写慢；缓存速度快，可一旦和数据库对不上，就会出现数据不一致。这种“表面快，实际乱”的问题，在高并发场景下特别常见。
常见的缓存策略有哪些？
最简单的做法是“Cache Aside”，也就是应用在读数据时先查缓存，没找到再去数据库拿，然后顺手写进缓存；写数据时，先更新数据库，再把缓存删掉。这样下次读请求进来，自然会从数据库取新值重新填充缓存。
// 读操作伪代码
function getData(key) {
data = redis.get(key);
if (data == null) {
data = db.query("SELECT * FROM table WHERE id = ?", key);
redis.setex(key, 3600, data); // 缓存一小时
}
return data;
}
// 写操作伪代码
function updateData(id, value) {
db.execute("UPDATE table SET value = ? WHERE id = ?", value, id);
redis.del("cache_key_" + id); // 删除旧缓存
}为什么删了缓存，有时还是不对？
问题出在“时间差”。比如两个线程同时操作：线程A要更新数据，先改数据库，正准备删缓存；这时线程B来读数据，发现缓存没了，就去数据库查，结果查到的是还没完全更新完的中间状态，接着又把这个“脏数据”写回了缓存。等A删缓存的操作执行完，B已经把旧数据复活了。
为缓解这个问题，有人采用“延迟双删”：更新前先删一次缓存，更新完数据库后再删一次，尽量把脏数据的存活时间压短。还有方案是用消息队列把数据库变更同步给缓存服务，确保最终一致。
读写多副本时更要小心
有些系统为了扛住流量，数据库做了主从分离，写走主库，读走从库。可从库同步有延迟，这时候如果缓存也跟着从库走，就可能出现你刚发的朋友圈，自己刷不到，别人却看到了。这类问题不能光靠缓存解决，得在业务逻辑上做取舍，比如关键操作强制走主库读。
缓存不是万能加速器，它和数据库之间的步调必须协调好。设计系统时，得想清楚：允许短暂不一致吗？用户能容忍几秒的延迟？这些问题决定了你该用哪种策略。
小网站也能用的实用建议
如果你维护的是中小型网站，不必一上来就搞复杂同步机制。可以给缓存设个较短的过期时间，比如5分钟。即使中间出点偏差，最多几分钟也能自动纠正。配合写数据库时主动清理相关缓存，大多数场景就够用了。
另外，别忘了加日志。当发现数据对不上时，能通过日志看出是缓存没删、删晚了，还是读到了从库的旧数据，排查起来才不抓瞎。