大 Key / 热 Key 线上治理

大 Key / 热 Key 线上治理：定位、拆分、降级全套优化手段

Redis 崩了，八成跟这两个" Key "有关。

大 Key 让你的 Redis 堵得像早高峰的三环，热 Key 让单节点 QPS 直接打满——它们不是同一个问题，但都能让整个集群陪葬。这篇文章把从定位到治理的全链路方案讲透，每一步都能直接落地。

一、先搞清楚：大 Key 和热 Key 根本不是一回事

治理大 Key 是设计问题，治理热 Key 是架构问题。搞混了，方案全废。

二、大 Key：精准定位，三步锁定

第一步：全局扫描，快速圈定嫌疑对象

bash

redis-cli -h 127.0.0.1 -p 6379 --bigkeys

输出示例：

Biggest string found so far 'product:detail:1001' with 120000 bytes Biggest hash found so far 'user:info:10000' with 10000 fields

这条命令按类型输出每个类型里最大的 Key，适合快速摸底。但注意：它只告诉你"最大的"，不告诉你"所有大的"。真正的大 Key 可能藏在第 10 名。

生产建议：在从节点执行，避免影响主节点性能。

第二步：精确测量，确认威胁等级

对疑似大 Key 做二次确认：

bash

TYPE product:detail:1001 # 确认数据类型 STRLEN product:detail:1001 # 字符串体积（字节） HLEN user:info:10000 # Hash 字段数 LLEN order:list:1001 # List 元素数 MEMORY USAGE product:detail:1001 # 真实内存占用（含管理开销）

统一判定标准（华为云/腾讯云实践共识）：

第三步：SCAN + DEBUG 组合，批量排查

--bigkeys只能看 Top 1，要找出所有大 Key，必须编程扫描：

python

import redis r = redis.Redis(host='127.0.0.1', port=6379, decode_responses=True) cursor = 0 big_keys = [] while True: cursor, keys = r.scan(cursor=cursor, count=100) for key in keys: size = r.debug_object(key).get('serializedlength', 0) if size > 10240: # 10KB 阈值，按需调整 big_keys.append((key, size)) if cursor == 0: break print(f"发现 {len(big_keys)} 个大 Key") for k, s in big_keys: print(f"{k}: {s} bytes")

进阶：离线分析 RDB 文件

生产环境大规模集群推荐离线分析，不影响线上：

bash

rdb-tools -c memory dump.rdb > memory.csv # 在 CSV 中筛选 serializedlength > 10240 的行

关联业务证据，确认优先级

定位完技术指标后，必须关联业务：

bash

SLOWLOG GET 128

看慢查询里是否有大 Key 的身影。如果HGETALL user:info:10000频繁出现在慢查询中，它就是你的头号敌人。

建立排查台账：

三、大 Key 治理：拆是核心，删要安全

手段一：拆分——最有效，没有之一

原则：避免一次操作全量数据。

Java 客户端分片示例：

java

public class KeySharding { private static final int SHARD_COUNT = 10; public String getShardedKey(String originalKey, String userId) { int shardIndex = Math.abs(userId.hashCode()) % SHARD_COUNT; return originalKey + ":" + shardIndex; } } // 写入时：product:123 -> product:123:0 ~ product:123:9 // 读取时：随机或 hash 选取一个分片

手段二：安全删除——UNLINK 替代 DEL

这是最容易踩的坑：直接 DEL 大 Key 会阻塞主线程。

bash

# ❌ 危险：主线程阻塞，期间所有请求排队 DEL big:hash:key # ✅ 安全：Redis 4.0+，异步释放，不阻塞主线程 UNLINK big:hash:key

Redis 6.0+ 可开启惰性删除：

bash

lazyfree-lazy-user-del yes lazyfree-lazy-user-flush yes

开启后，即使执行DEL，底层也等效于UNLINK。

对集合类型大 Key，必须分批删：

bash

# Hash：先 HSCAN 取字段，再 HDEL 逐个删 HSCAN big:hash 0 COUNT 100 HDEL big:hash field1 field2 field3 ... # List：先 LRANGE 分页取，再 LTRIM 缩减 LRANGE big:list 0 99 LTRIM big:list 100 -1

手段三：数据迁移——不该放 Redis 的搬走

超大 JSON、二进制文件、历史归档数据——Redis 不是为这些设计的。

铁律：所有可过期数据必须设置 TTL。忘设 TTL 是大 Key 膨胀的第一元凶。

四、热 Key 治理：把火分散，把压降级

第一步：找到那把"火"

华为云实践阈值：访问频率 > 100,000 次/分钟 = 热 Key，设置多级预警。

第二步：四大治理手段，按场景选

手段一：Key 分片——读多写少的首选

把一个热 Key 拆成 N 个副本，流量打散：

hot:product:123 → hot:product:123:0 ~ hot:product:123:9

写：只写主 Keyhot:product:123:0
读：随机或 hash 取一个分片

java

// 读取时随机选一个分片 int shard = ThreadLocalRandom.current().nextInt(10); String key = "hot:product:123:" + shard; return redisTemplate.opsForValue().get(key);

京东 hotkeys 方案更进一步：代理层自动识别热 Key，创建临时副本，实现流量自动负载均衡。

手段二：本地缓存——挡在 Redis 前面的最后一道墙

热点数据根本不该到 Redis。用 Caffeine/Guava Cache 挡在应用层：

java

LoadingCache<String, Object> localCache = Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(5, TimeUnit.MINUTES) .build(key -> redisTemplate.opsForValue().get(key));

收益：某线上案例，接入本地缓存后 Redis QPS 骤降 99%。

但要注意：

• 本地缓存过大会导致 GC 压力
• 必须有同步机制保证与 Redis 一致性（推荐 Redis 发布订阅 + 版本号校验）

手段三：读写分离——读压力的解药

适用于读多写少场景：

写请求 → 主节点 读请求 → 从节点（多个）

云上一键开启即可。但从节点增多会增加故障率，运维复杂度上升，需权衡。

手段四：限流 + 降级——最后的保险

当热 Key 已经把 Redis 打满，必须断臂求生：

五、全链路闭环：从发现到根治

治理不是一次删除，是建立可持续的闭环：

发现 → 止血 → 改造 → 验证 → 回滚 → 监控

六、一张表记住所有方案

Redis 的性能上限，往往取决于 Key 的设计能力。大 Key 靠拆，热 Key 靠分，而所有方案的前提是——你得先找到它们。