Redis 热 key 单分片被打到 98% CPU：本地缓存 + 一致性令牌 + 限流的三层防线

作者林砚舟

Redis热key本地缓存高并发性能调优

结论先行：热 key 的根因不是「Redis 慢」，而是集群分片均衡被单 key 击穿——所有读都落在同一个分片上，其余 7 个分片在空转。解法不是加机器、不是调 Redis，而是把 90% 的读拦在应用进程内（本地缓存），用一致性令牌控制失效窗口，再用限流兜住击穿瞬间的 miss 洪峰。下面是一次大促的真实复盘。

一、现象与背景（带数字）

大促预热期压测，一个商品 SKU 详情页接口出问题。该服务是 Spring Boot 3.2 / JDK 21，后端读 Redis 7.2 集群（8 分片，单分片 maxmemory 8GB，allkeys-lru）。平时单 key QPS 约 4k，压测拉到「爆款」场景后：

单个 SKU 的 key QPS 从 4k 冲到 38 万；
承载该 key 的分片 CPU 从 32% 飙到 98.4%，网络出口打满 9.2 Gbps；
其余 7 个分片 CPU 只有 10%~18%，几乎空转；
该接口 P99 从常态 8ms 恶化到 45ms，并出现零星超时；
Redis 侧 instantaneous_ops_per_sec 单分片 36 万，keyspace_hits 命中率 99.9%（说明不是缓存没命中，是打得太狠）。

加机器没用：这是 8 分片集群，热点 key 物理上只属于 1 个分片，横向扩容不改变「所有读挤向 1 分片」的事实。

二、原理与根因

为什么加机器救不了：Redis Cluster 按 CRC16(key) % 16384 把 key 映射到 slot 再映射到分片。一个 key 的读永远路由到同一个分片。QPS 越高，这个分片的 CPU（网络序列化 + 命令执行）和网卡带宽越先饱和。这是单分片瓶颈，不是集群瓶颈。

为什么本地缓存能救：把读结果缓存到应用进程内存里，90% 的请求不再发网络往返，直接进程内返回。38 万 QPS × 90% ≈ 34 万被拦在本地，真正打到 Redis 的只剩约 4 万，单分片压力骤降一个数量级。

为什么必须有「一致性令牌」和「限流」：本地缓存是最终一致的，写路径（改价、改库存）后各节点本地缓存是脏的；且 TTL 到期瞬间会有一波 miss 同时打回 Redis（击穿）。这两个问题不解决，本地缓存反而会把「不一致」和「击穿洪峰」放大。

三、具体做法（可复现）

1) 本地缓存（Caffeine，异步刷新）

Cache<Long, SkuDto> hotCache = Caffeine.newBuilder()
    .maximumSize(2000)                       // 只缓存热点，别全量
    .expireAfterWrite(Duration.ofMillis(300)) // 硬过期：一致性窗口上限
    .refreshAfterWrite(Duration.ofMillis(100)) // 软刷新：到期后异步回源，旧值继续可读
    .recordStats()                            // 开命中率统计
    .build(skuId -> loadFromRedis(skuId));    // loader 回源 Redis

2) 一致性令牌（version 兜底脏读）

每个热点 key 在 Redis 里维护一个 version。写路径顺序：SET value → INCR version。读路径带 version 比对，本地缓存存 (value, version)，version 不一致则视为失效：

// 写路径：先写值，再推版本号（顺序不能反，否则读到「新 version + 旧 value」）
redis.set(key, newJson);
redis.incr(key + ":v");

// 读路径：本地 version < 远端 version 时强制回源
long localV = entry.version();
long remoteV = Long.parseLong(redis.get(key + ":v"));
if (localV < remoteV) { /* 本地脏，回源并更新 version */ }

3) 击穿限流（Guava RateLimiter 兜住 miss 洪峰）

TTL 到期瞬间的 miss 全部打向 Redis，用限流把这波「回源」压平：

private static final RateLimiter HOT_KEY_GUARD = RateLimiter.create(5000); // 回源上限

SkuDto loadWithGuard(Long skuId) {
    if (!HOT_KEY_GUARD.tryAcquire()) {
        return staleOrNull(skuId); // 拿不到令牌：返回旧值/降级，绝不打穿
    }
    return loadFromRedis(skuId);
}

4) 观测（压测/线上验证）

# 单分片实时命令速率（确认热点分片）
redis-cli -h <node> -p <port> info stats | grep instantaneous_ops_per_sec
# 单分片内存与命中率
redis-cli -h <node> -p <port> info memory | grep used_memory_human
redis-cli -h <node> -p <port> info keyspace | grep keyspace_hits
# 客户端到 Redis 的 RT
redis-cli -h <node> --latency

四、踩过的坑 / 反直觉

命中率 91% 不代表安全：Caffeine recordStats() 显示本地命中率 91%，看着很美，但那 9% 的 miss 全部落在同一个 Redis 分片上——等于把 38 万 QPS 里的 3.4 万集中砸向 1 分片。所以必须叠加限流，命中率不能单独作为安全指标。
TTL 调小不能治击穿：把 expireAfterWrite 从 300ms 调到 50ms，miss 反而更频繁，打回 Redis 的洪峰更密。击穿根因是「同时 miss」，不是「缓存活得久」。
秒杀库存别走本地缓存：refreshAfterWrite 是异步刷新，刷新窗口内旧值会继续被返回。对「展示类」（商品名、价格）可接受 300ms 窗口；对「库存扣减」这种强一致场景，本地缓存的脏读是致命的，必须直连 Redis 或走分布式锁。
写路径顺序不能反：先 INCR version 再 SET value，会出现「新 version + 旧 value」，所有节点误判缓存有效，脏数据被放大。
不要全量本地缓存：maximumSize(2000) 只放热点；全量缓存会让内存和一致性问题一起爆炸。

五、结论与可复用清单

热 key 的本质是分片倾斜，横向扩容无效；正解是「进程内拦截 + 一致性控制 + 击穿限流」三层。可复用清单：

[ ] 先确认是不是单分片热点：看 instantaneous_ops_per_sec 是否某分片远高于其余，而不是急着加机器；
[ ] 展示类数据上 Caffeine：maximumSize 限热点、expireAfterWrite 控窗口、refreshAfterWrite 做异步刷新；
[ ] 强一致数据（库存）不走本地缓存，直连 + 分布式锁；
[ ] 写路径 SET value → INCR version，顺序固定，读路径按 version 判脏；
[ ] miss 回源加 RateLimiter 兜底，拿不到令牌返回旧值/降级，绝不打穿；
[ ] 监控命中率和单分片命令速率两个指标，命中率单独看会骗人。

效果：上线三层后，热点分片 CPU 从 98.4% 回落到 41%，接口 P99 从 45ms 回到 8.2ms，压测 38 万 QPS 稳定通过。

赞 1 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。