Redis 是现在互联网中使用最广泛的分布式缓存系统，几乎每家公司都在用。它的 qps 可以达到10万每秒，吞吐量还是非常可观的，对于一般体量的互联网公司，一台机器就够了。但不论是什么业务，都不得不面对一个棘手的问题：那就是Redis和源数据的一致性问题。

一、Spring注解使用，控制Redis缓存更新

使用 SpringBoot 可以很容易地对 Redis 进行操作。Java 的 Redis 的客户端常用的有三个：jedis、redisson、lettuce。其中，Spring 默认使用的是 lettuce。 很多人喜欢使用 Spring 抽象的缓存包 spring-cache，它可以使用注解，非常方便。它的注解采用 AOP 的方式，对 Cache 层进行了抽象，可以在各种堆内缓存框架和分布式框架之间进行切换。

我们来看一下它的 maven 坐标：

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-cache</artifactId> 
</dependency>

使用spring-cache有三个步骤：

1. 在启动类上加上@EnableCaching 注解；
2. 使用 CacheManager 初始化要使用的缓存框架，使用 @CacheConfig 注解注入要使用的资源；
3. 使用@Cacheable等注解对资源进行缓存。而针对缓存操作的注解有三个：

@Cacheable 表示如果缓存系统里没有这个数值，就将方法的返回值缓存起来； @CachePut 表示每次执行该方法，都把返回值缓存起来； @CacheEvict 表示执行方法的时候，清除某些缓存值。

二、缓存一致性问题是如何产生的？

在说缓存一致性问题如何产生的前，我们先看下缓存的API操作，缓存操作和数据库的CRUD结合起来，大致可以抽象成以下几个方法：

• getFromDB(key)
• getFromRedis(key)
• putToDB(key,value)
• putToRedis(key,value)
• deleteFromDB(key)
• deleteFromRedis(key)
•  

把Redis当缓存使用，就说明Redis是不合适作为落地存储的。 一般我们是把最终的数据存放在数据库中的，，一般情况下，Redis 的操作速度比数据库的操作速度快得多。毕竟是 10wQPS 和上千 QPS 的对比。

上面这些 API 很简单，但把它们的顺序调整一下，一致性就会出现问题。一致性，简单说就是“数据库里的数据”与“Redis 中的数据”不一样了。 对于读的过程，一般是没什么异议的。

• 首先，读缓存；
• 如果缓存没有值，那就读取数据库的值；
• 同时把这个值写进缓存中；

我们下面主要看一下写模式。

三、双更新模式：操作不合理，导致数据一致性问题

我们来看下常见的一个错误编码方式，这些是代码 review 时要着重看的点，也是常出问题的地方。

public void putValue(key,value){
    putToRedis(key,value);
    putToDB(key,value);//操作失败了
}

比如我们需要更新一个值，首先刷了缓存，然后把数据库也更新了。但更新数据库过程中出现了异常，发生了回滚。所以，最后“缓存里的数据”和“数据库的数据”就不一样了，也就是出现了数据不一致的问题。

那如果先更新数据库，再更新缓存呢？如代码：

public void putValue(key,value){
    putToDB(key,value);
    putToRedis(key,value);
}

这依然会有问题。

考虑到下面的场景：操作 A 更新 a 的值为 1，操作 B 更新 a 的值为 2。由于数据库和 Redis 的操作，并不是原子的，它们的执行时长也不是可控制的。当两个请求的时序发生了错乱，就会发生缓存不一致的情况。

放到实操中来说：A 操作在更新数据库成功后，再更新 Redis；但在更新 Redis 之前，另外一个更新操作 B 执行完毕。那么操作 A 的这个 Redis 更新动作，就和数据库里面的值不一样了。 其实双更新模式的问题，主要不是体现在并发的一致性上，而是业务操作的合理性上。

