Redis 大 Key 治理实战：如何分层识别、拆分与验证线上风险

线上 Redis 的内存突然逼近上限时，大家第一反应通常是缓存整体总量超标。实际排查下来往往会卡在上少数几个大 Key 上：它们不光会拖慢单次读取响应，执行删除操作时还可能直接卡住主线程，在实例扩容、主从同步阶段还会进一步放大复制链路的压力。大 Key 治理不能指望一次性全量清空解决问题，核心思路是先定位出具体对象类型和对应的访问风险，再分批完成拆分、迁移、清理，最后用统一的指标维度完成效果校验。

为什么一个大 Key 会变成多种线上风险

大 Key 的风险从来都不只是它占用了多少 MB 内存。Redis 的各类数据结构大多是单命令整体处理，Hash、List、Set 和 Sorted Set 这类复合结构尤其容易出现平时运行平稳，某次操作触发后性能突然陡降的情况。比如一个存了几十万字段的 Hash，在执行全量读取、自动过期、实例迁移或者主动删除操作时，都会产生比普通小 Key 长得多的连续主线程占用时间。

先用低成本方法找出候选 Key

排查第一步是缩小范围。可以在从节点、维护窗口或低流量副本上使用 redis-cli --bigkeys 做类型抽样；它适合发现各类结构中偏大的样本，但不是精确的全量排行榜。若业务已经有明确的命名空间，先按前缀分批抽样，结果更容易和负责人对应。

redis-cli -h 127.0.0.1 -p 6379 --scan --pattern 'user:*' | head -n 2000
redis-cli -h 127.0.0.1 -p 6379 memory usage user:profile:10086
redis-cli -h 127.0.0.1 -p 6379 type user:profile:10086
redis-cli -h 127.0.0.1 -p 6379 hlen user:profile:10086

MEMORY USAGE 给出的是近似字节数，HLEN 只能说明字段数量，二者都不能单独代表线上风险。String 要看值大小，Hash 要看字段数和字段值分布，List/Set/Sorted Set 则要结合元素数量和命令使用方式。

把“很大”改成可以执行的风险等级

团队不要直接硬设一个“超过多少字节就判定为大 Key”的固定阈值。一个 8 MB 的 String 可能只是业务上偶尔触发的下载缓存，本身访问频率很低；反而一个 2 MB 的 Hash 可能被频繁做全量读取，直接影响接口性能。更实用的判断方式是把容量阈值、访问路径特征、后续运维动作三个维度放到同一张评估清单里综合判断。

1. 观察级：容量偏高但访问曲线稳定，先建档记录 Key 基本信息和对应业务责任人。
2. 关注级：容量指标和对应命令耗时同时偏高，禁止业务侧新增同结构数据，安排做拆分验证实验。
3. 处理级：已经出现在慢日志里、引发主线程抖动或者复制延迟，先临时降低写入压力，再执行灰度迁移操作。

这阶段不用急着把所有符合大 Key 特征的对象都清理掉。先从慢日志、命令统计项和业务调用代码确认它是不是正在被全量读取；如果只是长期没人访问的冷数据，清理策略和热数据的拆分策略完全不一样。

拆分迁移时，先改变访问路径再改变数据

以 user:profile:10086 这个大 Hash 为例，可以把固定字段与低频扩展字段拆到不同 Key，或者按用户资料模块拆成 user:base:10086、user:preference:10086。新命名空间要带版本，例如 user:profile:v2:10086，这样灰度期间可以同时保留旧读路径。

-- 伪代码：先写新结构，再切换读取
HSET user:base:10086 name "Lin" region "sh"
HSET user:preference:10086 theme "dark"
SET user:profile:version:10086 v2 EX 86400

-- 切换后只按模块读取，避免整量 HGETALL

示例里的字段仅用来演示操作结构，不要直接把线上真实用户数据复制到命令行历史留下痕迹。生产环境做迁移还要提前处理双写失败、旧 Key 过期逻辑、读新失败回退旧值和回滚开关的相关适配。切换流量之前先保证新结构完全可正常读取，切流后要观察至少一个完整的业务高峰，确认没有异常之后再逐步清理旧 Key。

删除与回收：UNLINK 也需要验证

对大对象直接使用 DEL，可能把较长的回收工作集中到一次命令里。UNLINK 通常能把释放内存的工作放到后台线程，降低主线程被长时间占用的概率，但它不是“无代价删除”：删除队列、内存回收速度和实例负载仍要观察。

redis-cli unlink user:profile:10086
redis-cli info memory
redis-cli info stats

如果实例本来就处在高负载，连续提交大量 UNLINK 也可能造成后台回收积压。更稳妥的做法是按批次提交，给每批设置数量上限，并在内存、命令延迟、复制延迟任一指标恶化时暂停。

用同一组指标完成迁移后的复查

验证治理效果不能只看“大 Key 数量少了”这一个指标。至少要留存迁移前后同一时间窗口的全量数据：对应命名空间的总内存占用、相关命令的 P99 延迟、实例 used_memory 数值、内存碎片率、主从复制延迟和接口错误率。如果拆分之后总内存没有明显下降，大概率是存在字段重复、过期时间没有继承配置，或者旧的读路径还没改过来重新把旧 Key 写回去了。

• 随机抽查 20 个相同业务对象，对比旧结构和新结构的字段是否完整一致。
• 单独统计新读路径的 P50/P95/P99 延迟，避免用平均值掩盖长尾延迟问题。
• 确认旧 Key 在预设时间窗口之后不会继续增长，同时观察副本延迟指标是否回落到正常区间。
• 全程保留回滚开关和迁移批次号，一旦出现异常先切回读旧逻辑，暂停双写流程。

常见问题

Redis 大 Key 到底按多少字节判断？

不存在能适配所有业务场景的统一判定标准。建议把字节数作为初筛条件，再叠加元素数量、访问频率、命令耗时和删除影响多个维度，整理出适合自己团队的观察级和处理级阈值。

能不能直接用 SCAN 找出所有大 Key？

SCAN 适合渐进遍历 Key 名称，但它不会直接告诉你每个对象的完整业务风险。应先用它取样，再对候选调用类型、长度和内存占用检查，避免把高成本操作打到高峰实例。

拆分后旧 Key 什么时候删除？

至少等新的读路径跑完一个完整的业务高峰，同时确认回滚窗口、数据校验结果和副本同步状态都稳定之后，再着手清理旧 Key。对核心业务的重要数据建议保留带版本的回退数据，先设置自动过期观察，等全量运行稳定后再做彻底清理。

把大 Key 治理变成持续检查

一次专项治理只能解决当前已经存在的大 Key，持续的常态化检查才能避免新生成的数据再次长成大 Key。可以按命名空间维度记录 Key 的对象类型、元素数量、近似内存占用、最后访问时间和对应负责人；针对标记为处理级的大 Key 要绑定变更单和后续复查时间。后续再遇到内存告警的时候，排查直接从提前建好的清单和监控指标入手，不用临时挨个猜是哪个业务占满了 Redis 资源。