针对于缓存雪崩，谈一下个人的几点看法，之前某美国老奶访台湾的时候某大厂就出现过缓存雪崩的问题。 现在业内主流的做法是 一致性hash + rehash，也就是说出现缓存雪崩分为两种情况： 情况一：缓存不支持rehash导致的服务雪崩。
情况二：缓存支持rehash导致的服务雪崩，大部分跟流量洪峰有关系，流量洪峰到达从而引发部分缓存节点过载，然后因为rehash扩散到其它节点上，最终导致整个缓存系统崩溃。
针对于缓存雪崩实际上并没有什么很好的解决方案，只能在架构层面进行预防，除了限流策略意外，其余两种方案不管是给不同的Key的TTL添加随机值，还是利用Redis集群提高服务的可用性。都还是针对于缓存层，不能很好的预防缓存雪崩的问题。 如何防止？ ---> 方案一+方案二+方案三相互配合使用
方案一：对业务 DB 的访问增加读写开关，当发现DB请求变慢、阻塞、慢查询超过阙值，关闭读开关，部分或所有读DB的请求进行快速失败。立刻返回，等DB恢复之后再打开读开关。
方案二：对缓存增加多个副本，缓存未命中则读取副本，并且需异地多活。 方案三：缓存监控，服务降级限流等策略..... 监控+预防
标签：方案,缓存,rehash,DB,面试,限流,雪崩 From： https://blog.csdn.net/2201_75977417/article/details/144476642