如何保证缓存与数据库双写时的数据一致性

背景

在优化系统性能时，总会用到缓存去提高系统性能，但是同时也会单来一个问题缓存跟数据库很难做到原子操作，就会出现缓存与数据库双写时数据不一致性问题。

解决方案

先更新数据库，后更新缓存

这种方案在并发场景下会有问题，例如A线程先更新完数据库，这个时候线程B进行查询操作，那么线程B就会读到缓存的旧数据。

先更新数据库，后删除缓存

这一种情况也会出现问题，比如更新数据库成功了，但是在删除缓存的阶段出错了没有删除成功，那么此时再读取缓存的时候每次都是错误的数据了。

先更新缓存，后更新数据库

同样在更新完成缓存后，在更新数据库时候出错，这时候其他线程进行读取操作时，就会读到缓存中的数据，但是数据库数据其实并没有更新。

先删除缓存，后更新数据库

在删除缓存的时候，还没有来得及更新数据库，此时有另外一个线程进行读取操作，发现缓存中数据为空，会去数据库中查询，并将查询结果回写进数据库中，这个时候缓存中就会是旧数据库了。

最终一致性

从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。

该方案的缺点：在缓存有效时间内数据有可能存在不一致

延时双删策略

但是上述的保证事务提交完以后再进行删除缓存还有一个问题，就是如果你使用的是 Mysql 的读写分离的架构的话，那么其实主从同步之间也会有时间差。

此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）。

1. 请求 A 更新操作，删除了 Redis。

2. 请求主库进行更新操作，主库与从库进行同步数据的操作。

3. 请 B 查询操作，发现 Redis 中没有数据。

4. 去从库中拿去数据。

5. 此时同步数据还未完成，拿到的数据是旧数据。

此时的解决办法就是如果是对 Redis 进行填充数据的查询数据库操作，那么就强制将其指向主库进行查询。

订阅数据库binlog更新缓存

们知道对 Mysql 数据库更新操作后再 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。