用户查询优惠券之缓存击穿

1.缓存击穿

缓存击穿指的是某个热点key突然失效，比如说过期了，导致大量请求打到缓存，缓存不存在就去访问数据库，导致数据库压力暴增，甚至崩溃。

2.缓存击穿的解决方法：

缓存预热、缓存永不过期、双重判定锁

2.1缓存预热

指在接收请求前，先将较为热点的缓存从数据库读取到缓存中，这样可以减少数据库的访问压力。如果不进行缓存预热，那么就只能等用户访问缓存，发现缓存没有再去读数据库并回写，这样在高并发场景下可能是致命的。

2.2缓存永不过期

一般而言，高并发的场景实质上是有限的，一般是可以预判的，比如秒杀场景，还有其他的一些活动场景，在可预判的情况下，我们做缓存预热的同时就可以设置缓存不过期，避免缓存过期导致缓存穿透。在活动结束后，再将缓存设为有限存在。

2.3双重判定锁

光做了上述内容还不够，因为高并发情境下，上万个请求发现缓存不存在，此时开始阻塞，等待获取锁并访问数据库进行回写。

但是，第一个线程做了就够了，此时后续的线程就不应该继续访问数据库做回写操作，所以拿到锁后需要回头查看缓存是否已经被回写，如果已经被回写，那么就直接返回。

3.高并发极端情况

有一万个请求同一时间访问触发了缓存击穿，如果用双重判定锁，逻辑是这样的：

1.第一个请求加锁、查询缓存是否存在、查询数据库、放入缓存、解锁，假设我们用了50毫秒；

第二个请求拿到锁查询缓存、解锁用了1毫秒；
那最后一个请求需要等待10049毫秒后才能返回，用户等待时间过长，极端情况下可能会触发应用的内存溢出。

方案1：直接返回

由于每个线程都需要阻塞等待拿到分布式锁，但是实质上只要有第一个线程拿到锁，就能够完成回写，所以后续的线程访问锁，发现无法访问，就说明已经有线程在进行回写，此时直接抛出异常并返回即可。减少了线程等待时常。但是这样对用户并不友好。

方案2：分布式锁分片

上述矛盾实际上是检查缓存和释放锁的时常太长导致的线程等待时间太长，所以我们减少线程等待时常即可，我们将锁分成多个，按照线程对应的全局唯一id hash 后取模分配锁，假设现在分配十把锁，此时每个锁的压力就减少十倍，那么对应线程的等待时常也减少了十倍。

如果使用双重判定锁，那最后一个请求需要等待10049毫秒后才能返回。

而使用分布式锁分片

十把锁，每把锁线程数量大概为1000，此时每把锁的最后一个线程的只需要1049ms即可返回，速度翻了10倍。

这里有一个疑惑，减少线程阻塞有什么用呢？还不如直接返回报错。

实质上缓存的访问速度大概是0.1ms，所以主要矛盾在阻塞等待，只要阻塞等待的时间缩短了，就缓解了整个流程的读取速度。

伪代码如下：

java 复制代码

public String selectTrain(String id， String userId) {
    // 查询缓存不存在，去数据库查询并放入到缓存
    String cacheData = cache.get(id);
    if (StrUtil.isBlank(cacheData)) {
        // 假设设置10把分布式锁，那么就通过唯一标识（这里取用户ID）进行取模获取分片下标
        int idx =  Math.abs(userId.hashCode()) % 10;
        // 为避免大量请求同时访问数据库，通过分布式锁减少数据库访问量
        Lock lock = getLock(id + idx);
        lock.lock();
        try {
            // 获取锁后双重判定
            cacheData = cache.get(id);
            // 理论上只有第一个请求加载数据库是有效的，因为它加载后会把数据放到缓存
            // 后面的请求再请求数据库加载缓存就没有必要了
            if (StrUtil.isBlank(cacheData)) {
                // 获取数据库中存在的数据
                String dbData = trainMapper.selectId(id);
                if (StrUtil.isNotBlank(dbData)) {
                    // 将查询到的数据放入缓存，下次查询就有数据了
                    cahce.set(id, dbData);
                    cacheData = dbData;
                }
            }
        } finally {
            lock.unlock();
        }
    }
  return cacheData;
}

4.热key问题：

热key场景是指在一个并发请求的环境中，其中一个热点的key被高频访问，影响线程的响应速度。

解决方案：

使用key分片，和上面的锁分片类似，不过此次是将缓存分为多块，每块有自己的key，每个线程根据自身全局唯一id hash 后取模，从而被分配到相同缓存的不同分片上，提升了读写缓存的效率。

假设在一个商品秒杀活动场景下，商品ID123正在被秒杀，所有用户访问同一个key：product:123:info，为了减缓高频请求对这一个key的访问，可以将这个热key分片为100个子key，即product:123:info:shard0 ~ product:123:info:shard99，每条子key的内容都是一致的，无论请求访问哪条key的内容，结果都是相同。

这么做的好处是可以分担请求压力。原本1w请求同一件商品，对一条key的压力是巨大的，但是经过分片之后，每个子key同时只需要承载100个请求，压力大大缓解。

热key分片的方案适用于读多写少的场景，但他的缺点也是明显的，需要同时维护多个子key，如果更新就要写所有子key。