缓存穿透、缓存击穿、缓存雪崩
Redis缓存的使用,极大提升了应用程序的性能和效率,特别是数据查询方面。但也带来一些问题。
数据一致性问题:从严格意义上讲,这个问题无解,如果对数据一致性要求很高,就不能使用缓存。
另一些问题:缓存穿透、缓存击穿、缓存雪崩
1. 缓存穿透
用户想要查一个数据,发现redis内存数据库没有,称缓存没有命中。于是,向持久层数据库查询,发现也没有,此次查询失败。
很多用户查询时,缓存都没有命中,都要向持久层要数据,这就给持久层数据库造成很大压力,称为缓存穿透 。
1.1. 解决方案
- 布隆过滤器,在缓存和持久层数据库中间加一层布隆过滤器,用来筛选掉一些不符合的请求(持久层不存在),从而降低持久层存储系统的查询压力。
布隆过滤器是一种数据结构,比较巧妙的概率型数据结构(probabilistic data structure),特点是高效地插入和查询,可以用来告诉你 “某样东西一定不存在或者可能存在”。
参考这里
- 缓存空对象,当持久层存储不命中时,返回一个空对象缓存起来,同时设置一个过期时间,之后再访问这个数据,将会从缓存中获取,保护了后端数据源。
2. 缓存击穿
某一个key非常热点,不停的进行大并发对这个点访问,当这个key失效的瞬间,持续的大并发就会直接访问持久层数据库,相当于大并发击穿了缓存。
1.2. 解决方案
- 设置热点数据永不过期。从缓存层面来看,没有设置过期时间,所以不会出现问题。
- 加互斥锁。使用分布式锁,保证对于每个key 同时只有一个线程查询后端服务,其他线程没有获得分布式锁的权限,因此只能等待。这种方式把高并发的压力转移到了分布式锁,因此对分布式锁的考验很大。
3. 缓存雪崩
在某个时间段,缓存集中过期失效。
3.1. 原因
- 数据集中过期
双11抢东西,0点一些商品集中放入缓存,有效期1小时,1点集中过期,会导致对这些商品的查询全部落到数据库上。
- 缓存服务器某个节点宕机或断网
1. 自然形成的缓存雪崩,一定是在某个时间段集中创建缓存,此时数据库也是可以顶住压力的,无非对数据库产生周期性的压力而已。
2. 缓存服务器节点宕机,对数据库服务器造成的压力是不可预估的,很有可能瞬间把数据库压垮。
3.2. 解决方案
- 限流降级
缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存
- 数据预热
- 正式部署前,先把可能的数据预访问一遍,这样很多数据会提前加载到缓存。
- 在即将发生大并发访问前,手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。
- redis高可用
多备几台redis,其实就是集群搭建(异地多活)。