分布式缓存

在前面的blog中提到过，分布式缓存系统是大型分布式系统的基础设施之一。

常用的分布式缓存主要有Memcache和Redis。尤其是Redis，是一些大厂的主流分布式缓存选择。主要原因有两个，一是Redis支持多种数据存储类型，二是Redis支持数据持久化。

缓存主要在读多写少的情况下使用。在使用缓存的时候需要注意一些问题，如数据不一致，缓存击穿等。下面将对这些问题进行介绍。

缓存穿透、缓存击穿、缓存雪崩

缓存击穿，既然能击穿，说明是有缓存的，只是在某个时间点没有从缓存中获取到数据，例如缓存过期，此时需要到数据库中查询。如果并发量很小，那没什么问题。而如果并发量很大的情况下，例如对“热点”数据的查询，大量的请求同时涌入到数据库，会给数据库带来巨大的压力，甚至引起性能问题。

缓存穿透，就要查询的数据是不存在的，这样每次查询均需要走到数据库中，并且返回空。如果被人利用，很可能会对数据库造成影响。

缓存雪崩，就是批量的缓存穿透。缓存穿透是因为个别key缓存失效导致的，而当大量的key设置了相同的过期时间时，会导致缓存在同一时刻全部失效，从而瞬时DB请求量巨大、压力骤增，引起雪崩。

解决方法

缓存穿透
缓存穿透有两种解决办法，一种是布隆过滤器，一种是对不存在的值也设置一个特殊的缓存如null，并将过期时间设短一点。

缓存击穿
对于缓存击穿问题，也有多种解决办法。

一种是通过定时任务定期地刷新缓存，即每次判断key当前的过期时间，发现快要过期了就重新设置过期时间。但这种方法只针对key较少的情况下可以使用，如果有较多的缓存key就不太合适了。

还有一种方法是通过互斥锁来实现。当有多个线程准备进入数据库获取数据时，让第一个线程加上互斥锁，只允许第一个线程进入数据库查询，获得结果后将数据设置到缓存中。其他的线程在互斥锁处等待几十或者几百毫秒，直到缓存中有了数据为止。代码示例如下：

public static String getData(String key) throws InterruptedException {
    // 从缓存中读取数据
    String result = getDataFormRedis(key);
    if (result == null) {
        // 加锁，从数据库中取数据
        if (distributionLock.tryLock(lockKey, uniqueId, expireTime)) {
            result = getDataFromDB(key);
            if (result != null) {
                setDataToCache(key, result);
            }
            distributionLock.releaseLock(lockKey, uniqueId);
        } else {
            // 获取锁失败, 暂停100ms之后重新获取数据
            Thread.sleep(100);
            result = getData(key);
        }
    }
    return result;
}

缓存雪崩
对于缓存雪崩问题，设置缓存数据的过期时间时可以在基础值上加上随机数，防止同一时间大量数据过期现象发生。

缓存与数据库数据不一致

缓存是为了缓解高并发下的数据库压力，使用缓存必然会带来数据的不一致问题。

正常使用缓存的过程如下：(1)查询缓存数据是否存在；(2)不存在则查询数据库；(3)将从数据库中查询到的数据设置到缓存中并返回查询结果；(4)下一次访问时直接从缓存中取数据，没有则重复以上步骤。

那么更新数据库时，该如何更新缓存呢？

更新缓存还是淘汰缓存

缓存更新有两种方式，一种是set，一种是直接delete。

直接淘汰缓存比较方便，但是如果是热点数据的缓存，可能会带来缓存击穿问题。

更新缓存则会相对复杂一些，如果是简单的String类型还好，如果缓存的是一个复杂对象或文本，现在需要修改其中的部分属性，修改缓存需要先获取到完整对象，然后修改属性值，将对象序列化并set到缓存中。整个过程中修改缓存值的成本较高，不如直接做delete操作。

修改缓存和淘汰缓存的主要区别就是一次cache miss的区别，对于非热点数据的缓存更新，建议使用缓存淘汰即可。

先更新数据库还是先更新缓存

先写数据库再淘汰缓存的问题是，数据库更新成功而缓存淘汰失败时，缓存中的数据就一直是脏数据了。

先淘汰缓存再写数据库的问题是，如果在淘汰缓存和写数据库中间有其他的读请求，则会读取到数据库更新之前的数据并设置到缓存中，随后数据库被更新，而缓存中的数据仍然是旧数据。

此时可以使用双淘汰法，即在写数据库之前和之后都淘汰缓存。

数据库主从架构带来的延迟

进一步思考，如果数据库是主从架构，主库写入之后同步到从库中需要一定的时间，此时双淘汰法的后一次淘汰则需要考虑这个延迟时间。如果直接在写入数据库成功之后淘汰缓存，而此时主从同步还没有完成，读请求读到的数据仍然是旧数据，这个旧数据被设置到缓存中就达不到双淘汰的目的。

可以在后一次淘汰缓存时考虑上主从同步的延迟时间，如休眠500毫秒之后再淘汰。

选择性读主库

双淘汰法可以解决数据库与缓存不一致的问题，但由于主从同步的延迟，在这个延迟时间内，如果有读请求进入数据库，读到的数据仍然不是最新数据。当然，在大多数业务场景下，这个微小的延迟是可以接受的。

如果一定要求强一致性，可以考虑选择性读主库。

具体来说，就是当发生写操作时，对操作的记录设置一个缓存，用于标识对这个记录进行了操作（可以用db:table:PK这样的key来标识），过期时间设为主从同步的延时时间，如500ms。当读请求进来时，先在cache中查询标识key，如果存在，说明短时间内有写操作，而此时主从同步还没有完成，从库数据不是最新的，应该去主库查询。不存在key就去从库查询。