Redis 大 key 排查与治理实战：四种定位手段与四板斧方案

前言

“Redis 内存突然涨到 90%，但 key 数量没怎么变”——十有八九是大 key 惹的祸。大 key 的可怕之处不在于它占多少内存，而在于它会拖慢整个实例：单个 key 的操作阻塞主线程，进而影响所有请求的延迟。

这篇文章把大 key 从"定义 → 定位 → 治理 → 预防"的完整链路写清楚，附华为云 Redis 环境下的具体工具用法。

一、什么叫大 key

没有绝对标准，但业界的经验阈值比较一致：

为什么要这么严？因为 Redis 单线程模型下，操作一个 10 万元素的 Hash 意味着主线程被独占几十毫秒，期间所有其他请求排队——这就是"一个大 key 拖垮整个实例"的原理。

二、定位大 key 的四种手段

1. 云控制台的大 Key 分析（零成本，首选）

华为云 Redis 控制台自带"大 key 分析"，后台异步扫描不阻塞业务，直接给 Top N 大 key 列表（支持按元素数 / 内存两个维度）。日常巡检用它最省事，建议每周跑一次。

2. redis-cli --bigkeys（通用）

redis-cli --bigkeys -i 0.1

-i 0.1 表示每扫描 100 个 key 休眠 0.1 秒，降低对线上影响。局限：采样式统计，且只看元素数量维度——String 型的大 value 抓不全。

3. RDB 离线分析（最精准）

下载备份 RDB 文件，用 redis-rdb-tools 分析：

rdb --command memory dump.rdb > memory.csv
sort -t, -k4 -nr memory.csv | head -20

能得到每个 key 的精确内存占用，排序即得完整大 key 清单。生产环境推荐这种离线方式，对线上零侵扰。

4. 实时精确探测（补漏）

MEMORY USAGE keyname          # 单 key 精确内存
redis-cli --memkeys           # 遍历统计（需服务端支持）

遍历务必用 SCAN 而非 KEYS：

SCAN 0 COUNT 100 MATCH user:*  # 游标分批，不阻塞

三、治理四板斧

1. 拆分（治本）

大 Hash 按字段哈希分桶：user:stat:{id} → user:stat:{id}:{bucket}（如 16 个桶）。大 List 按业务 ID 分散写入不同 key。拆分后单 key 操作成本降到 1/N。

2. 压缩（降本）

value 是 JSON 时用 gzip/zstd 压缩，通常能降 60-80%。注意压缩和解压的 CPU 开销要评估，高频读取的场景不一定划算。

3. 删除要用 UNLINK

UNLINK bigkey      # 异步删除，后台线程回收
# 而不是 DEL bigkey（同步删除会阻塞）

Redis 4.0+ 支持。超大 key 也可以 SCAN + 分批 DEL，每批 100~500 个元素。

4. 过期时间加抖动

大批 key 同时过期会造成内存抖动和慢查询。给 TTL 加随机偏移：

ttl = base_ttl + random.randint(0, 300)

四、华为云 Redis 环境的补充提示

监控告警前置：控制台的"大 key 数量"指标可以配置告警，超过阈值（比如单实例 10 个）就通知，比事后救火从容。

GeminiDB Redis 的差异：云原生架构下分片模型不同，但大 key 危害本质一样——单分片热点。控制台的实时 Top Key 统计 + 慢日志（SLOWLOG GET）配合使用，定位"哪个 key 拖慢了整体"效率最高。

慢日志是线索：SLOWLOG GET 10 看到的慢命令里如果反复出现同一个 key 前缀，基本就是它了。

五、预防：从设计阶段避免

1. 写入口收口：所有集合类写入前校验元素数量上限（超限拆桶或拒绝）
2. Code Review 清单：把"是否会写大 key"加进 Redis 使用规范
3. 压测覆盖：上线前用接近真实数据规模的集合做压测，避免小数据量下的"假快"

写在最后

大 key 问题"发现容易、治理麻烦"，最好的策略是设计和巡检双管齐下：写入侧卡住上限，运维侧每周巡检。真遇到存量大 key，按"拆分 → 压缩 → UNLINK 删除"的顺序处理，注意删除一定要用异步方式。

一句话记忆：大 key 不是内存问题，是延迟问题。看到延迟抖动先查大 key，比查网络和 CPU 更快命中。