先说结论：缓存和数据库一致性没有银弹，只有取舍。你选了强一致，就得牺牲性能；你选了高性能，就得接受短暂的不一致。这跟找对象似的，想要长得好看的，就得容忍点小脾气，想要脾气好的，就得接受长相普通。今天聊的这三种解法，本质上就是在不同场景下做的权衡，至于怎么落地，得看你的业务到底缺什么。
第一种解法，也是最简单粗暴的：先更新数据库，再删除缓存。这招被很多人叫“Cache Aside”模式，实际开发里用得最多。逻辑不复杂——你改了用户信息，先写库，然后把对应的缓存key删了，下次读的时候再回源查库，把新数据写回缓存。好处是代码改动量小，几乎不引入额外的中间件，而且性能损耗极低。但问题也明显：如果删除缓存这步失败了，缓存里就永远是旧数据，直到它自然过期。为了补救，很多人会加个重试机制，比如发个消息队列，让消费者去删，但这就多了一套基础设施，复杂度上来了。还有种更尴尬的情况：两个并发请求，一个读一个写，读请求先把旧数据写回缓存，写请求再删缓存——结果缓存里留下的还是旧数据。这种概率很低，但一旦碰上，业务就得忍受一段时间的脏读。
第二种解法，是引入消息队列，用最终一致性来兜底。思路是这样的：写操作先落库，然后发一条“数据已变更”的消息到MQ，专门有个消费者去删缓存或者更新缓存。好处是解耦，写库和删缓存之间隔了一层消息，数据库的压力小了，缓存更新的失败率也低了，因为MQ自带重试机制。这个方案在电商、订单这类场景特别常见，比如你下单后库存变了，但用户看到的最新库存可能延迟个几秒钟，这业务上能接受。但代价是链路变长了，你得维护MQ集群，还得处理消息乱序、重复消费、消息丢失这些问题。更麻烦的是，如果业务对实时性要求高，比如账户余额、秒杀库存，这种延迟几秒的最终一致性可能就扛不住了。所以说，最终一致性不是“不准确”，而是“延迟准确”，你得判断业务能不能等这几秒。
第三种解法，是强一致方案，具体做法是“先删缓存，再更新数据库”，配合延迟双删或者加锁。这招的出发点很简单：既然删缓存可能失败，那不如先删缓存，让所有读请求都打不到旧数据，等数据库更新完，再删一次缓存（也就是延迟双删），确保一次删能把并发期间写进缓存的旧数据清掉。这么做确实能把不一致的时间窗口压到毫秒级，但代价不小。你得估算好缓存重建的时间，设置合理的延迟值，否则双删的第二次删太早，旧数据已经回写缓存了；太晚，又白白多一次缓存穿透。还有一个更狠的变种：在读写路径上加分布式锁，读请求发现缓存为空就尝试加锁回源，写请求先拿锁再更新库再删缓存，完全串行化。这种方案一致性最好，但性能损耗最大，并发一高，锁竞争能把QPS打到惨不忍睹。所以，除非是金融、支付这类绝对不允许错的场景，一般业务真没必要上锁。
落地的时候，你还要考虑缓存本身的生命周期。很多团队喜欢给缓存设短过期时间，比如30秒或1分钟，这其实是个非常好的“安全网”。哪怕上面三种方案都出了岔子，缓存过期后强制回源，也能把数据纠回来。但这里有个坑：过期时间设得太短，缓存命中率直线下降，数据库压力陡增；设得太长，脏数据留存时间太久。所以，比较成熟的做法是“兜底过期时间+主动更新策略”结合，让缓存既不会无限期脏，也不会频繁失效。另外，缓存的数据结构也要留意，如果你存的是整个用户对象，而业务只改了其中一个字段，那更新缓存时最好做字段级合并，别整个覆盖，否则并发写同一个对象时，容易出现互相覆盖、丢更新的问题——这属于实现细节，但往往就是这些细节决定方案靠不靠谱。
再往后走，你会发现很多大厂其实不是只用一种方案，而是按读多写少、写多读少、强一致要求等维度拆成多个服务，每个服务用自己的策略。比如商品信息这种读多写少、容忍秒级延迟的，用Cache Aside加消息队列就够；订单状态这种写多读少、用户实时查的，可能就得用延迟双删加短过期；而余额、库存这种强一致敏感型，干脆不走缓存，直接走数据库，或者用Redis的原子操作加分布式锁。说到底，缓存一致性问题的本质不是“技术选哪个”，而是“业务能接受多少不一致”。你把这个问题想清楚了，方案自然就出来了。
说句掏心窝的话：很多人一上来就追求完美方案，把系统搞得复杂无比，结果上线后三天两头出故障，反而不如一个简单的方案跑得稳。缓存与数据库一致性，本质是CAP理论在业务层的一个投影——你永远只能选两个，不能全都要。与其纠结怎么做到绝对一致，不如先想清楚你的业务到底能容忍多少数据不一致，然后选一个实现成本最低、运维最不费劲的方案。毕竟，大多数业务场景下，用户不会盯着你的缓存看，他们只在乎页面刷出来的时候，数据是不是说得过去。所以，别被“一致性”这三个字吓住，它没你想的那么玄乎，落地才是王道。
