概念就不再赘述了。
参考:https://blog.csdn.net/zx711166/article/details/82469674
缓存穿透
引发原因
在查询一个一定不存在的数据,由于缓存是不命中时被动写入,并且处于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,缓存层失去意义。
当在大流量流入时,可能因为频繁访问存储层导致DB直接宕机,这样会形成被人利用不存在的key频繁攻击应用的漏洞。
解决方案:
1.布隆过滤器(最常用)。将所有可能存在的数据哈希到一个 bigmap 中,一个一定不存在的数据会被该 bigmap 拦截掉,从而避免对底层存储系统造成查询压力。
2.另一种更为简单的方法,如果一个查询返回的数据为空(无论数据为空,或是系统故障),将空结果进行缓存,设置一个最长不超过五分钟的过期时间。(个人感觉这个也太简单粗暴了,不太推荐吧)
缓存雪崩
引发原因
- 设置缓存时采用了相同的过期时间,导致缓存在某时刻同时失效,请求全部转向DB,DB瞬时压力过重雪崩。
- Redis宕机,导致客户端的请求之间流向DB,拖垮DB。
问题一的解决方案
1.在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
2.简单方案就是将缓存失效时间分散开,我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
问题二的解决方案
保持缓存层服务器的高可用。
–监控、集群、哨兵。当一个集群里面有一台服务器有问题,让哨兵踢出去。
依赖隔离组件为后端限流并降级。
比如推荐服务中,如果个性化推荐服务不可用,可以降级为热点数据。
提前演练。
演练 缓存层crash后,应用以及后端的负载情况以及可能出现的问题。 对此做一些预案设定。