redis缓存一致性

redis是目前使用最广泛的分布式缓存系统，几乎每家公司都在用。它使用简单，吞吐量高，单机 qps 可以达到 10 万每秒，但在使用redis缓存时存在一个问题，即如何保证缓存数据和数据库中数据的一致性。本文就一致性问题提出常用的解决方案。

一致性问题

读取流程

首先，读缓存；

如果缓存里没有值，那就读取数据库的值；

同时把这个值写进缓存中。

双更模式

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

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 的操作，并不是原子的，它们的执行时长也不是可控制的。当两个请求的时序发生了错乱，就会发生缓存不一致的情况。

双更模式下，数据不一致的概率较大，一般不建议使用双更模式。

删除模式

删除模式即更新数据时，删除缓存，查询时重新从数据库中加载数据。先删除缓存还是后删除缓存？

先删除缓存

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

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

后删除缓存（Cache-Aside Pattern)

后删除缓存不会出现上述问题。一般情况下这种方式可以解决大部分问题，也是最常用的解决方案。

但是在高并发的情况下，仍有可能出现不一致的情况。场景如下：

public void proccess(key, value){
    N:putToDB(key, 1);
    N:deleteFromRedis(key);
    // A B线程同时操作同一组数据
    A:getFromRedis(key);
    A:getFromDB(key)=1;

    B:putToDB(key, 2);
    B:deleteFromRedis(key);
    // 特殊情况下导致A更新redis慢于B，在B删除redis之后A才完成更新
    A:putToRedis(key, 1);
    
    //DB=2,Redis=1
}

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

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

一个是读操作，读到的当然是数据库的旧值 1，我们记作操作 A；
同时，另外一个请求发起了更新操作，把数据库记录更新为 2，我们记作操作 B。

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

一种是这个读取操作 A，发生在更新操作 B 的尾部；
一种是操作 A 的这个 Redis 的操作时长，耗费了非常多的时间。比如，这个节点正好发生了 STW。（条件比较苛刻）

那么很容易地，读操作 A 的结束时间就超过了操作 B 删除的动作。

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

此种场景下如何解决？

延迟双删

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

public void putValue(key, value){
    putToDB(key, value);
    deleteFromRedis(key);
    // 5秒之后再次进行删除
    deleteFromRedisDelay(key, 5second);
}

延迟删除动作也有多种实现方式：

如果放在DelayQueue中，会有随着 JVM 进程的死亡，丢失更新的风险；
如果放在 MQ 中，会增加编码的复杂性。

实现方案要根据实际情况进行选择，没有完美的方案，只要能满足业务需求即可。

设置较小的缓存时间

俗称闪电缓存，即把缓存的失效时间设置非常短，比如 5秒。一旦失效，就会再次去数据库读取最新数据到缓存，即数据不一致只会在短时间内不一致。但这种方式，在非常高的并发下，同一时间对某个 key 的请求击穿到 DB，产生缓存击穿问题。

缓存击穿

缓存击穿，指的是缓存中没有数据但数据库中有，由于同一时刻请求量特别大，但是没有读到缓存数据，就会一股脑涌入到数据库中读取，导致数据库因压力过大不可用。

解决方案：

读操作互斥，使用锁或者分布式锁来控制；
更新集中，采用定时或者 binlog 的方式同步更新。

getValue(key){
    res = getFromRedis(key);
    // 未命中
    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;
}