4. 热点Key的本地缓存削峰策略：客户端本地缓存原理、Caffeine/Guava Cache集成、一致性保障

4.1 客户端本地缓存削峰原理

当单个Redis热点Key的QPS达到数十万甚至百万级别时，即使Redis自身能承载，网络带宽和客户端连接池也会成为瓶颈。本地缓存（Local Cache）策略的核心思想是：在应用进程内存中缓存热点数据，将绝大部分读请求拦截在Redis网络层之前，从而彻底消除对Redis的冲击。

下图展示了引入本地缓存前后的请求路径对比：

4.2 本地缓存选型：Caffeine vs Guava Cache

Java生态中主流的进程内缓存方案是 Caffeine 和 Guava Cache。Caffeine基于Java 8重写，性能全面超越Guava Cache，是当前的首选方案。

4.3 Caffeine集成实战

以下是一个面向Redis热点削峰的Caffeine配置模板，重点在于最大容量、过期策略和异步刷新三个参数：

import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import java.util.concurrent.TimeUnit;

public class HotKeyLocalCache {

    // 热点Key本地缓存：最大10万条，写入后5秒过期，过期前2秒异步刷新
    private final Cache<String, String> cache = Caffeine.newBuilder()
            .maximumSize(100_000)                    // 最大条目数，防止OOM
            .expireAfterWrite(5, TimeUnit.SECONDS)   // 写入后5秒过期
            .refreshAfterWrite(3, TimeUnit.SECONDS)  // 写入后3秒异步刷新
            .recordStats()                           // 开启命中率统计
            .build(key -> loadFromRedis(key));        // 缓存未命中时回调

    // 从Redis加载数据（兜底逻辑）
    private String loadFromRedis(String key) {
        // 实际调用Redis客户端
        return jedis.get(key);
    }

    // 对外查询接口
    public String get(String key) {
        return cache.get(key, k -> loadFromRedis(k));
    }

    // 主动失效（数据更新时调用）
    public void invalidate(String key) {
        cache.invalidate(key);
    }

    // 获取命中率
    public double hitRate() {
        return cache.stats().hitRate();
    }
}

4.4 一致性保障策略

本地缓存最大的挑战是数据一致性：当Redis中的数据被更新后，如何通知所有应用节点失效本地缓存？以下是三种主流方案：

下图展示了基于Redis Pub/Sub的本地缓存一致性架构：

4.5 一致性保障代码实现

以下代码展示了如何在数据更新时通过Redis Pub/Sub广播失效事件，以及各节点如何订阅并清除本地缓存：

// ========== 数据变更服务（写操作） ==========
public class DataUpdateService {

    private final Jedis jedis;

    public void updateHotKey(String key, String newValue) {
        // 1. 更新Redis主数据
        jedis.set(key, newValue);

        // 2. 发布失效消息到指定频道
        //    消息格式：cache:invalidate:<key>
        jedis.publish("cache:invalidate", key);
    }
}

// ========== 应用节点（读操作 + 订阅） ==========
public class LocalCacheSubscriber {

    private final Cache<String, String> localCache;
    private final Jedis jedis;
    private volatile boolean running = true;

    public LocalCacheSubscriber(Cache<String, String> localCache, Jedis jedis) {
        this.localCache = localCache;
        this.jedis = jedis;
        startSubscriber();
    }

    private void startSubscriber() {
        new Thread(() -> {
            // 订阅失效频道
            jedis.subscribe(new JedisPubSub() {
                @Override
                public void onMessage(String channel, String message) {
                    // message就是需要失效的key
                    localCache.invalidate(message);
                    System.out.println("本地缓存失效: " + message);
                }
            }, "cache:invalidate");
        }, "local-cache-subscriber").start();
    }
}

4.6 避坑指南

• 内存泄漏风险： 本地缓存必须设置 maximumSize 和 expireAfterWrite，否则热点Key列表变化时，旧Key永远不会被淘汰，导致堆内存持续增长。
• 缓存击穿： 当本地缓存过期且Redis也恰好宕机时，所有请求会同时回源到数据库。解决方案：在 loadFromRedis 方法中加入分布式锁或限流，只允许一个线程回源。
• 序列化开销： 本地缓存存储的对象应尽量精简，避免存储大JSON或完整POJO。建议只存储热点Key的核心字段，或使用二进制序列化（如Protobuf）。
• 统计监控： 务必开启 recordStats()，将命中率、加载耗时等指标暴露给Prometheus/Grafana，以便及时调整缓存容量和过期时间。