如何处理redis缓存雪崩的情况

我们先了解什么是缓存雪崩现象，假设A系统每秒需要处理5000个请求，但数据库每秒只能处理 4000 个请求，某一天，缓存机器出现了宕机，挂了，这时候所有的请求一下子全部落在数据库上，数据库肯定扛不住，报警挂掉了，这时候如果没有采取缓存设施，数据库又急着用，重新重启数据库，刚重启完成（有可能没启动完），请求又进来了，数据库立马挂掉。

这就是雪崩事件，是 Redis 缓存中最致命问题之一（有一个是穿透）。大家可以看看下图：

出现雪崩事件后不要急不要慌，我们可以在事故前中后三个方面来思考解决方案：

• 事故前：redis 高可用方案，主从+哨兵，集群方案，避免全盘崩溃；

• 事故中：较少数据库的压力，本地 Ehcache 缓存+限流及降级，避免超过数据库承受压力；

• 事故后：做 Redis 持久化，一旦 Redis 重启，可从磁盘中快速恢复数据。

我们来看看改造后的数据流程，假设用户A发送一个请求，系统先请求本地 Ehcache 是否有数据，如果没有再去 Redis 请求数据，如果没有再去数据库请求数据，获取到数据后同步到 Ehcache 和 redis。

限流组件的作用：可以设置每秒请求数次，有多少通过请求，剩余的未通过的可以走降级处理，返回一些默认的值，或者友情提示等默认操作。具体流程可以看看下图：

这样做的好处是:

• 数据库安全：在限流组件可用的情况下，数据库不会挂掉，限流根据确保了每秒多少请求能通过；

• 部分请求可以被处理：数据库没挂，就意味着至少2/5的请求可以被处理掉；

• 高峰时期部分请求无法处理到，需要用户多次点击，因为只有 2/5 的请求被处理，剩下的请求，用户刷不出来界面，需要多点击几次；

• redis 设置的缓存失效时间不是设置成同一个时间，可根据功能、业务、请求接口灵活设置缓存时间：setRedis（key, value, time+Math.random()*10000）