Redis和DB的缓存一致性

注意以下所出现的问题，都是相当于多个事务而言，【一个事物更新】，【另外一个事物读】而导致的数据不一致的问题。

为什么要双删：因为无论下面哪种单删都有问题

第一种方案：先更新数据库，再删除redis。
第二种方案：先删除redis，再更新数据库。

这两种方案的弊端是当存在并发请求时，很容易出现以下问题：

第一种方案：当请求1执行完更新数据库操作后，还未来得及删除redis，
此时请求2查询到并使用了redis中的旧数据。

第二种方案：当请求1执行完删除redis后，还未进行更新数据库操作，
此时请求2查询到了数据库的旧数据并写入了redis。

普通双删

问题：
事务A清空缓存后，在更新数据库前，事务B查询了数据库，但是还没有更新到缓存里面去。事务A清空缓存后：事务B在更新缓存，此时事务B把旧数据更新到缓存里面去了。

什么是延迟双删？

在三中，第二次清空缓存之前，多延时一会儿，等B更新缓存结束了，再删除缓存，这样就缓存就不存在了，其他事务查询到的为新缓存。

延迟双删策略是分布式系统中数据库存储和缓存数据保持【最终一致性】的常用策略，但它不是强一致。其实不管哪种方案，都避免不了Redis存在脏数据的问题，只能【减轻】这个问题，要想彻底解决，得要用到【同步锁】和对应的业务逻辑层面解决。

流程上：先删除redis，再更新数据库，延迟N秒后再删除一次redis

延迟双删问题：

采用延时删最后一次缓存，但这其中难免还是会大量的查询到旧缓存数据的。这时候可以通过加锁来解决，一次性不让太多的线程都来执行DB查询，避免拿到过多的旧数据。

小结
延迟双删用比较简洁的方式实现 mysql 和 redis 数据【最终一致性】，但它不是【强一致】。

延迟：是因为 mysql 和 redis 主从节点数据同步不是实时的，所以需要等待一段时间，去增强它们的数据一致性。
mysql 和 redis 数据一致性是一个复杂的课题，通常是多种策略同时使用。
例如：延迟双删、redis 过期淘汰、通过路由策略串行处理同类型数据、分布式锁等等。

更细的介绍 跳转