MySQL 数据库和 Redis 缓存一致性的更新策略

一、更新策略

1、如果 Redis 中有数据，需要和数据库中的值相同。

2、如果 Redis 中无数据，数据库中的最新值要对 Redis 进行同步更新。

二、读写缓存

1、同步直写策略

写入数据库也同步写 Redis 缓存，缓存和数据库中的数据一致；对于读写缓存来说，要保证缓存和数据库中的数据一致，就要保证同步直写策略。

2、异步缓写策略

某些业务运行中，MySQL 数据更新之后，允许在一定时间后再进行 Redis 数据同步，比如物流系统。

当出现异常情况时，不得不将失败的动作重新修补，需要借助 rabbitmq 或 kafka 进行重写。

三、双检加锁策略

多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。

其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。

后面的线程进来发现已经有缓存了，就直接走缓存。

public String get(String key){    // 从Redis缓存中读取    String value = redisTemplate.get(key);
    if(value != null){        return value;    }
    synchronized (RedisTest.class){        // 重新尝试从Redis缓存中读取        value = redisTemplate.get(key);        if(value != null){            return value;        }
        // 从MySQL数据库中查询        value = studentDao.get(key);        // 写入Redis缓存        redisTemplate.setnx(key,value,time);        return value;    }}

四、数据库和缓存一致性的更新策略

1、先更新数据库，再更新 Redis

按照常理出牌的话，应该都是如此吧？那么，这种情况下，会有啥问题呢？

如果更新数据库成功后，更新 Redis 之前异常了，会出现什么情况呢？

数据库与 Redis 内缓存数据不一致。

2、先更新缓存，再更新数据库

多线程情况下，会有问题。比如：

1. 线程 1 更新 redis = 200；

2. 线程 2 更新 redis = 100；

3. 线程 2 更新 MySQL = 100；

4. 线程 1 更新 MySQL = 200；

结果呢，Redis=100、MySQL=200；我擦！

3、先删除缓存，再更新数据库

1. 线程 1 删除了 Redis 的缓存数据，然后去更新 MySQL 数据库；

2. 还没等 MySQL 更新完毕，线程 2 杀来，读取缓存数据；

3. 但是，此时 MySQL 数据库还没更新，线程 2 读取了 MySQL 中的旧值，然后线程 2，还会将旧值写入 Redis 作为数据缓存；

4. 线程 1 更新完 MySQL 数据后，发现 Redis 中已经有数据了，之前都删过了，那我就不更新了；

完蛋了。。

延时双删

延时双删可以解决上面的问题，只要 sleep 的时间大于线程 2 读取数据再写入缓存的时间就可以了，也就是线程 1 的二次清缓存操作要在线程 2 写入缓存之后，这样才能保证 Redis 缓存中的数据是最新的。

/** * 延时双删 * @autor 哪吒编程 */public void deleteRedisData(Student stu){    // 删除Redis中的缓存数据    jedis.del(stu);
    // 更新MySQL数据库数据    studentDao.update(stu);
    // 休息两秒    try {        TimeUnit.SECONDS.sleep(2);    } catch (InterruptedException e) {        e.printStackTrace();    }
    // 删除Redis中的缓存数据    jedis.del(stu);}

延迟双删最大的问题就是 sleep，在效率为王的今天，sleep 能不用还是不用为好。

你不睡我都嫌你慢，你还睡上了...

4、先更新数据库，再删除缓存

1. 线程 1 先更新数据库，再删除 Redis 缓存；

2. 线程 2 在线程 1 删除 Redis 缓存之前发起请求，得到了未删除的 Redis 缓存；

3. 线程 1 此时才删除 Redis 缓存数据；

问题还是有，这翻来覆去的，没完没了了。

这种情况如何解决呢？

引入消息中间件解决战斗，再一次详细的复盘一下。

1. 更新数据库；

2. 数据库将操作信息写入 binlog 日志；

3. 订阅程序提取出 key 和数据；

4. 尝试删除缓存操作，发现删除失败；

5. 将这些数据信息发送到消息中间件中；

6. 从消息中间件中获取该数据，重新操作；

5、总结

哪吒推荐使用第四种方式，先更新数据库，再删除缓存。

方式①和方式②缺点太过明显，不考虑；方式③中的 sleep，总是让人头疼；方式④是一个比较全面的方案，但是增加了学习成本、维护成本，因为增加了消息中间件。

五、MySQL 主从复制工作原理

1. 当 master 主服务器上的数据发生改变时，则将其改变写入二进制事件日志文件中；

2. salve 从服务器会在一定时间间隔内对 master 主服务器上的二进制日志进行探测，探测其是否发生过改变。

如果探测到 master 主服务器的二进制事件日志发生了改变，则开始一个 I/O Thread 请求 master 二进制事件日志；

3. 同时 master 主服务器为每个 I/O Thread 启动一个 dump Thread，用于向其发送二进制事件日志；

4. slave 从服务器将接收到的二进制事件日志保存至自己本地的中继日志文件中；

5. salve 从服务器将启动 SQL Thread 从中继日志中读取二进制日志，在本地重放，使得其数据和主服务器保持一致；

6. 最后 I/O Thread 和 SQL Thread 将进入睡眠状态，等待下一次被唤醒；

作者：哪吒编程

链接：https://juejin.cn/post/7219674355491553340

来源：稀土掘金