MySQL与Redis的缓存一致性问题

前言

在学习中，为了提高数据的读取效率，我们往往会使用Redis来作为MySQL数据的缓存，那么，自然就产生了二者间数据的一致性问题。

想要对MySQL和Redis进行数据处理，自然会产生以下问题：

MySQL与Redis操作的时序问题
- 更新与删除的选择及时序问题

下面我们来一一分析：

先操作MySQL

先删除MySQL中数据

这种情况下，当我们选择先将MySQL中的数据删除时，如果后续写入新数据失败，新数据就很有可能会丢失，我们就完全失去了这条数据，这是难以接受的。所以我们还是来看看先更新MySQL的情况吧：

先更新MySQL中数据

这种情况下，当客户端修改一个数据时，我们先将MySQL中数据更新为最新状态，然后再操作Redis（如果第一步更新MySQL数据失败，就不会继续操作Redis了，此时MySQL和Redis中的数据都还是老数据，也是处于一致状态，可以接受）：

再更新Redis中数据

试想这样一种情况：

线程A和线程B按以下顺序执行：

线程A缓存未命中，然后从MySQL中读到数据c=1
线程B想将数据c=1修改为c=2
线程B先更新MySQL成功，再更新Redis数据c=2（不论更新Redis成功与否）
线程A写回Redis数据c=1

可以看到，此时MySQL中是新数据c=2，Redis中却是老数据c=1，处于不一致状态。在Redis中该数据自动过期，或者再次更新该数据之前，客户端都会读到Redis中的老数据（脏数据）。

不过读操作，往往比写操作更快速，也就是说大多数情况下，线程A等线程B操作完了再写回Redis的情况不会出现。

但是，对于并发更新的情况，可能会出现多个线程并发更新Redis数据，导致老数据覆盖新数据的情况，也会造成不一致状态。

再删除Redis中数据

与上面“再更新Redis中数据”的情况类似，可能会出现线程B删除完Redis数据后，线程A又写回老数据的情况。

但是，对于并发更新的情况，就算多个线程并发删除Redis数据，也能够保证删除老数据，不会造成不一致状态。

当然，如果删除Redis失败了，Redis中还是会留下老数据，造成不一致状态。

先操作Redis

先删除Redis中数据

再更新MySQL中数据

试想这样一种情况：

线程A和线程B按以下顺序执行：

线程B想将数据c=1修改为c=2
线程B先删除Redis中数据成功
线程A缓存未命中，然后从MySQL中读到数据c=1
线程B更新MySQL中数据c=2
线程A写回Redis数据c=1

此外，对于并发更新的情况，可能会出现多个线程并发更新MySQL数据，导致老数据覆盖新数据的情况，也会造成不一致状态。

再删除MySQL中数据

这种情况下，当我们选择将MySQL中的数据删除时，如果后续Redis中的新数据丢失（磁盘存储相对内存存储的可靠性更高），我们就完全失去了这条数据，这是难以接受的。

总结

Cache-Aside (旁路缓存)

综上所述，我们往往会选择 先更新MySQL中数据-再删除Redis中数据 的方案。

以上所述所有的方案，有一个统称：Cache-Aside (旁路缓存)。

直读与同步/异步直写

此外，如果我们将缓存的业务直接从其它业务代码中抽取出来，给其它业务提供一个缓存抽象层，将缓存的操作全部放在这个缓存抽象层中独立存在，也就是缓存的解耦。

这样，主体业务就只需要与抽出来的缓存层进行交互，无需再关心数据的一致性，直接读/写缓存层，也就是直读与直写。

直读（Write-Through）

客户端（也可以是其他业务层）直接读取Redis缓存，如果缓存未命中，从MySQL中读取数据后，再写回Redis，然后再返回给客户端。

直写（Write-Through）

客户端（也可以是其他业务层）直接先更新Redis缓存，然后再更新MySQL，然后再返回数据给客户端。

上面的是同步直写，如果在更新MySQL的同时，异步将数据返回给客户端，那么就叫异步直写（Write-Behind）。

canal

此外，为了提高系统的可用性，我们可以配合一些成熟的中间件，例如：

使用Canal监控MySQL的binlog日志，自动通知缓存业务MySQL中的数据进行了什么修改，可以让我们的系统迅速知道MySQL的数据改动，延迟极低。

在缓存业务中，我们往往还可以引入消息队列，提高数据传输的可靠性，例如：

当Canal监控到MysQL数据改动后，将监控数据发送到RabbitMQ，由订阅了相关Topic的缓存业务消费监控数据并进行处理，可以有效避免数据传输中失败、丢失等问题。