Redis缓存与数据库如何保证一致性？同步删除+延时双删+异步监听+多重保障方案

导航：

【Java笔记+踩坑汇总】Java基础+JavaWeb+SSM+SpringBoot+SpringCloud+瑞吉外卖/谷粒商城/学成在线+设计模式+面试题汇总+性能调优/架构设计+源码解析

目录

一、四种基础同步策略

1.1 同步策略

1.2 更新缓存还是删除缓存？

1.2.1 更新缓存的优缺点

1.2.2 删除缓存的优缺点（推荐）

1.3 先操作数据库还是先删除缓存?

1.3.1 先删除缓存再操作数据库的优缺点

1.3.2 先操作数据库再删除缓存的优缺点（推荐）

1.4 最优同步策略：先更新数据库、再删除缓存

二、同步删除+可靠消息方案

三、延时双删：更高一致性方案

四、异步监听+可靠消息删除方案

五、多重保障：最终强一致方案

---

一、四种基础同步策略

1.1 同步策略

保证缓存和数据库的双写一致性，共有四种同步策略，即先更新缓存再更新数据库、先更新数据库再更新缓存、先删除缓存再更新数据库、先更新数据库再删除缓存。 

• 先更新缓存再更新数据库：第二步失败缓存库是脏数据
• 先更新数据库再更新缓存：第二步失败缓存库是旧数据
• 先删除缓存再更新数据库：第二步失败缓存库是空数据
• 先更新数据库、再删除缓存（推荐）：第二步失败缓存库是旧数据 

1.2 更新缓存还是删除缓存？

1.2.1 更新缓存的优缺点

更新缓存的优点是每次数据变化时都能及时地更新缓存，这样不容易出现查询未命中的情况，但这种操作的消耗很大，如果数据需要经过复杂的计算再写入缓存的话，频繁的更新缓存会影响到服务器的性能。如果是写入数据比较频繁的场景，可能会导致频繁的更新缓存却没有业务来读取该数据。

1.2.2 删除缓存的优缺点（推荐）

删除缓存的优点是操作简单，无论更新的操作复杂与否，都是直接删除缓存中的数据。这种做法的缺点则是，当删除了缓存之后，下一次容易出现未命中的情况，那么这时就需要再次读取数据库。 

那么对比而言，删除缓存无疑是更好的选择。 

1.3 先操作数据库还是先删除缓存?

1.3.1 先删除缓存再操作数据库的优缺点

情况1：数据库和缓存内容不一致

线程1删除缓存后还没有来得及更新数据库时，线程2读缓存，由于缓存中的数据已经被线程1清空了所以线程2需要去数据库读数据，然后把读到的结果保存到缓存中。此时线程1更新更新数据库成功。就会出现数据库和缓存内容不一致。

情况2：缓存击穿，数据库卡死

线程1删除缓存后还没有来得及更新数据库时，来了大量的读请求，由于缓存中没有数据，导致缓存击穿直接将大量请求访问到数据库，导致数据库崩溃。

1.3.2 先操作数据库再删除缓存的优缺点（推荐）

脏数据问题：先操作数据库但删除缓存失败的话，导致缓存库里一直存留着旧数据，而我们数据库里存的是新数据。

解决办法：异步重试机制

出现上述问题的时候，我们一般采用重试机制解决，而为了避免重试机制影响主要业务的执行，一般建议重试机制采用异步的方式执行。当我们采用重试机制之后由于存在并发，先删除缓存依然可能存在缓存中存储了旧的数据，而数据库中存储了新的数据，二者数据不一致的情况。

1.4 最优同步策略：先更新数据库、再删除缓存

所以我们得到结论：先更新数据库、再删除缓存是影响更小的方案。如果第二步出现失败的情况，则可以采用重试机制解决问题。

同步删除方案： 先更新数据库、再删除缓存。适用于不强制要求数据一致性的情景

流程：先更新数据库、再删除缓存。

问题：

• 并发时脏数据：在查询数据库到写缓存期间其他线程执行了一次更新删除，导致缓存的数据是旧数据
• 缓存删除失败：删除失败导致缓存库还是旧数据

二、同步删除+可靠消息方案

同步删除+可靠消息删除： 适用于不强制要求数据一致性的情景

流程：先更新数据库、再删除缓存，如果删除失败就发可靠MQ不断重试删除缓存，直到删除成功或重试5次。

问题：MQ多次重试失败，导致长期脏数据。

三、延时双删：更高一致性方案

延时双删方案：比同步删除策略一致性更高的方案。

流程：先删除缓存再更新数据库，大约在数据库从库更新后再删一次。

问题：时间无法控制，不能保证在数据库从库更新后删除缓存。如果在从库更新前删除，用户再在更新前查从库又把脏数据写在缓存里了。

四、异步监听+可靠消息删除方案

异步监听+可靠消息删除：很多大厂正在使用的方案。

流程：

1. 更新数据库后不做操作；
2. Canal等组件监听binlog发现有更新时就发可靠MQ删除缓存；
3. 如果删除缓存失败，就基于手动ack、retry等机制，让消息在有限次数之内不断重试。

优点：

• 异步删除，性能更高；
• 可靠消息重试机制，多次删除保证删除成功。

问题：要求canal等binlog抓取组件高可用，如果canal故障，会导致长期脏数据。

五、多重保障：最终强一致方案

多重保障方案：同步删除+ 异步监听+可靠消息删除，缓存时设置过期时间，查询时强制主库查；适合于强制要求数据一致性的情况

1. 同步删除：先更新数据库、再删除缓存；之后本链路禁止再查该数据，防止没来得及删缓存就又查到旧缓存数据。
2. Canal监听：Canal等组件监听binlog发现有更新时就发可靠MQ删除缓存；第二重保证删缓存成功；
3. 延迟消息校验一致性：Canal等组件监听binlog，发延迟MQ，N秒后校验缓存一致性；
4. 缓存过期时间：每次缓存时设置过期时间；第三重保证删缓存成功；
5. 强制Redis主库查：以后查缓存时强制从缓存主库查；因为主从同步有延迟，同时不用担心主库压力大，因为分片集群机制。