三.缓存双写一致性策略

三.缓存双写一致性策略（本文学习尚硅谷redis后整理得来）

问题，上面业务逻辑你用java代码如何写？

面试：

你只要用缓存,就可能会涉及到redis缓存与数据库双存储双写, 你只要是双写,就一定会有数据一致性的问题, 那么你如何解决一致性问题?

双写一致性,你先动缓存redis还是数据库mysql哪一个?why?

延时双删你做过吗?会有哪些问题?

有这么一种情况,微服务查询redis无mysql有,为保证数据双写一致性回写redis你需要注意什么? 双检加锁策略你了解过吗?如何尽量避免缓存击穿?

redis和mysql双写100%会出纰漏,做不到强一致性,你如何保证最终一致性?

如果redis中有数据

需要和数据库中的值相同

如果redis中无数据

数据库中的值要是最新值,且准备回写redis

缓存按照操作来分,细分2种

1.只读缓存

2.读写缓存

同步直写策略

写数据库后也同步写redis缓存,缓存和数据库中的数据一致;

对于读写缓存来说,要想保证缓存和数据库中的数据一致,就要采用同步直写策略

异步缓写策略

正常业务运行中,mysql数据变动了,但是可以在业务上容许出现一定时间后才作用于redis,比如仓库、物流系统

异常情况出现了,不得不将失败的动作重新修补,有可能需要借助kafka或者RabbitMQ等消息中间件,实现重试重写

双检加锁策略

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

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

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

  /**
     * 加强补充，避免突然key失效了，打爆mysql，做一下预防，尽量不出现击穿的情况。
     * @param id
     * @return
     */
    public User findUserById2(Integer id)
    {
        User user = null;
        String key = CACHE_KEY_USER+id;
​
        //1 先从redis里面查询，如果有直接返回结果，如果没有再去查询mysql，
        // 第1次查询redis，加锁前
        user = (User) redisTemplate.opsForValue().get(key);
        if(user == null) {
            //2 大厂用，对于高QPS的优化，进来就先加锁，保证一个请求操作，让外面的redis等待一下，避免击穿mysql
            synchronized (UserService.class){
                //第2次查询redis，加锁后
                user = (User) redisTemplate.opsForValue().get(key);
                //3 二次查redis还是null，可以去查mysql了(mysql默认有数据)
                if (user == null) {
                    //4 查询mysql拿数据(mysql默认有数据)
                    user = userMapper.selectByPrimaryKey(id);
                    if (user == null) {
                        return null;
                    }else{
                        //5 mysql里面有数据的，需要回写redis，完成数据一致性的同步工作
                        redisTemplate.opsForValue().setIfAbsent(key,user,7L,TimeUnit.DAYS);
                    }
                }
            }
        }
        return user;
    }

主要目的保证redis'和mysql数据一致性

给缓存设置过期时间，定期清理缓存并回写，是保证最终一致性的解决方案。

我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，达到一致性，切记，要以mysql的数据库写入库为准。

上述方案和后续落地案例是调研后的主流+成熟的做法，但是考虑到各个公司业务系统的差距，

不是100%绝对正确，不保证绝对适配全部情况，请同学们自行酌情选择打法，合适自己的最好。

策略	高并发多线程条件下	问题	现象	解决方案
先删除redis缓存，再更新mysql	无	缓存删除成功但数据库更新失败	Java程序从数据库中读到旧值	再次更新数据库，重试
	有	缓存删除成功但数据库更新中......有并发读请求	并发请求从数据库读到旧值并回写到redis，导致后续都是从redis读取到旧值	延迟双删
先更新mysql，再删除redis缓存	无	数据库更新成功，但缓存删除失败	Java程序从redis中读到旧值	再次删除缓存，重试
	有	数据库更新成功但缓存删除中......有并发读请求	并发请求从缓存读到旧值	等待redis删除完成，这段时间有数据不一致，短暂存在。

在大多数业务场景下，

个人建议是(仅代表我个人，不权威)，优先使用先更新数据库，再删除缓存的方案(先更库→后删存)。理由如下：

1 先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力导致打满mysql。

2 如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。

多补充一句：如果使用先更新数据库，再删除缓存的方案

如果业务层要求必须读取一致性的数据，那么我们就需要在更新数据库时，先在Redis缓存客户端暂停并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性，这是理论可以达到的效果，但实际，不推荐，因为真实生产环境中，分布式下很难做到实时一致性，一般都是最终一致性，请大家参考。