缓存层承载着大量的要求，有效保护了存储层。但是如果由于缓存大量失落效或者缓存整体不能供应做事，导致大量的要求到达存储层，会使存储层负载增加，这便是缓存雪崩的场景。
办理缓存雪崩，可以从以下几个方面入手。
1.保持缓存层的高可用性
利用Redis 哨兵模式或者Redis 集群支配办法，即便个别Redis 节点下线，全体缓存层依然可以利用。除此之外，还可以在多个机房支配 Redis，这样即便是机房去世机，依然可以实现缓存层的高可用。
2.限流降级组件
无论是缓存层还是存储层都会有出错的概率，可以将它们视为资源。作为并发量较大的分布式系统，假如有一个资源不可用，可能会造成所有线程在获取这个资源时非常，造玉成部系统不可用。降级在高并发系统中是非常正常的，比如推举行事中，如果个性化推举行事不可用，可以降级补充热点数据，不至于造玉成部推举行事不可用。常见的限流降级组件如 Hystrix、Sentinel 等。
3.缓存不过期
Redis 中保存的 key 永不失落效，这样就不会涌现大量缓存同时失落效的问题，但是随之而来的便是Redis 须要更多的存储空间。
4.优化缓存过期韶光
设计缓存时，为每一个 key 选择得当的过期韶光，避免大量的 key 在同一时候同时失落效，造成缓存雪崩。
5.利用互斥锁重修缓存
在高并发场景下，为了避免大量的要求同时到达存储层查询数据、重修缓存，可以利用互斥锁掌握，如根据 key 去缓存层查询数据，当缓存层为命中时，对 key 加锁，然后从存储层查询数据，将数据写入缓存层，末了开释锁。若其他线程创造获取锁失落败，则让线程休眠一段韶光后重试。对付锁的类型，如果是在单机环境下可以利用 Java 并发包下的 Lock，如果是在分布式环境下，可以利用分布式锁（Redis 中的 SETNX 方法）。
分布式环境下利用Redis 分布式锁实现缓存重修，优点是设计思路大略，对数据同等性有保障；缺陷是代码繁芜度增加，有可能会造成用户等待。假设在高并发下，缓存重修期间 key 是锁着的，如果当前并发 1000 个要求，个中 999 个都在壅塞，会导致 999 个用户要求壅塞而等待。
6.异步重修缓存
在这种方案下构建缓存采纳异步策略，会从线程池中获取线程来异步构建缓存，从而不会让所有的要求直接到达存储层，该方案中每个Redis key 掩护逻辑超时时间，当逻辑超时时间小于当前韶光时，则解释当前缓存已经失落效，应该进行缓存更新，否则解释当前缓存未失落效，直接返回缓存中的 value 值。如在Redis 中将 key 的过期韶光设置为 60 min，在对应的 value 中设置逻辑过期韶光为 30 min。这样当 key 到了 30 min 的逻辑过期韶光，就可以异步更新这个 key 的缓存，但是在更新缓存的这段韶光内，旧的缓存依然可用。这种异步重修缓存的办法可以有效避免大量的 key 同时失落效。
end：如果你以为本文对你有帮助的话，记得关注点赞转发，你的支持便是我更新动力。（商务互助私信即可）
