在 Redis 的使用中，有四个非常常见并且重要的异常问题：缓存穿透、缓存击穿、缓存雪崩、缓存和数据库（MySQL）双写一致性问题。

如果说前三个是否能遇到可能和你的业务体量有关系，那最后一个一致性问题可以说是无法避免了。假如你做的是电商业务，即使你们的系统没多少客户，缓存中的价格或者库存信息与数据库不一致也会给公司带来无法避免的损失。所以这也是面试中必考的重点问题。

问：你是如何解决 Redis 和 MySQL 双写数据不一致问题的呢？或者是如何保证他们之间的一致性。

问题背景

回答一个问题，首先要明白它是为什么产生的。

如果没有引入 Redis 技术，我们单纯往 MySQl 中写入数据（单实例）会有一致性问题吗？当然不会。

MySQL 的 InnoDB 引擎的事务特性已经保证了这点，我们不做赘述。

因为我们引入Redis后的读取流程是这样的：如果缓存存在，直接读取；如果缓存不存在，直接读取数据库数据，然后更新到缓存中。所以就产生了这样的一致性场景：

1. 缓存中有数据，和 MySQL 中的数据保持一致。
2. 缓存中没有数据，MySQL 存储的是最新数据。

对于第一种情况，我们需要保证 MySQL 和 Redis 数据是一样的；对于第二种情况，我们需要保证数据用适当的方式更新到缓存中。MySQL 和 Redis 之间并没有事务这种强约束去保证以上两点，当任意情况被打破的时候就是数据不一致。

在缓存的使用上又分为读写缓存和读缓存：

• 读写缓存：除了读场景，会直接修改缓存中的数据，它又分为同步直写和异步写回。同步直写会同步直接修改缓存数据和数据库；异步写回会在缓存淘汰时候写回数据库。这种方案出现不一致的概率更高，并且用于大量读写场景，这里不考虑。
• 读缓存：不会直接修改缓存内容。修改数据库时直接作废缓存，缓存中不存在会读取数据库值然后设置到缓存中。这种适合读多写少的场景，我们主要讨论这种方案。

先给出结论：其实从技术上来说，我们几乎无法保证Redis 和数据库的严格一致，所有的方案都是尽可能降低不一致的可能性和不一致时间。

1.先删除缓存再更新数据库

如果先删除缓存，再更新数据库，有可能出现如下情况：

1. 线程 1 删除缓存，准备更新数据库。
2. 线程2开始读取数据，发现缓存没有，就读取数据库中数据。由于读比写快很多，这时候大概率线程1还没有完成更新。
3. 线程2把旧数据更新到 Redis 中，这时候线程1完成数据库更改。数据不一致出现。

既然先删除可能出现这样的问题，那我过一会再删一次不就好了嘛。

2.缓存延时双删

比起上一个方案，我们多加了一次删除，但是这也有缺点。

这个sleep时间怎么确定呢？sleep时间要大于线程2读取并且设置缓存的时间，设置的太小有可能无法在设置后删除；设置的太大又影响系统的吞吐量。

3.先更新数据库再删缓存

能不能第一次不删除，只是第二次删除呢？先更新数据库，再删除缓存。这样线程2就可以在线程1提交数据前一直读取旧数据，只有线程1更新后才会去数据库读新值。它似乎完美的解决了这个问题。

但是有一种极端情况。

1. 线程1更新数据库，但是还没有提交事务。然后删除缓存，等事务提交后才完成数据修改。
2. 但是在事务最终提交和删除缓存这个间隙中，发生了线程二读取缓存发现不存在，并且设置数据库旧值这个过程。
3. 这样在线程1最终提交数据后，又发生了数据库和缓存不一致问题。

但是这个概率多大呢？非常非常小。一个commit操作的间隙显然非常短，只需要一次网络链接的过程。但是依旧存在这种可能。

针对这个问题还可以这么解决：在删除缓存的时候设置一个锁并且加一个很短的过期时间，作为lua脚本原子的去操作。如果有线程发现缓存不存在，就去阻塞等待或者返回查询失败。等数据库事务提交成功后删除锁。当然这种方案会造成吞吐量的降低或者接口短暂不可用。

如果把线程1事务提交的时机提交到删除缓存前呢？

这样流程会看起来简单很多。在线程1数据库修改后，到删除redis前这段短暂的时间内线程2会读取到旧数据，但是终究会被线程1删除。这种方案的不一致时间和成本显然最低。

但是，如果最后一步删除缓存失败怎么办呢？那缓存中永远是旧数据了。

4.消息队列重试删除

无论是第二种还是第三种方案，都有可能出现缓存删除失败的情况，可以在最后删除缓存的时候利用消息队列增加重试机制，保证最终一致。

1. 更新数据库。
2. 删除缓存，并且发送一条MQ消息。
3. 收到MQ，删除成功。否则不断重试。

这种方案有可能会造成业务入侵的问题。但是我觉得还好，你可以将删除逻辑封装一下，将删除和发送MQ写到一起，消费MQ也做成通用的删除功能。

原文链接：https://mp.weixin.qq.com/s/15kRoLovB0WL5cfWaxu51Q