为什么缓存更新这么重要
你有没有遇到过这种情况：在电商App里抢限量商品，页面显示还有库存，点进去却提示已售罄？或者公司内部系统刚改了配置，刷新好几遍还是老样子。这些问题，往往就出在缓存更新没跟上。
缓存就像大脑的短期记忆，速度快但容易过时。一旦数据变了，缓存不及时更新，用户看到的就是“假消息”。特别是在高并发场景下，比如秒杀、抢票，差个几百毫秒，结果可能天差地别。
常见的缓存策略有哪些
最简单的做法是“先更新数据库，再删缓存”。用户改了头像，系统先把新图片存进数据库，然后把旧缓存删掉。下次请求来的时候，发现缓存没了，就会重新从数据库取数据，顺便重建缓存。这个方法叫 Cache Aside Pattern，用的人最多。
但这里有个坑：如果删缓存失败了呢？比如网络抖动，缓存没删干净，接下来读到的还是旧数据。更麻烦的是，两个线程同时操作，一个在写数据库，一个在读缓存，很容易撞上数据不一致。
怎么减少数据不一致的风险
一种改进思路是“延迟双删”。第一次删缓存放在更新数据库之前，先把旧缓存干掉；等数据库写完，再删一遍。中间加个几百毫秒的延迟，给读请求留出空档，避免它在数据库更新过程中读到旧值并重新塞回缓存。
代码可以这样设计：
// 伪代码示例：延迟双删
deleteCache(KEY);
updateDB(data);
Thread.sleep(100); // 延迟100ms
deleteCache(KEY);虽然sleep会影响性能，但在强一致性要求高的场景，这点代价值得。
用消息队列解耦更新流程
更大的系统会把缓存更新丢给消息队列。比如用户提交订单后，主流程只管写数据库，然后发个消息到MQ，由下游消费者负责清理对应的缓存。这样即使缓存服务暂时不可用，消息也能重试，不会拖垮主业务。
举个例子，新闻网站发布一篇爆款文章，评论数瞬间暴涨。如果每次评论都同步更新缓存，数据库和缓存压力都会爆炸。换成异步方式，先把评论落库，再通过消息通知缓存服务增量更新，系统更稳，用户体验也更好。
缓存预热：别让用户当试验品
系统重启或大促前，缓存往往是空的。这时候大量请求直接打到数据库，很容易被压垮。聪明的做法是提前把热点数据加载进缓存，比如把首页商品、热门榜单这些“必访之地”先刷一遍。
就像奶茶店开门前先把招牌饮品的原料备好，顾客一来就能快速出杯，不用干等着现做。缓存预热就是这个道理——别让用户替你暖机。
监控和降级同样关键
再好的机制也得配上监控。记录缓存命中率、更新延迟、失败次数，一旦发现异常，比如命中率突然暴跌，可能是更新逻辑出问题了。这时候可以临时切换到“只读旧缓存”模式，保证系统能用，再慢慢排查。
有些团队还会设置“缓存版本号”，比如给每个用户数据加上 version 字段。缓存里存的是 v1，更新后变成 v2，所有请求带上版本判断，避免旧缓存被误用。虽然多了一次比较，但换来的是更高的可靠性。