我们先了解什么是缓存雪崩现象,假设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)