数据库与缓存最终一致性方案——延迟双删技术-CSDN博客

在实际开发中，我们常常会遇到这样的问题：数据库更新后，Redis 缓存数据与之不一致。虽然有多种解决方案，但并没有一种完美适配所有场景的方案。今天，我们就来深入探讨一种实用性较强的方案 —— 延迟双删。

常用缓存策略

在说正题之前，先介绍一下前置依赖，也就是缓存策略。

以下是一些常用的缓存策略：

基本思想 ：在查询数据时，先查询缓存，如果缓存中有数据（缓存命中），直接返回缓存数据；如果缓存中没有数据（缓存未命中），则从数据库查询数据，将查询结果写入缓存，再返回数据。
优点：缓存和数据库解耦，缓存系统和数据库系统相互独立，一个系统挂掉不影响另一个系统的使用。
缺点：可能出现缓存与数据库数据不一致的情况，如在写数据库后删除缓存的过程中，有请求查询缓存，此时缓存还没有更新，就会读取到旧数据。

延迟双删的技术方案，实际是采用缓存旁置（Cache-Aside）策略前提下，来提升数据一致性的技术方案。

在高并发的业务场景下，缓存击穿、缓存雪崩等问题频发。此时，若按照传统的 “先更新数据库，再删除缓存” 或 “先删除缓存，再更新数据库” 的方式，很容易出现缓存与数据库数据不一致的情况。

例如，当一个请求先删除了缓存，再更新数据库，但在这两个操作之间，有另一个请求查询缓存，发现缓存不存在，就会从数据库读取旧数据并重新写入缓存，这样就导致了缓存数据与数据库更新后的数据不一致。

延迟双删的核心思想是在更新数据库后，先删除一次缓存，然后等待一定时间，再次删除缓存，以确保缓存在数据库更新期间不会被旧数据污染。

具体操作步骤如下：

通过这种方式，可以最大限度地保证缓存数据与数据库数据的一致性。

以下是延迟双删的伪代码示例：

// 删除缓存
redis.delKey(key);
// 更新数据库
db.update(key, value);
// 等待一段时间，让数据库操作完成
Thread.sleep(500);
// 再次删除缓存
redis.delKey(key);

延迟双删适用于对最终一致性要求较高但能容忍一定延迟的场景。例如，在一些对实时性要求不高的业务系统中，如电商的商品详情页缓存、新闻资讯类应用的内容缓存等，都可以考虑使用延迟双删策略来保证数据的一致性。

先更新数据库，再删除缓存 ：这种方式在读操作较少的场景下效果较好，但如果读操作频繁，仍然可能出现缓存与数据库数据不一致的情况。
先删除缓存，再更新数据库 ：这种方式容易导致在缓存删除后、数据库更新前，其他请求将旧数据写入缓存的问题。
消息队列异步更新 ：通过消息队列来解耦数据库和缓存的更新操作，也可以保证数据的最终一致性，但会增加系统的复杂度和延迟。
Canal 监控 Binlog ：利用 Canal 监控的 Binlog 日志，实现准实时更新 Redis 缓存，保证数据一致性，但需要额外的运维成本和资源消耗。