redis雪崩与穿透及击穿解决方案

什么是redis的雪崩？

对于系统A,假如每天高峰期每秒5000个请求，本来缓存在高峰期可以抗住每秒4000个请求，但是缓存机器意外发生了全面积的失效，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。 这就是缓存的雪崩。

解决方案如下：

事前：redis高可用，主从+哨兵，redis cluster,避免全盘奔溃。
事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉
事后：redis持久化，一旦重启，自动从磁盘上加载数据加速恢复缓存数据。

如下为图解：

什么是缓存的穿透？

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。
如下图：
正常的redis请求
redis穿透异常流程

一般3000个并发请求就能打死大部分数据库了

如何解决？

最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

1）缓存无效 key : 如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：SET -999 UNKNOWN。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。

2）布隆过滤器：布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在与海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，我会先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。总结一下就是下面这张图：

redis击穿

缓存击穿，就是说某个key非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个key在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

不同的场景的解决方案

1. 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。
2. 若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于redis、zookeeper等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余县城则再锁释放后能访问到新缓存。
3. 若缓存的数据更新频繁或者缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存即将过期前主动的重新构建缓存火证延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。