本文为 基于Docker实现Nginx、php、mysql、redis等服务系列文章中 redis 的雪崩、穿透和击穿 文章目录 https://blog.csdn.net/appAndWxy/article/details/113425343
为什么要先写这几种情况呢,因为 redis读写分离、哨兵、集群等可以解决、或者迅速恢复因为雪崩、穿透和击穿引起的系统问题,但更应该防患于未然。
缓存雪崩
对于系统 A,假设每天高峰期每秒 5000 个请求,本来缓存在高峰期可以扛住每秒 4000 个请求,但是缓存机器意外发生了全盘宕机。缓存挂了,此时 1 秒 5000 个请求全部落数据库,数据库必然扛不住,它会报一下警,然后就挂了。此时,如果没有采用什么特别的方案来处理这个故障,DBA 很着急,重启数据库,但是数据库立马又被新的流量给打死了。这就是缓存雪崩。
解决方案: 主从+哨兵,本地 ehcache 缓存 + hystrix 限流&降级,redis 持久化
缓存穿透
对于系统A,假设一秒 5000 个请求,结果其中 4000 个请求是黑客发出的恶意攻击。黑客发出的那 4000 个攻击,缓存中查不到,每次你去数据库里查,也查不到。
缓存中不会有,请求每次都“视缓存于无物”,直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。
解决方案:1.系统 A 从数据库中只要没查到,就写一个空值到缓存里去;
2.设置对ip请求现在,同一ip并发和几秒内请求数量过多直接黑名单;
缓存击穿
某个 key 非常热点,处于集中式高并发访问的情况,当这个 key 在失效的瞬间,大量的请求就击穿了缓存,直接请求数据库
解决方案:1.若缓存的数据是基本不会发生更新的,则可尝试将该热点数据设置为永不过期。
2.在过期前更新缓存值;
本文献参考