redis 的雪崩、穿透和击穿

本文为 基于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.在过期前更新缓存值；

本文献参考

知乎 redis 的雪崩、穿透和击穿，如何应对？