热点Key的常见解决方案：本地缓存、读写分离、Key拆分、二级缓存架构

热点Key（Hot Key）是指某一时刻被大量并发访问的Key，当单个Redis实例的某个Key的QPS超过其单线程处理能力时，会导致该实例CPU飙升、请求超时甚至雪崩。解决热点Key的核心思路是分散压力和分层缓存。以下是业界最成熟的四种解决方案。

方案一：本地缓存（Client-Side Cache）

在应用服务器内存中缓存热点数据，直接从本地内存读取，完全绕过Redis网络IO。这是延迟最低的方案，但需要解决数据一致性问题。

实现要点

• 缓存容量控制： 使用LRU或LFU淘汰策略，单机本地缓存上限建议不超过JVM堆的10%。
• 过期时间： 设置合理的TTL（如1~5秒），避免长时间数据不一致。
• 主动失效： 通过Redis Pub/Sub或配置中心推送失效消息，应用监听后清除本地缓存。

// 伪代码：本地缓存 + 主动失效
public class LocalCacheManager {
    private final Cache<String, String> cache = Caffeine.newBuilder()
            .maximumSize(10_000)
            .expireAfterWrite(3, TimeUnit.SECONDS)
            .build();

    public String get(String key) {
        String value = cache.getIfPresent(key);
        if (value != null) return value;
        value = redis.get(key);
        if (value != null) cache.put(key, value);
        return value;
    }

    // 监听Redis频道，收到失效消息后清除本地缓存
    public void onInvalidate(String key) {
        cache.invalidate(key);
    }
}

方案二：读写分离 + 副本节点

利用Redis主从架构，将热点Key的读请求分散到多个从节点（Replica），主节点只负责写操作。此方案无需修改应用代码，但需要合理配置连接池。

方案三：Key拆分（Sharding）

将一个热点Key拆分为多个子Key（如 hotkey:0 ~ hotkey:99），将请求分散到不同的Redis槽位或实例上。这是最彻底的分散方案，但需要应用层做聚合或轮询。

拆分策略对比

// 伪代码：随机前缀拆分，读时轮询所有子Key
public class HotKeyShard {
    private static final int SHARD_COUNT = 64;

    public void set(String key, String value) {
        for (int i = 0; i < SHARD_COUNT; i++) {
            redis.set(key + ":" + i, value);
        }
    }

    public String get(String key) {
        int shard = ThreadLocalRandom.current().nextInt(SHARD_COUNT);
        return redis.get(key + ":" + shard);
    }
}

方案四：二级缓存架构（L1 + L2）

将本地缓存（L1）与Redis（L2）组合成多层缓存体系，同时配合热点探测和自动降级。这是大型互联网公司应对极端热点（如秒杀、明星事件）的标准方案。

四种方案选型决策矩阵

组合实战建议

在实际生产环境中，这四种方案通常组合使用而非互斥。推荐的分层策略如下：

1. 第一层： 本地缓存（L1），扛住80%的突发流量，TTL设为1~3秒。
2. 第二层： Redis读写分离（L2），从节点连接池适当放大，承载剩余流量。
3. 第三层： Key拆分，针对已被识别出的热点Key（如QPS > 10万），自动触发拆分逻辑。
4. 兜底： 热点探测模块实时监控Redis节点CPU和慢查询，超过阈值时自动降级到本地缓存或返回默认值。