Redis 和 MySQL 数据一致性问题

在高并发的场景下，大量的请求直接访问 Mysql 很容易造成性能问题。所以，我们都会用 Redis 来做数据的缓存，削减对数据库的请求。但是，Mysql 和 Redis 是两种不同的数据库，如何保证不同数据库之间数据的一致性就非常关键了。

1、导致数据不一致的原因

1、在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。
2、所以，就需要使用redis做一个缓冲操作，让请求先访问到 redis，而不是直接访问 MySQL 等数据库。
3、读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库

(MySQL)间的数据一致性问题。
4、这个业务场景，主要是解决读数据从 Redis 缓存，一般都是按照下图的流程来进行业务操作。

1.1、缓存先后删除问题

不管是先写 MySQL 数据库，再删除 Redis 缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。

1.2、先删除缓存

1、如果先删除 Redis 缓存数据，然而还没有来得及写入 MySQL，另一个线程就来读取。
2、这个时候发现缓存为空，则去 Mysql 数据库中读取旧数据写入缓存，此时缓存中为脏数据。
3、然后数据库更新后发现 Redis 和 Mysql 出现了数据不一致的问题。

1.3、后删除缓存

1、如果先写了库，然后再删除缓存，不幸的写库的线程挂了，导致了缓存没有删除
2、这个时候就会直接读取旧缓存，最终也导致了数据不一致情况
3、因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题

2、解决方案

2.1、延时双删策略

2.1.1、基本思路

在写库前后都进行 redis.del(key) 操作，并且设定合理的超时时间。

伪代码如下：

public void write( String key, Object data ){ 
	redis.delKey( key ); 
	db.updateData( data ); 
	Thread.sleep( 500 ); 
	redis.delKey( key );
}

2.1.2、具体步骤

1、先删除缓存
2、再写数据库
3、休眠 xxx 毫秒(根据具体的业务时间来定)
4、再次删除缓存

问题：这个 500 毫秒怎么确定的，具体该休眠多久时间呢？

1、需要评估自己的项目的读数据业务逻辑的耗时。
2、这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
3、当然这种策略还要考虑 redis 和数据库主从同步的耗时。
4、最后的的写数据的休眠时间：则在读数据业务逻辑的耗时基础上，加几百 ms 即可。

比如：休眠 1 秒。

2.1.3、设置缓存过期时间是关键点

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

2.1.4、方案缺点

结合双删策略+缓存超时设置，这样最差的情况就是：

1、在缓存过期时间内发生数据存在不一致
2、同时又增加了写请求的耗时。

2.1.5、问题

为什么要双删呢！

因为第一次删除的是还没更新前的数据，第二次删除则是因为读取的并发性导致的缓存重新写入数据出现的垃圾数据。
如果你们的删缓存失败了，怎么办？那不是还是会出现缓存和数据库不一致的情况么？比如一个写数据请求，然后写入数据库了，删缓存失败了，这会就出现不一致的情况了。

这时候我们就需要一个中间件的无私配合了，那就是使用消息来进行重试机制。
步骤：
1、业务代码去更新数据库
2、数据库的操作进行记录日志。
3、订阅程序提取出所需要的数据以及 key
4、获得该信息尝试删除缓存，发现删除失败的时候，发送消息到消息队列
5、继续重试删除缓存的操作，直到删除缓存成功。
其实这个方法与分布式事务的处理方式，就是保证数据的最终一致性，而在分布式事务中，则称之为这种为最大努力通知。那么最大努力通知又是什么样的流程呢？

1、业务方把通知发送给 MQ
2、接收通知方监听 MQ
3、接收通知方接收消息，业务处理完成回应 ack
4、接收通知方若没有回应 ack 则 MQ 会重复通知，MQ  按照间隔时间从短到长的方式逐步拉大通知间隔，直到达到通知要求的时间上限，比如 24 小时之后不再进行通知。
5、接收通知方可通过消息校对接口来校对消息的一致性

总结：
而为什么叫最大努力通知呢，实际上也很容易理解，他并没有从本质上解决问题，只是把问题数目从100 变成了 10 ，毕竟有些内容第一次没处理，第二次就可能会被处理掉。也就是说降低了这种有问题情况的发生，毕竟保证的都是最终一致性。

2.2、异步更新缓存(基于Mysql binlog 的同步机制)

2.2.1、整体思路

1、涉及到更新的数据操作，利用 Mysql binlog 进行增量订阅消费
2、将消息发送到消息队列
3、通过消息队列消费将增量数据更新到 Redis 上
4、操作情况

读取 Redis 缓存：热数据都在 Redis 上
写 Mysql：增删改都是在 Mysql 进行操作
更新 Redis 数据：Mysql 的数据操作都记录到 binlog，通过消息队列及时更新到 Redis 上

2.2.2、Redis 更新过程

数据操作主要分为两种：

1、一种是全量（将所有数据一次性写入Redis）
2、一种是增量（实时更新）

这里说的是增量,指的是 mysql 的 update、insert、delate 变更数据。

读取 binlog 后分析 ，利用消息队列,推送更新各台的 redis 缓存数据。
1、这样一旦 MySQL 中产生了新的写入、更新、删除等操作，就可以把 binlog 相关的消息推送至 Redis
2、Redis 再根据 binlog 中的记录，对 Redis 进行更新
3、其实这种机制，很类似 MySQL 的主从备份机制，因为 MySQL 的主备也是通过 binlog 来实现的数据一致性
这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ 等来实现推送更新 Redis!

3、总结

在高并发应用场景下，如果是对数据一致性要求高的情况下，要定位好导致数据和缓存不一致的原因。

解决高并发场景下数据一致性的方案有两种，分别是延时双删策略和异步更新缓存两种方案。

也可以采用别的第三方：kafka、rabbitMQ 等来实现推送更新 Redis!