我们大多数业务代码并没有经过良好的设计。一个缓存的值，可能是多条数据库记录拼凑或计算得出来的。比如一个余额操作，可能是“钱包里的值”加上“基金里的值”计算得出来的。

要是采用“更新”的方式，那这个计算代码就分散在项目的多个地方，这就不合理了。

那么怎么办呢？其实，我们把“缓存更新”改成“删除”就好了。

四、“后删缓存”，能解决多数不一致

因为每次读取时，如果判断 Redis 里没有值，就会重新读取数据库，这个逻辑是没问题的。唯一的问题是：我们是先删除缓存？还是后删除缓存？

答案是后者！

1、如果先删缓存

我们来看一下先删除缓存会有什么问题：

public void putValue(key,value){
    deleteFromRedis(key);
    putToDB(key,value);
}

操作 B 删除了某个 key 的值，这时候有另外一个请求 A 到来，那么它就会击穿到数据库，读取到旧的值。无论操作 B 更新数据库的操作持续多长时间，都会产生不一致的情况。

2、如果后删缓存

而把删除的动作放在后面，就能够保证每次读到的值都是新鲜的，从数据库里面拿到最新的。

public void putValue(key,value){
    putToDB(key,value);
    deleteFromRedis(key);
}

这就是我们通常说的Cache-Aside Pattern，也是我们平常使用最多的模式。我们看一下它的具体方式。 先看一下数据的读取过程，规则是“先读 cache，再读 db”，详细步骤如下：

1. 每次读取数据，都从 cache 里读；
2. 如果读到了，则直接返回，称作 cache hit；
3. 如果读不到 cache 的数据，则从 db 里面捞一份，称作 cache miss；
4. 将读取到的数据塞入到缓存中，下次读取时，就可以直接命中。

再来看一下写请求，规则是“先更新 db，再删除缓存”，详细步骤如下：

1. 将变更写入到数据库中；
2. 删除缓存里对应的数据。

为什么说最常用呢？因为 Spring cache 就是默认实现了这个模式。

五、大厂高并发，“后删缓存”依旧不一致

所以在高并发情况下，Cache Aside Pattern会不够用。下面就描述一个“先更新再删除”这种场景下，依然会产生不一致的情况。场景很好理解、很极端，但在高并发多实例的情况下很常见。

有一系列的高并发操作，一直执行着更新、删除的动作。某个时刻，它更新数据库的值为 1，然后删除了缓存。

public void proccess(key,value){
    N:putToDB(key,1);
    N:deleteFromRedis(key);

    A:getFromRedis(key);
    A:getFromDB(key)=1;
    B:putToDB(key,2);
    B:deleteFromRedis(key);
    A:putToRedis(key,1);

    //DB=2,Redis=1
}

正在这时，有两个请求发生了：

• 一个是读操作，读到的当然是数据库的旧值 1，我们记作操作 A；

• 同时，另外一个请求发起了更新操作，把数据库记录更新为 2，我们记作操作 B。

一般情况下，读取操作都是比写入操作快的，但我们要考虑两种极端情况：

• 一种是这个读取操作 A，发生在更新操作 B 的尾部；

• 一种是操作 A 的这个 Redis 的操作时长，耗费了非常多的时间。比如，这个节点正好发生了 STW。 那么很容易地，读操作 A 的结束时间就超过了操作 B 删除的动作。就像上图虚线部分画的一样，这个时候，数据也是不一致的。

实际上，你也无法控制它们的执行顺序。只要发生这种情况，大概率数据库和 Redis 的值会不一致。

但为什么一般公司不去处理这种情况呢？你仔细看这张图，它发生的条件是非常苛刻的。它要求在一系列“并发写”的同时，还有“并发读”的参与。而一般业务是达不到这个量级的，所以一般公司不去处理这种情况，但高并发业务就非常常见了。

六、如何解决高并发的不一致问题？

大家看上面这种不一致情况发生的场景，归根结底还是“删除操作”发生在“更新操作”之前了。

1、延时双删

