Redis缓存穿透，缓存击穿，缓存雪崩

# 概念解释
- redis 缓存穿透
key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
- redis 缓存击穿
key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
- redis 缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

## 解决办法

### 1、 缓存穿透
有很多种方法可以有效地解决缓存穿透问题。
最简单的是将查询为空的也进行缓存，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间要比正常的短。
最常见的则是采用布隆过滤器，通过多个哈希函数，去数据哈希到一个足够大的bitmap中，查询时必须多个哈希函数都返回存在才查询数据库。多个哈希函数是为了避免哈希冲突，但是布隆过滤器只能新增，无法删除，选型时要加以考虑
### 2、 缓存击穿
**加锁**
当缓存失效的时候，每个请求都落到数据库肯定会造成压力的，这点不论是redis还是mysql都要考虑到。
最简单是对数据访问服务加锁，无论多少并发请求，反正我请求redis时都是串行的。代价是并发性能降低，因为不同的请求参数实际上也被同样限制成串行了。
更优的解决方案地是对同样的请求参数加锁，不同的请求参数锁不互斥，这就涉及到请求参数加锁。由于每个请求默认不共享栈变量，所以同样的字符串作为key时，实际上字符串实例可能不一致，导致加锁没起到作用，故需要使用String::intern将字符串放入常量池，保证同样的字符串只有一份对象实例。代价是如果你的key不是有限的话，常量池会占用过大。
对常量池占用过大的另一种改进方案，是利用本地缓存保证实例唯一。这个代价是sonar会有一个异味，提示缓存函数调用方如果过多，会可能有死锁或者频繁等待的问题，且不易排查。使用者需要自己注意。
**不加锁**
对于只读业务的时间不敏感的数据可以采用主动缓存的方式，对QPS和并发能力都有一个较大的提高。本地缓存拉取数据，请求只从本地缓存。代价是缓存不一致的风险，需视业务而选
### 3、 缓存雪崩
与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key。
最简单的方案是给缓存时间延长一个短的随机时间，如果缓存1小时的话，追加一个1分钟的随机时间。
更常见的解决方案是加入线程池或有锁队列保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。