一个良好的缓存系统，往往在处理一下几个关键问题上有独到之处：缓存穿透、击穿、雪崩、热点、大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区域
- 单点的热点请求就被散列到多个节点乃至整个集群。
- 采用动态散列技术，在存储服务端实现了热点的再散列
- 客户端对热点实现了一套单独的逻辑
