高并发下缓存雪崩、穿透、击穿了,你该如何挽救

在今天的互联网里,高并发大数据量大流量已经成为了代言词,那么我们的系统也承受着巨大的压力,首当其冲的解决方案就是redis

那么redis使用不当就会产生雪崩穿透击穿等问题,这也是考验一个程序员技术能力的时刻。

当然面试的时候,这也是高频面试题,几乎大厂都会问到。下面跟着贴心老哥一起来看看这些技术吧。

缓存雪崩

举例

双十一期间,所有用户一打开淘宝就是进入首页,首页的压力非常大,为了提高并发,将网站首页数据都缓存到redis里,所有的redis key失效时间都是3小时

双十一当天大量用户剁手狂欢,这时候3个小时过去了,redis里首页的key缓存全部失效,这时候redis里查询不到数据了,只能去数据库中查询,造成数据库无法响应挂掉

用户进不去首页没法剁手了,马爸爸不开心了,把这个程序员外派到非洲了。

一句话总结

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

解决方案

  • 随机设置key失效时间,避免大量key集体失效。

    setRedis(Key,value,time + Math.random() * 10000);
    
  • 若是集群部署,可将热点数据均匀分布在不同的Redis库中也能够避免key全部失效问题

  • 不设置过期时间

  • 跑定时任务,在缓存失效前刷进新的缓存

缓存穿透

举例

老哥做了一个网站火了,动了别人的蛋糕,于是开始疯狂攻击老哥的网站,由于老哥网络安全方面学艺不精被人钻了空子。

某人用脚本疯狂的给老哥发送请求,查询 id = -1 的数据,redis并没有这样的数据,这时候就穿透redis,直接打到了数据库上。

半夜老哥在睡觉并没有察觉,他疯狂攻击老哥一晚上,结果把数据库搞挂了,然后老哥的网站也挂了。

一句话总结

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

解决方案

  • 对不存在的数据缓存到redis中,设置key,value值为null(不管是数据未null还是系统bug问题),并设置一个短期过期时间段,避免过期时间过长影响正常用户使用。

  • 拉黑该IP地址

  • 对参数进行校验,不合法参数进行拦截

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

缓存击穿

举例

双十一马爸爸突发奇想,想拍卖自己穿了20年的老布鞋,并且附带本人签名,程序员将该鞋的信息存到了redis中,设置了3小时过期。寻思3小时够他们抢了吧,但他低估了马爸爸的魅力。

该商品引起了一千万人关注,这些人不断的竞拍这双鞋,价格越拍越高,马爸爸乐开了花。

竞拍了2小时59分,马上要拍到一个亿了,突然这双鞋在redis里的key数据过期了,导致该key的大量请求,都打到了数据库,直接导致数据库挂掉了,服务无法响应。

竞拍到此结束,鞋没卖出去,马爸爸又不开心了,把这个程序员也外派到非洲了。

一句话总结

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

解决方案

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

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

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

    # 简单的分布式锁实现,之后我们重点会讲分布式锁
    public String get(key) {
      String value = redis.get(key);
      if (value == null) { //代表缓存值过期
        //设置3min的超时,防止del操作失败的时候,下次缓存过期一直不能load db
        String keynx = key.concat(":nx");
        if (redis.setnx(keynx, 1, 3 * 60) == 1) { //代表设置成功
          value = db.get(key);
          redis.set(key, value, expire_secs);
          redis.del(keynx);
        } else {
          //这个时候代表同时候的其他线程已经load db并回设到缓存了,这时候重试获取缓存值即可
          sleep(50);
          get(key); //重试
        }
      } else {
        return value;        
      }
    }
    

最后总结

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

思考

未雨绸缪:将redis、MySQL等搭建成高可用的集群,防止单点。

亡羊补牢:服务中进行限流 + 降级,防止MySQL被打崩溃。

重振旗鼓:Redis 持久化 RDB+AOF,宕机重启,自动从磁盘上加载数据,快速恢复缓存数据。

 
  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值