Skip to content

Latest commit

 

History

History
44 lines (23 loc) · 2.04 KB

5322c71dcf4f89e769c39bb328e3fe17.md

File metadata and controls

44 lines (23 loc) · 2.04 KB

缓存雪崩,缓存穿透和缓存击穿方案分析

在互联网的高并发,大流量场景下,系统往往承担着巨大的压力,首先选择的方案是增加缓存。缓存使用不当则会产生雪崩,穿透,击穿等问题。

缓存雪崩

在高并发场景下,大量缓存key在同一时间失效,导致大量请求直接落在数据库上,数据库压力过大以致宕机。

解决方案

  • 随机设置key的失效时间,避免大量key集体失效。
setRedis(Key,value,time + Math.random() * 10000);
  • 不设置过期时间,通过定时任务在缓存失效前刷新缓存。

缓存穿透

缓存和数据库中没有相关数据(比如用户携带id <= 0的参数不断发起请求),缓存中没有这样的数据,无法进行拦截,直接被穿透到数据库,导致数据库压力过大宕机。

解决方案

  • 对不存在的数据缓存到redis中,设置key,value值为null,并设置一个短期过期时间段,避免过期时间过长影响用户使用。

  • 布隆过滤器 将所有可能存在的数据哈希到一个足够大的bitmap(位图)中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。

缓存击穿

某一个热点key,在不停地扛着高并发,当这个热点key在失效的一瞬间,持续的高并发访问就击破缓存直接访问数据库,导致数据库宕机。

解决方案

  • 设置热点数据"永不过期"

  • 加上互斥锁:上面的现象是多个线程同时去查询数据库的这条数据,那么我们可以在第一个查询数据的请求上使用一个互斥锁来锁住它

其他的线程走到这一步拿不到锁就等着,等第一个线程查询到了数据,然后将数据放到redis缓存起来。后面的线程进来发现已经有缓存了,就直接走缓存。

区别

雪崩是大面积的key缓存失效;穿透是redis里不存在这个缓存key;击穿是redis某一个热点key突然失效,最终的受害者都是数据库。