Redis 热 Key解决方案
一、背景
什么是Redis热Key。
我们知道Redis单机读写理论值是读的速度是110000次/s,写的速度是81000次/s。Reidis 热Key就是指类似微博热门事件、秒杀的商品，短时间大量的请求访问同一个key。
可能导致的问题有：
- 流量集中，达到物理网卡上限。
- 请求过多，缓存分片服务被打垮。
- DB 击穿，引起业务雪崩。
二、解决方法
1、二级缓存
根据业务判断把指定的热Key，在服务本地存储一份。降低Redis压力。
//本地缓存初始化以及构造
private static LoadingCache<String, List<Object>> configCache
= CacheBuilder.newBuilder()
.concurrencyLevel(8) //并发读写的级别，建议设置cpu核数
.expireAfterWrite(10, TimeUnit.SECONDS) //写入数据后多久过期
.initialCapacity(10) //初始化cache的容器大小
.maximumSize(10)//cache的容器最大
.recordStats()
// build方法中可以指定CacheLoader，在缓存不存在时通过CacheLoader的实现自动加载缓存
.build(new CacheLoader<String, List<Object>>() {
@Override
public List<Object> load(String hotKey) throws Exception {
}
});
//本地缓存获取
Object result = configCache.get(key);
使用本地缓存则存在以下问题：
- 需要提前获知热点
- 缓存容量有限
- 不一致性时间增长
- 热点 Key 遗漏
2、对Key拆分
将热key拆分成多份，使其均匀分布在每个Redis-Cluster上，每个服务获取到热Key拆分的Key集合，根据服务的ip或mac地址做hash，之后的值与拆key的数量做取余，获取到Key的后缀。
3、整合解决方法
目前市面上已经有了不少关于hotKey相对完整的应用级解决方案，其中京东在这方面有开源的hotkey工具，原理就是在client端做洞察，然后上报对应hotkey，server端检测到后，将对应hotkey下发到对应服务端做本地缓存，并且这个本地缓存在远程对应的key更新后，会同步更新，已经是目前较为成熟的自动探测热key、分布式一致性缓存解决方案，京东零售热key。
