Redis ：缓存穿透、缓存击穿、缓存雪崩问题的分析与解决方案

前言

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括 合适的缓存更新策略，更新数据库后要及时更新缓存、缓存失败时增加重试机制，例如MQ模式的消息队列。

另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。本篇文章，将从实际代码操作，来演示这三个问题现象。之所以要这么做，是因为，仅仅看这些问题的学术解释，脑袋里很难有一个很形象的概念，有了实际的代码演示，可以加深对这些问题的理解和认识。

缓存穿透

1.缓存穿透的原理：

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中缓存时访问数据库被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

下面举一个例子：

private String getCarrierNameById(UUID carrierId) throws Exception {
        // 获取缓存key值
        String cacheKey = RedisUtils.getRedisKey(
                RedisUtils.REDIS_PREFIX_MODULE_SHIPHUB_CARRIER,
                this.getClass().getSimpleName(), "carrierId4Name", carrierId.toString());

        // 检查缓存 & 校验locationNum
        String carrierName = "";
        if (redisTemplate.hasKey(cacheKey) &&
                null != redisTemplate.opsForValue().get(cacheKey) &&
                redisTemplate.opsForValue().get(cacheKey) instanceof String) {

            // 封装响应体
            carrierName = (String) redisTemplate.opsForValue().get(cacheKey);
            log.info("StoreWebService response from cache:[carrierName={}", carrierName);
        } else {
            ResponseEntity<ShipCarrierDto> shipCarrierDto = shipCarrierFeign.findById(carrierId);
            if (null != shipCarrierDto.getBody()) {
                carrierName = shipCarrierDto.getBody().getCarrierName();
                redisTemplate.opsForValue().set(cacheKey,cacheKey);
            }
            log.info("StoreWebService response from api:[carrierName={}", carrierName);

        }

        return carrierName;
    }

如果我们每次传入一个不存在的carrierId，那么每次对这个carrierId的查询都会访问一次数据库。

2.缓存穿透的解决方案：

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

private String getCarrierNameById(UUID carrierId) throws Exception {
        // 获取缓存key值
        String cacheKey = RedisUtils.getRedisKey(
                RedisUtils.REDIS_PREFIX_MODULE_SHIPHUB_CARRIER,
                this.getClass().getSimpleName(), "carrierId4Name", carrierId.toString());

        // 检查缓存 & 校验locationNum
        String carrierName = "";
        if (redisTemplate.hasKey(cacheKey) &&
                null != redisTemplate.opsForValue().get(cacheKey) &&
                redisTemplate.opsForValue().get(cacheKey) instanceof String) {

            // 封装响应体
            carrierName = (String) redisTemplate.opsForValue().get(cacheKey);
            log.info("StoreWebService response from cache:[carrierName={}", carrierName);
        } else {
            ResponseEntity<ShipCarrierDto> shipCarrierDto = shipCarrierFeign.findById(carrierId);
            if (null != shipCarrierDto.getBody()) {
                carrierName = shipCarrierDto.getBody().getCarrierName();
            }
            log.info("StoreWebService response from api:[carrierName={}", carrierName);

            // 放入缓存
            redisTemplate.opsForValue().set(cacheKey, carrierName);
            if (carrierName.equals(""))
                redisTemplate.expire(cacheKey, 1, TimeUnit.MINUTES);
            else
                redisTemplate.expire(cacheKey, CACHE_TIMEOUT_MINUTES, TimeUnit.MINUTES);
        }

        return carrierName;
    }

缓存击穿

1.缓存击穿原理

缓存击穿，是指一个key非常热点，在不停的扛着大并发，集中对这一个点进行访问，当这个key在失效的瞬间，这些请求发现缓存过期一般都会从后端DB加载数据并回射到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮，就像在一个屏障上凿开了一个洞。

2.缓存击穿解决方案

2.1 使用互斥锁(mutex key)

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

public String get(key) {
	String value = redis.get(key);
	if (value == null) {
		//代表缓存值过期
		//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
		if (redis.setnx(key_mutex, 1, 3 * 60) == 1) {
			//代表设置成功
			value = db.get(key);
			redis.set(key, value, expire_secs);
			redis.del(key_mutex);
		} else {
			//这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
			sleep(50);
                        //重试
			get(key);
		}
	} else {
		return value;
	}
}

2.2 "提前"使用互斥锁(mutex key)

在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。

当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。

2.3 设置永不过期

这里的“永远不过期”包含两层意思：

(1) 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。

(2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期

从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

String get(final String key) {
	V v = redis.get(key);
	String value = v.getValue();
	long timeout = v.getTimeout();
	if (v.timeout <= System.currentTimeMillis()) {
		// 异步更新后台异常执行  
		threadPool.execute(new Runnable() {
			public void run() {
				String keyMutex = "mutex:" + key;
				if (redis.setnx(keyMutex, "1")) {
					// 3 min timeout to avoid mutex holder crash  
					redis.expire(keyMutex, 3 * 60);
					String dbValue = db.get(key);
					redis.set(key, dbValue);
					redis.delete(keyMutex);
				}
			}
		}
		);
	}
	return value;
}

比较一下上面的三种解决方案，

方案1，2 思路简单，可以保证一致性，但是代码复杂度大大增加，同时存在着死锁和线程阻塞的风险

方案3由于是异步构建缓存，不存在线程阻塞，但是它不保证一致性，同时代码复杂度增加，切占用的内存空间也会增加，因为要为每个value维护一个timeKey。

其实，大多数情况下这种爆款很难对数据库服务器造成压垮性的压力。达到这个级别的公司没有几家的。所以，务实主义的我，对主打商品都是早早的做好了准备，让缓存永不过期。即便某些商品自己发酵成了爆款，也是直接设为永不过期就好了。

缓存雪崩

1.缓存雪崩的原理

缓存雪崩，是指在某一个时间段，缓存集中过期失效，请求全部转发到DB，DB瞬时压力过重雪崩。

产生雪崩的原因之一，比如双十一零点，迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

2.缓存雪崩的解决方案

1. 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。
2. 建立备份缓存，缓存A和缓存B，A设置超时时间，B不设值超时时间，先从A读缓存，A没有读B，并且更新A缓存和B缓存;
3. 设置缓存超时时间的时候加上一个随机的时间长度，比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟，酱紫可从一定程度上避免雪崩问题。
4. 对于不同的key可以设置不同的过期时间，入热门类目的商品缓存时间长一些，冷门类目的商品缓存时间短一些，也能节省缓存服务的资源。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，那么那个时候数据库能顶住压力，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。