Redis：（三）穿透，击穿，雪崩常用解决方案

1. 缓存击穿

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

解决方案：

1. 若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期
2. 使用互斥锁(mutex key)（若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下）
   即，在过期的时候（拿出来的值为空），不立刻去访问数据库查询数据，而是先使用Redis的 setnx 方法去 set 一个mutex key，当操作返回成功时，再去进行数据库操作并回设缓存值
   SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果
3. 若缓存的数据更新频繁或者缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动的重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

2. 缓存穿透

对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。

黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。

举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

解决方案：

1. 布隆过滤器。将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力
2. 每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。
3. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截

3. 缓存雪崩

大量key同一时间点失效，同时又有大量请求打进来，导致流量直接打在DB上，造成DB不可用。

解决方案：

1. 设置key永不失效（热点数据）
2. 缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
3. 使用多级缓存机制，比如同时使用redsi和memcache缓存，请求->redis->memcache->db