更新数据库后怎么更新缓存？先更新数据库还是先更新缓存？

在构建高并发、高性能的分布式系统架构时，确保数据库与缓存之间的数据一致性是至关重要的技术难题，针对“更新数据库后更新缓存”这一场景，业界经过长期的实践验证，得出了一条核心结论：为了保证数据的一致性与系统的高可用性，应当采取“先更新数据库，再删除缓存”的策略，并配合延时双删或消息队列机制来处理极端情况下的并发问题。 这一策略并非简单的顺序执行，而是基于对数据库事务特性、缓存失效机制以及并发竞态条件的深刻理解而得出的最佳实践。

数据一致性面临的挑战与核心原则

在典型的应用架构中，数据库（如MySQL）承担着数据的持久化存储，而缓存（如Redis）则承担着减轻数据库压力、加速读取的重任，由于这两个存储系统在物理上是独立的，无法通过ACID事务来保证跨系统的原子性操作，因此必然存在数据不一致的时间窗口，当执行写操作时，如果处理不当，就会出现“数据库是新值，缓存是旧值”的脏读现象，严重影响业务逻辑的正确性，设计缓存更新策略的核心原则在于：在保证最终一致性的前提下，尽可能缩小不一致的时间窗口，并避免产生雪崩效应。

四种常见缓存更新策略的深度剖析

为了找到最优解,我们需要对常见的几种策略进行严谨的对比分析。

第一种是“先更新缓存，再更新数据库”，这种方案最大的风险在于，如果缓存更新成功，但数据库更新失败，会导致缓存中存在数据库中不存在的脏数据，且一旦后续发生缓存失效，系统会尝试从数据库读取该不存在的数据，导致严重的逻辑错误,这种方案在严肃的生产环境中是被摒弃的。

第二种是“先更新数据库，再更新缓存”，这是许多初级开发者直觉上的选择，在并发场景下，这存在严重的隐患，假设线程A和线程B同时更新同一条数据，线程A先更新数据库，线程B后更新数据库；但由于网络波动或处理速度不同，可能线程B先更新了缓存，线程A后更新了缓存，最终结果是：数据库中是线程B的新值（正确），但缓存中是线程A的新值（错误）,这种并发竞态会导致数据长期不一致。

第三种是“先删除缓存，再更新数据库”，这种方案看似合理，但在极端并发下也会失效，假设线程A删除缓存，正准备更新数据库时，线程B进来读取数据，发现缓存未命中，于是去数据库读取旧值并写入缓存，此时线程A完成数据库更新，结果就是：数据库是新值，缓存中却被线程B写入了旧值，且如果不设置过期时间,这个脏数据将一直存在。

第四种是“先更新数据库，再删除缓存”，这是目前公认的最优方案，为什么它最可靠？因为数据库的写操作通常比缓存删除操作慢得多，在“先删缓存，更库”方案中，读操作很容易在写操作更新数据库之前发生并重建缓存，但在“先更库，再删缓存”方案中，读操作必须在写操作更新数据库之后、删除缓存之前发生，且读操作必须比写操作慢，才会导致旧值被写入缓存，根据统计，这种情况发生的概率极低，因为数据库的“写”耗时远大于缓存的“删”耗时,这种策略从概率上最大程度地规避了脏数据的产生。

为何选择“删除”而非“更新”缓存

在确定了“先更新数据库，再删除缓存”的大方向后，还需要明确操作是“更新”还是“删除”。强烈建议采用“删除缓存”而非“更新缓存”。 采用懒加载模式，即删除缓存后，下次读取时再从数据库加载并写入缓存，具有显著优势，计算成本更低，如果每次写操作都重新计算缓存值，但在该缓存值很少被读取的情况下，会造成巨大的计算资源浪费，避免并发写入冲突，如果是“更新缓存”，两个线程同时更新可能会导致覆盖问题，而“删除缓存”则将复杂的并发控制简化了。

高并发场景下的终极解决方案：延时双删与异步重试

虽然“先更库，再删缓存”在绝大多数情况下是有效的，但在极端苛刻的 consistency 要求下，为了防止那“极低概率”的脏读发生，可以引入延时双删策略，即：先删除缓存，再更新数据库，休眠一小段时间（比如500毫秒），再再次删除缓存，休眠的目的是为了让那个在“第一次删除”和“更新数据库”之间读取了旧数据的并发线程，能够完成将旧数据写入缓存的操作,随后的第二次删除就能彻底清除这个旧值。

如果“删除缓存”这一步失败（例如Redis抖动），就会导致缓存永久不一致，为了解决这一问题，必须引入重试机制，但为了保证业务主流程的性能，重试不应在主线程中进行，专业的解决方案是：将需要删除的缓存Key发送到消息队列（如Kafka、RabbitMQ），由独立的消费者服务负责消费消息并执行缓存删除操作。 如果删除失败，消费者可以进行有限次数的重试，或者记录死信日志供人工处理，这种异步重试机制完美地保证了数据最终一致性,且不阻塞主业务流程。

处理数据库与缓存一致性的问题，不能仅凭直觉，而必须基于严谨的并发控制理论。“先更新数据库，再删除缓存”是基础策略，“删除而非更新”是性能优化的关键，而“延时双删”配合“消息队列异步重试”则是应对高并发与极端故障的专业保障。 只有构建了这样一套多层级的防护体系，才能在享受缓存带来的高性能红利的同时,确保系统的数据资产准确无误。

相关问答

Q1：为什么在“先更新数据库，再删除缓存”策略中，推荐使用消息队列来执行删除操作？
A1： 使用消息队列主要是为了保证系统的健壮性和最终一致性，如果在主业务线程中直接删除缓存失败，会导致数据不一致，通过将删除操作发送到消息队列，可以实现异步处理：即使消息队列短暂不可用，只要消息最终投递成功，消费者就能确保缓存被删除，如果消费者删除失败，还可以利用消息队列的重试机制进行多次尝试，直到成功或达到阈值报警,从而彻底避免因单点故障导致的脏数据长期驻留问题。

Q2：在延时双删策略中，中间休眠的时间应该如何设定？
A2： 休眠时间的设定需要评估业务中“读操作+写缓存”的总耗时，这个时间的目标是大于“读取数据库数据并写入缓存”的耗时，通常建议设定在200毫秒到500毫秒之间，如果设置过短，可能无法覆盖并发读操作完成缓存写入的时间；设置过长则会影响数据更新的可见性延迟，开发者需要对核心业务路径的耗时进行监控和压测,从而得出一个合理的经验值。

互动环节

您在项目中是如何处理缓存与数据库一致性的？是否遇到过因为缓存策略不当导致的线上事故？欢迎在评论区分享您的实战经验和独到见解,我们一起探讨更优的解决方案。