专注,勤学,慎思。戒骄戒躁,谦虚谨慎

just do it

导航

统计

Redis中几个简单的概念:缓存穿透/击穿/雪崩,别再被吓唬了

 

Redis中几个“看似”高大上的概念,经常有人提到,某些好事者喜欢死扣概念,实战没多少,嘴巴里冒出来的全是高大上的名词,个人一向鄙视概念党,呵呵!

其实这几个概念:缓存穿透/缓存击穿/缓存雪崩,有一个共通的相似之处,就是高并发下,某些原因导致缓存层失去了保护,导致后端的持久化层(数据库)承担较大压力的情形。
需要注意的是,这些问题发生的前提,需要有足够大的并发性,如果本身并发性不高,那些即便出现了这些个问题,也不会造成非常大的影响。
甚至极端地讲,只要代码的健壮性足够,即便是缓存层全部宕机,也不会导致整个应用程序的崩溃,只不过是所有的请求都指向后端的持久化数据库层罢了。
试问,排出一些低级的问题包括方案,君见过多少请求压垮数据库的场景,或者数据缓存流行之前应用程序就应付不了高并发?
使用缓存,更多的进一步改善性能或者并发,而不是因为数据库被压垮了才使用缓存。

缓存穿透
缓存穿透本质上是查询一个缓存和数据库中都不存在的key值,Redis的缓存层无法命中,导致请求再次指向执行数据库层的情况。
由于是查询到值不存在(当然也不存在与Redis缓存中),导致请求总是“穿透”Redis发往数据库层,因此缓存层失去了“保护”关系数据库层的意义。
解决方案:
布隆过滤器是一个比较好的选择,参考:https://www.cnblogs.com/wy123/p/11571215.html

缓存击穿
强调对于某些热点key,缓存穿透本质上是高并发地请求一个缓存中不存在,但是数据库中存在的key值,导致并发请求指向数据库,导致数据库端承担大量的请求压力的情况,本质上跟缓存穿透一样。
主要侧重的是并发&&“热点”Key不存在与缓存中,导致请求指向数据库层。
解决方案:
这种场景可以从代码逻辑层面优化,从缓存中查询不到数据,再次将请求转向数据库中的时候,锁定该key,获取到该key之后,将该key写入缓存,伪代码如下

value = get_value_from_redis(key1)
if not value:
    if exclusiveness_lock(key1):#成功排他性锁定目标,请求指向数据库
        value = get_value_from_mysql(key1)
      if value:
          write_key_to_redis(key1,value)
    else:#无法获取排他性锁,间隔0.1s之后再次查询缓存
        time.sleep(0.1)
        # 再次从缓存中查询
        get_value_from_redis(key1)       

缓存雪崩
某些原因,比如:
1,Redis实例(主从,集群,哨兵等等)故障。
2,Redis中的key由于过期时间已到,自动过期。
3,由于Redis内存策略导致(maxmemory,maxmemory-policy配置)某些key失效(过期,被清理出缓存等)。
如果此时出现高并发的请求出现,这些请求会全部指向数据库层,缓存层失去了对数据库层的保护,导致数据库承担绝大压力的情况。
解决方案:
1,Redis层的高可用,保证缓存层可以有效地保护数据库层
2,从Redis配置(内存管理策略maxmemory,maxmemory-policy)以及结合业务,避免某些潜在的热点key值过期
3,应用程序端限流,或者通过队列的方式等削峰的方式来保护后端数据库

 

posted on 2019-12-12 10:17  MSSQL123  阅读(...)  评论(...编辑  收藏