Redis的大Key问题怎么解决？

# 1) 什么是大 Key & 有啥危害 * **定义**：单个 key 的**值很大**（String 体积大）或**元素很多**（Hash/List/Set/ZSet 的 field/成员量很大）。 * **危害**： 1. **阻塞**：对大 key 做 `DEL`/`HGETALL`/`LRANGE` 等重操作，可能长时间占用 CPU，造成主线程阻塞、RT 抖动。 2. **复制/AOF 抖动**：大 key 变更带来**复制延迟**、AOF 膨胀与重写开销。 3. **迁移困难**：Cluster 迁槽、MIGRATE 对大 key 成本高、易超时。 4. **网络与带宽压力**：一次读取返回太大包体，拖慢客户端与网关。 5. **内存碎片与淘汰**：容易触发淘汰或 OOM。 # 2) 怎么发现大 Key（线上可用） * **一键扫描**（抽样统计）： ```bash # 统计各类型最大键及其大小（适合初步摸底） redis-cli --bigkeys # 统计按内存大小排行（更精准，建议 Redis 6+） redis-cli --memkeys ``` * **逐个估算**： ```bash MEMORY USAGE my:key # 字节 OBJECT ENCODING my:key # 查看底层编码（listpack/hashtable/quicklist/skiplist等） SCAN 0 MATCH prefix:* COUNT 1000 # 采样 + MEMORY USAGE 估算 ``` * **热点 ≠ 大 key**：用 `redis-cli --hotkeys` 或监控区分“热点 key（访问频繁）”与“大 key（体积大/成员多）”，两者处理思路不同。 * **Cluster**：逐节点执行（或用集群管理工具汇总）。 # 3) 安全处置：先“止血”再“拆分” ## 3.1 安全删除与下线 * **优先用异步删除**：`UNLINK my:key`（Redis 4+）；**不要**直接 `DEL` 大 key。 * 全库：`FLUSHDB ASYNC` / `FLUSHALL ASYNC`。 * 打开懒删除（减少阻塞）： ```conf lazyfree-lazy-user-del yes lazyfree-lazy-eviction yes lazyfree-lazy-expire yes lazyfree-lazy-server-del yes ``` ## 3.2 读写限流与分页 * 对 `HGETALL`/`SMEMBERS`/`ZRANGE 0 -1` 等**全量遍历**操作改为： * **分页**：`HSCAN`/`SSCAN`/`ZSCAN`；`ZRANGE byscore/lex` 分段。 * **裁剪**：`LIST` 用 `LTRIM` 维持上限；`XADD MAXLEN ~ N` 控制 `Stream` 长度。 * API 限制：服务端对返回体设置**最大条数/最大字节**，避免一次性拉爆。 # 4) 重构与拆分（按数据结构给出落地方案） > 原则：**按业务维度分片**、**按时间滚动分桶**、**按成员数量设上限**。 ### 4.1 String 大 Value * **分片存储**：把大对象按 1MB/2MB 切片： ``` obj:{id}:0, obj:{id}:1, ... # 元信息中记录总片数 ``` * 读：`MGET` + 组装（pipeline）。 * **外部化大文件**：大二进制（图片/报告）放 **对象存储（OSS/S3）**，Redis 只存指针+元数据。 * **压缩**：客户端 LZ4/Snappy 压缩再写入（权衡 CPU）。 ### 4.2 Hash（field 特别多） * **分桶**：`user:attr:{uid}:{bucket}`，对 field 做哈希或时间分桶，单桶**限制字段上限**（如 1\~5 万）。 * **按时间滚动**：`hash:{uid}:2025-08`，老桶定期归档/删除。 * **只取必要字段**：避免 `HGETALL`，改 `HMGET`/`HSCAN` 分页。 ### 4.3 List（超长队列） * **封顶列表**：生产侧每次 `LPUSH` 后 `LTRIM key 0 N`，保持长度 ≤ N。 * **分区队列**：`queue:{topic}:{shard}` 多分片并行消费。 * **换用 Stream**：`XADD MAXLEN ~ N` + 消费组（支持持久、背压）。 ### 4.4 Set/ZSet（成员爆炸） * **时间分桶**：排行榜/延迟队列按**日/周**分表：`rank:2025-08-13`；只保留“当前 + 最近 N 个桶”。 * **按业务分片**：`rank:{game}:{shard}`。 * **统计替代**：只需去重计数用 **HyperLogLog**（`PFADD/PFCOUNT`），Top-N 估算用 **TopK（RedisBloom 模块）**。 * **范围查询分页**：`Z[RANGE|REVRANGE] offset count` 或 `ZRANGEBYSCORE` 分段。 # 5) 预防：把“大 key”扼杀在设计阶段 * **键/成员上限**：在应用层对每类 key 设**硬阈值**（条数/字节），超限拒收并告警。 * **TTL 策略**：数据有生命周期就**必须设置过期**；配合“滚动分桶 + 归档”。 * **规范序列化**：JSON 字段名用短名、必要时压缩；避免嵌套过深。 * **监控与告警**： * 周期性跑 `--memkeys`/采样 `MEMORY USAGE` 统计**按前缀**的占用 TopN； * 关注 `repl_backlog`、`aof_current_size`、`latency doctor`、慢查询。 * **迁移/扩容**：Cluster 环境下，提前分片键（使用 **HashTag**：`{tag}`）确保相关分片落同槽，便于迁移与跨键操作。 # 6) 迁移/修复大 Key 的稳妥做法 * **在线拷贝**：`DUMP/RESTORE` + `SCAN` 分页 + pipeline，避免一次性 `MIGRATE` 超时。 * **只读窗口**：迁移期间短暂只读或双写校验，完成后切流。 * **删除旧数据**：迁移完成用 `UNLINK`/异步删除。 # 7) 面试速答版（10 秒） > 大 key 会导致**阻塞、复制/AOF延迟、迁移困难**。**发现**靠 `--bigkeys/--memkeys`、`MEMORY USAGE` 抽样；**处置**用 `UNLINK` + 懒删除；**重构**按业务/时间分桶与分片（List 限长、ZSet 分期、Hash 分桶、String 切片/外部化）；**预防**设上限+TTL+监控，必要时用 Stream/HyperLogLog/TopK 替代。