文章目录
1. 缓存穿透
在高并发下,查询一个不存在的值时,缓存不会被命中,导致大量请求直接落到数据库上,如活动系统里面查询一个不存在的活动。
解决方案:
布隆过滤器
。首先也是对所有可能查询的参数以hash形式存储,当用户想要查询的时候,使用布隆过滤器发现不在集合中,就直接丢弃,不再对持久层查询。缓存空对象
。当持久层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据将会从缓存中获取,保护了后端数据源。缺点是:占用更多的内存。
2. 缓存雪崩
在高并发下,大量的缓存key在同一时间失效,导致大量的请求落到数据库上,如活动系统里面同时进行着非常多的活动,但是在某个时间点所有的活动缓存全部过期。
解决方案:
- 给缓存的失效时间,加上一个随机值,避免集体失效。
- 两级缓存。我们有两个缓存,缓存A和缓存B。缓存A的失效时间为20分钟,缓存B不设失效时间。自己做缓存预热操作。然后细分以下几个小点
● I 先从缓存A读数据,有则直接返回;
● II A没有数据,直接从B读数据,直接返回,并且异步启动一个更新线程;
● III 更新线程同时更新缓存A和缓存B。
3. 缓存击穿
一个key非常热点,在不停的扛着高并发,高并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的高并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。
解决方案:
- 使用互斥锁(mutex key):同一时刻只有一个client能够获取数据。
- 永不过期:没有设置过期时间就保证不会出现热点key过期问题
4. 缓存并发竞争(并发set)
多个client线程同时set key引起的并发问题
解决方案:
- 分布式锁+时间戳:准备一个分布式锁(Redis自己有实现),并发访问哪个资源,就将该资源作为key,值为一个唯一的随机值(如unix时间戳加上ip之类的),这个key在Redis中存在,表示对此资源上锁了,用完再把这个key删了就行。
- 消息队列:把Redis.set操作放在队列中使其串行化,必须的一个一个执行。这种方式在一些高并发的场景中算是一种通用的解决方案。
5. 如果master还未将AOF同步给slave就挂了,此时failover将此slave提升为新的master,那么如何保证最终一致性?
保证不了,就是丢了。
[1] redis缓存与数据一致性
[2] 缓存穿透、缓存击穿和缓存雪崩实践