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

一个良好的缓存系统，往往在处理一下几个关键问题上有独到之处：缓存穿透、击穿、雪崩、热点、大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<Integer> 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区域

• 单点的热点请求就被散列到多个节点乃至整个集群。

• 采用动态散列技术，在存储服务端实现了热点的再散列

• 客户端对热点实现了一套单独的逻辑

作者：jiangmo
链接：https://www.jianshu.com/p/090c8767ffea