而假如有一种机制，能够确保删除动作一定被执行，那就可以解决问题，起码能缩小数据不一致的时间窗口。常用的方法就是延时双删，依然是先更新再删除，唯一不同的是：我们把这个删除动作，在不久之后再执行一次，比如 5 秒之后。

public void putValue(key,value){
    putToDB(key,value);
    deleteFromRedis(key);

    ...deleteFromRedis(key,after5sec);
}

而删除动作也有多种选择：

• 如果放在 DelayQueue 中，会有随着 JVM 进程的死亡，丢失更新的风险；

• 如果放在 MQ 中，会增加编码的复杂性。 所以到了这个时候，并没有一个能够行走天下的解决方案。我们得综合评价很多因素去做设计，比如团队的水平、工期、不一致的忍受程度等。

2、闪电缓存

还有一种不太常用的，那就是采用闪电缓存。就是把缓存的失效时间设置非常短，比如 3～4 秒。一旦失效，就会再次去数据库读取最新数据到缓存。但这种方式，在非常高的并发下，同一时间对某个 key 的请求击穿到 DB，会锁死数据库，所以很少用。

对于一般并发场景，上面的各种修修补补，已经把不一致问题降低到很小的概率了。但是它仍然是有问题的，因为它引入了一个高可用问题：缓存击穿。

七、如何解决缓存击穿？

缓存击穿，指的是缓存中没有数据但数据库中有，由于同一时刻请求量特别大，但是没有读到缓存数据，就会一股脑涌入到数据库中读取，造成数据库假死。

任何删除缓存的动作都会造成缓存击穿。 所以我们上面一直说的是要删除缓存，但在极高并发下，你还不能乱删。 你反过头去看一下，好像我们一开始双更的方案比 Cache-Aside Pattern 还要靠谱一些，起码能用。怎么回事？代码还能不能写了？这就是业务开发中的特事特办，要专门针对这种功能进行编码。场景特殊时，代码也就不要追求极端优雅性了，毕竟也没有万能的解决方案。

这时，盘点一下我们手头上的工具，可以看到有两种不同的解决方式：

• 读操作互斥，使用锁或者分布式锁来控制；

• 更新集中，采用定时或者 binlog 的方式同步更新。

1、读操作互斥

先来看一下锁操作。我们依然采用 Cache-Aside Pattern，只不过在读的时候进行一下处理。来看一下伪代码，从 Redis 读取不到值的时候，我们要上锁去从数据库中读这个值。我们这里默认这个值是有的，否则就得处理缓存穿透的问题。

get(key){
    res = getFromRedis(key);
    //读取缓存为null
    if(null == res){
        lock.lock(...);
        //再次读取缓存为null
        res = getFromRedis(key);
        if(res == null){
            res = getFromDB(key);
            if(null != res){
                //读取设值
                putToRedis(key,res);
            }
        }
        lock.unlock();
    }
    return res;
}
getFromDB(key){
    ...
}

使用分布式锁和非分布式锁的主要区别，还是在于数据一致性窗口上：

• 对于多线程锁来说，可能某些节点执行得非常慢，更新了旧的值到 Redis；

• 对于分布式锁来说，肯定又是一个效率上的话题。

2、集中更新

我们再来看一下集中更新。这个很美好，但大多数业务很复杂，这对业务架构的前期设计要求非常高。比如通过 Binlog 方式，典型的如 Canal。我们不会在代码里做任何 Redis 更新的操作，而是会设计一个服务，订阅最新的 binlog 更新信息，然后解析它们，主动去更新缓存。这个一般在大并发大厂才会采用。

还有一种就是弱化数据库。所有的数据首先在 Redis 落地，也就是把 Redis 作为数据库使用，把数据库作为备份库使用。有定时任务，定期把 Redis 中的数据，保存到数据库或其他地方。

一般，重要业务还要配备一个对账系统，定时去扫描，以便快速发现不一致的情况。