二、缓存雪崩(一批过期的key)
缓存雪崩是指在我们设置缓存时采取了相同的过期韶光，导致缓存在某一时候同时失落效，要求全部转发到DB，DB瞬时压力过重雪崩。
办理方案缓存失落效时的雪崩效应对底层系统的冲击非常恐怖。大多数系统设计者考虑用加锁或者行列步队的办法担保缓存的单线程（进程）写，从而避免失落效时大量的并发要求落到底层存储系统上。这里分享一个大略方案就时讲缓存失落效韶光分散开(过期韶光错开)，比如我们可以在原有的失落效韶光根本上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期韶光的重复率就会降落，就很难引发集体失落效的事宜。
对付一些设置了过期韶光的key，如果这些key可能会在某些韶光点被超高并发地访问，是一种非常“热点”的数据。这个时候，须要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的差异在于这里针对某一key缓存，前者则是很多key。
缓存在某个韶光点过期的时候，恰好在这个韶光点对这个Key有大量的并发要求过来，这些要求创造缓存过期一样平常都会从后端DB加载数据并回设到缓存，这个时候大并发的要求可能会瞬间把后端DB压垮。
办理方案1.利用互斥锁(mutex key)业界比较常用的做法，是利用mutex。大略地来说，便是在缓存失落效的时候（判断拿出来的值为空），不是立即去load db，而是先利用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试全体get缓存的方法。
SETNX，是「SET if Not eXists」的缩写，也便是只有不存在的时候才设置，可以利用它来实现锁的效果。在redis2.6.1之前版本未实现setnx的过期韶光，以是这里给出两种版本代码参考：
2. "提前"利用互斥锁(mutex key)：在value内部设置1个超市价(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1创造它已经由期时候，立时延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。伪代码如下：
3. "永久不过期"：这里的“永久不过期”包含两层意思：
(1) 从redis上看，确实没有设置过期韶光，这就担保了，不会涌现热点key过期问题，也便是“物理”不过期。(2) 从功能上看，如果不过期，那不就成静态的了吗？以是我们把过期韶光存在key对应的value里，如果创造要过期了，通过一个后台的异步线程进行缓存的构建，也便是“逻辑”过期
从实战看，这种方法对付性能非常友好，唯一不敷的便是构建缓存时候，别的线程(非构建缓存的线程)可能访问的是老数据，但是对付一样平常的互联网功能来说这个还是可以忍受。
4. 资源保护：采取netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个运用到缓存的构建也未尝不可。
四种办理方案：没有最佳只有最得当
总结针对业务系统，永久都是详细情形详细剖析，没有最好，只有最得当。
末了，对付缓存系统常见的缓存满了和数据丢失问题，须要根据详细业务剖析，常日我们采取LRU策略处理溢出，Redis的RDB和AOF持久化策略来担保一定情形下的数据安全。
作者：玄明Hanko链接：https://juejin.cn/post/6940070054788595743
