缓存穿透、雪崩、热点击穿问题

一个良好的缓存系统,往往在处理一下几个关键问题上有独到之处:缓存穿透、击穿、雪崩、热点、大Value等

基本位置

缓存穿透

概念

查询肯定不存在的数据,缓存不命中,怼到DB查询。


风险

流量大时,可能导致DB挂掉
黑客利用肉鸡大规模攻击,DB挂掉

思路

BloomFilter拦截

将所有可能存在的Key Hash到一个足够大的bitmap中,不存在的Key会被bitmap拦截,从而避免怼DB。


BloomFilter

  • 有误判率,会将不存在的误判为存在,Guava BloomFilter默认0.03
  • 但对于存在的key,一定不会误判为不存在
  • 则发生误判(不存在的误判为存在),则去查库,这时量已降低很多

很高效管用,但数据量大了也费内存,增加维护成本;除非要解决特定的高并发场景,不建议使用。

// 1亿
    private final static int SIZE = 100000000;
    private static BloomFilter bf =BloomFilter.create(Funnels.integerFunnel(), SIZE);

    @Test
    public void testBloomFilter(){

        for (int i = 0; i < SIZE; i++) {
            bf.put(i);
        }

        long timeStart = System.nanoTime();
        if (bf.mightContain(8888)) {
            System.out.println("hit");
        }
        long timeEnd = System.nanoTime();
        System.out.println(String.format(" time = %f mm" , (timeEnd - timeStart) * 1.0/1000/1000));
    }
// 1千万 1亿级别判断的时间基本没差别
// 但是分配的内存会几乎线性变化
hit
time = 0.138511 mm

缓存空结果+过期(jetcache采用方式)

  • Key查DB返回的数据为空,仍然缓存Key : DefaultValue
  • 设置一个可容忍的过期时间

虽然过期后会重新查库,但很大程度上能降低查库压力,而且实现简单、易维护,jetcache采用的方法。

雪崩

概念

雪崩往往是由于缓存的多Key设置了相同的过期时间,某一时刻缓存多Key同时失效,所有请求全部打到DB,DB瞬时压力过重,导致Halt住或奔溃。

思路

加锁查库(jetcache使用方式)

  • 查Cache,Key Miss,先Lock
  • 获取到锁的线程进行查库,放入Cache,释放锁,唤醒其他线程
  • 其他线程等待,直到被唤醒,再查Cache(Double check)
  • 失败,则重试,或返回一个默认值(推荐)

整流队列

  • 并发流量特别大时
  • 查DB前先通过整流器,可按key的总要程度划分多个优先级队列,重要的获取令牌百分比大
  • 获取到令牌的进入消费线程池队列
  • 多个消费线程读DB
  • 查DB限流
  • 线程数可控
  • 增加开发成本
  • Guava 有RateLimiter限速工具类,实现了令牌桶算法,以一定的频率往桶里扔令牌,线程拿到令牌才能执行。

错开过期时间(RD自定义)

  • 在设置过期值,在基础过期时间上增加一个随机值(如1-5分钟随机)

热点击穿

概念

  • 某些时间点,某些Key会被高并发地访问,形成热点Key
  • 热点Key恰好在这时过期了,大量并发打到DB
  • 或是超高并发单Key(一般是hash到单台机上),打满单机的网卡/cpu

思路

加锁

每个热key的多个请求,只放过1个请求去查DB

预判超时,缓存旧值(Guava Cache的RefreshAfterWrite)

  • 在value内部设置1个超时值t1, t1比实际的超时时间t2小
  • 当读时发现t1已过期,先加锁延长t1并重新设置到cache, 同时通知查库
  • 查库期间Cache返回旧值
  • 有一个线程从数据库加载数据并设置到cache中
  • 此后Cache返回新值

预热(12306验证码)

  • 将热数据先加载到缓存系统
  • 请求直接查询
  • 后台线程异步同步/定时更新
  • ScheduledRefresh(定时刷新 jetcache)
  • 支持很高的并发(一般是OS系统层面限制、网卡带宽限制)
  • 费内存(热点过期时间很长,甚至永不过期)

多级缓存

  • 热点Key放在本地缓存
  • 远程缓存定时从DB更新
  • 远程缓存进行主动推送更新本缓存
  • 应用节点不可以也是热点

热点动态散列(tair热点处理方式)

  • 每个HotZone都存储相同的读热点数据
  • 客户端对热点数据Key的请求会随机到任意一台DataServer的HotZone区域
  • 单点的热点请求就被散列到多个节点乃至整个集群。
  • 采用动态散列技术,在存储服务端实现了热点的再散列
  • 客户端对热点实现了一套单独的逻辑

你可能感兴趣的:(缓存穿透、雪崩、热点击穿问题)