Redis-高并发下缓存失效问题

缓存穿透

指查询一个一定不存在的数据，由于缓存是不命中，将去查询数据库，但是 数据库也无此记录，我们没有将这次查询的null写入缓存，这将导致这个不 存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

风险： 利用不存在的数据进行攻击，数据库瞬时压力增大，最终导致崩溃。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

解决： null结果缓存，并加入短暂过期时间，这样的话，下次有相同的 key 来访问的时候，在缓 存失效之前，都可以直接从缓存中取数据。

缓存雪崩 

缓存雪崩是指在我们设置缓存时key采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决： 原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这 样每一个缓存的过期时间的重复率就会降低，就很难引发集体 失效的事件。

另一种缓存雪崩情况：

对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请 求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据 库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个 故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。

 缓存雪崩的事前事中事后的解决方案如下：

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

用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 Redis。如 果 ehcache 和 Redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 Redis 中。

限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降 级！可以返回一些默认的值，或者友情提示，或者空值。 

好处：

• 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
• 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
• 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷 不出来页面，但是多点几次，就可以刷出来了。

缓存击穿 

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。 如果这个key在大量请求同时进来前正好失效，那么所有对 这个key的数据查询都落到db，我们称为缓存击穿。

解决：

      加锁 大量并发只让一个去查，其他人等待，查到以后释放锁，其他人获取到锁，先查缓存，就会有数据，不用去db。

不同场景下的解决方式可如下：

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