【Redis】Redis 热 Key解决方案
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。
好学若饥,谦卑若愚