【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);

使用本地缓存则存在以下问题：

1. 需要提前获知热点
2. 缓存容量有限
3. 不一致性时间增长
4. 热点 Key 遗漏

2、对Key拆分

将热key拆分成多份，使其均匀分布在每个Redis-Cluster上，每个服务获取到热Key拆分的Key集合，根据服务的ip或mac地址做hash，之后的值与拆key的数量做取余，获取到Key的后缀。

3、整合解决方法

目前市面上已经有了不少关于hotKey相对完整的应用级解决方案，其中京东在这方面有开源的hotkey工具，原理就是在client端做洞察，然后上报对应hotkey，server端检测到后，将对应hotkey下发到对应服务端做本地缓存，并且这个本地缓存在远程对应的key更新后，会同步更新，已经是目前较为成熟的自动探测热key、分布式一致性缓存解决方案，京东零售热key。

参考：
https://juejin.cn/post/7061568468537049124#heading-13