在高并发的互联网服务中，缓存几乎是标配。无论是电商商品详情、社交平台动态，还是后台配置信息，缓存都能大幅降低数据库压力，提升响应速度。但问题也随之而来：当数据在数据库更新了，缓存里的旧内容怎么办？这就是缓存策略与数据同步要解决的核心矛盾——既要快，又要准。
常见的缓存读写模式
先说最常见的做法：Cache-Aside（旁路缓存）。应用在读数据时，先查缓存，命中就直接返回；没命中就去数据库加载，再写回缓存。写操作则是先更新数据库，再删除缓存。
比如用户修改了自己的昵称，服务先更新数据库，然后把Redis里对应的用户缓存删掉。下次请求来的时候，发现缓存没了，就会重新从数据库加载最新数据。这种“延迟加载+主动失效”的方式简单有效，被很多系统采用。
删除还是更新缓存？
有人会问：为什么不直接更新缓存内容，而是选择删除？原因很简单：避免并发写导致的数据不一致。
想象两个线程同时修改同一个用户的信息。如果一个线程刚把缓存更新为“A”，另一个线程紧接着更新为“B”，但由于网络延迟，B的操作反而先到数据库，A后到。这时候缓存可能比数据库还旧。而删除缓存则规避了这个问题——不管怎么改，下次读的时候都以数据库为准。
双写一致性难题
即便删除缓存，也不能完全避免问题。比如数据库更新成功了，但缓存删除失败，那接下来读到的就是脏数据。这种情况虽然少见，但在节点宕机或网络抖动时确实可能发生。
为了解决这个问题，有些系统引入了消息队列。数据库变更后，把操作事件发到MQ，由消费者异步清理或更新缓存。这样即使删除失败，也能通过重试机制最终完成同步。
UPDATE users SET nickname = '新名字' WHERE id = 123;
-- 触发消息
INSERT INTO binlog_events (table_name, row_id, event_type) VALUES ('users', 123, 'update');更进一步的做法是监听数据库的binlog，用类似Canal这样的工具捕获变更，自动刷新缓存。这种方式对业务代码无侵入，适合复杂系统。
过期策略的巧妙运用
完全实时的一致性代价太高。很多时候，我们允许缓存短暂不一致。比如商品库存，在秒杀场景下必须强一致，但在普通浏览页，延迟一两秒也可以接受。
合理设置缓存TTL（生存时间），相当于给不一致上了个“保险”。即使同步出错，最多影响一段时间，之后自然恢复。配合随机过期时间，还能防止大量缓存同时失效造成的雪崩。
多级缓存中的同步挑战
现代系统往往有多个缓存层级：本地缓存（如Caffeine）、分布式缓存（如Redis）、CDN等。更新一处，其他层也要联动。
这时候通常靠发布-订阅机制。Redis本身支持Pub/Sub，当某条数据变更时，通知所有节点清除本地缓存。或者用ZooKeeper、etcd这类协调服务做状态广播。
举个例子，配置中心更新了一个开关，需要立刻生效。不能等缓存过期，就得通过消息通道推送到每一台机器，主动失效本地缓存。
没有银弹，只有权衡
缓存策略和数据同步不是选对方法就一劳永逸的事。不同场景需要不同方案。金融交易系统宁可慢一点，也要保证每一步都一致；而内容推荐系统更看重响应速度，容忍短暂偏差。
关键是在性能、复杂性和一致性之间找到平衡点。有时候最笨的办法——加日志、打监控、人工干预——反而是最可靠的兜底手段。