1. 缓存穿透

   一、缓存穿透
   缓存穿透是指key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。
   例如：一些恶意攻击、爬虫等造成大量空命中（爬取线上商城商品数据，超大循环递增商品的ID）.
   缓存穿透示意图：
   
   解决方案：
   1、布隆过滤器拦截
   将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
   2、简单粗暴的方法（推荐）
   如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
   简单粗暴方法的伪代码：

//伪代码
public object GetProductListNew(){const int cacheTime = 30;const string cacheKey = "product_list";var cacheValue = CacheHelper.Get(cacheKey);if (cacheValue != null)return cacheValue;cacheValue = CacheHelper.Get(cacheKey);if (cacheValue != null){return cacheValue;}else{cacheValue = GetProductListFromDB(); //数据库查询不到，为空。if (cacheValue == null){cacheValue = string.Empty; //如果发现为空，设置个默认值，也缓存起来。                }CacheHelper.Add(cacheKey, cacheValue, cacheTime);return cacheValue;}}

把空结果，也给缓存起来，这样下次同样的请求就可以直接返回空了，即可以避免当查询的值为空时引起的缓存穿透。同时也可以单独设置个缓存区域存储空值，对要查询的key进行预先校验，然后再放行给后面的正常缓存处理逻辑。

二、缓存击穿
系统中存在以下两个情况时会出现这种情况：
1、当前key是一个热点key（例如一个秒杀活动），并发量非常大。
2、重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。

在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

解决方案：
1、添加互斥锁(mutex key)（推荐）
就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。

public String get(key) {String value = redis.get(key);if (value == null) { //代表缓存值过期//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load dbif (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、永不过期

从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。

三、缓存雪崩

由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因不可用（宕机）或者大量缓存由于超时时间相同在同一时间段失效（大批key失效/热点数据失效），大量请求直接到达存储层，存储层压力过大导致系统雪崩。

缓存正常从Redis中获取，示意图如下：

缓存失效瞬间示意图如下：

解决方案：
1、加锁排队
加锁或者队列的方式来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
加锁排队，伪代码如下：

//伪代码
public object GetProductListNew() {int cacheTime = 30;String cacheKey = "product_list";String lockKey = cacheKey;String cacheValue = CacheHelper.get(cacheKey);if (cacheValue != null) {return cacheValue;} else {synchronized(lockKey) {cacheValue = CacheHelper.get(cacheKey);if (cacheValue != null) {return cacheValue;} else {//这里一般是sql查询数据cacheValue = GetProductListFromDB(); CacheHelper.Add(cacheKey, cacheValue, cacheTime);}}return cacheValue;}
}

加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量。假设在高并发下，缓存重建期间key是锁着的，这是过来1000个请求999个都在阻塞的。同样会导致用户等待超时，这是个治标不治本的方法！

注意：加锁排队的解决方式分布式环境的并发问题，有可能还要解决分布式锁的问题；线程还会被阻塞，用户体验很差！因此，在真正的高并发场景下很少使用！

2、失效时间设为随机值
缓存数据的过期时间设置随机，可以在原有的过期时间上加上一个随机值，比如1-3min，防止同一时间大量缓存数据集体失效，导致数据库压力过大。

3、缓存数据增加相应的缓存标记
将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
随机值伪代码：

//伪代码
public object GetProductListNew() {int cacheTime = 30;String cacheKey = "product_list";//缓存标记String cacheSign = cacheKey + "_sign";String sign = CacheHelper.Get(cacheSign);//获取缓存值String cacheValue = CacheHelper.Get(cacheKey);if (sign != null) {return cacheValue; //未过期，直接返回} else {CacheHelper.Add(cacheSign, "1", cacheTime);ThreadPool.QueueUserWorkItem((arg) -> {//这里一般是 sql查询数据cacheValue = GetProductListFromDB(); //日期设缓存时间的2倍，用于脏读CacheHelper.Add(cacheKey, cacheValue, cacheTime * 2);                 });return cacheValue;}
} 

解释说明：

缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓 存；

缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。