redis-cli --bigkeys在集群中仅扫描首个master节点DB0，因不识别Cluster架构、不支持重定向或槽位跳转；须手动逐个直连各master执行，并用MEMORY USAGE等验证真实内存占用。
redis-cli --bigkeys 在集群中会失效
直接在 Redis 集群节点上运行 redis-cli -c --bigkeys 会报错或返回不完整结果，因为 --bigkeys 是单实例扫描命令，不支持 -c（cluster）模式。它无法跨 slot 自动路由，也不能聚合各分片结果。
真正可用的方式只有两种：
- 逐个连接每个 master 节点（不加
-c），分别执行redis-cli -h node_ip -p port --bigkeys - 用
redis-rdb-tools解析 RDB 文件：先对每个 master 执行bgrewriteaof或等待自动 bgsave，再离线分析 dump.rdb —— 这是生产环境首选，零干扰
注意：别在高峰期跑 --bigkeys，哪怕单节点也会短暂升高 CPU，影响请求延迟。
MEMORY USAGE 和 SCAN 组合定位具体大key
确认某节点存在大key嫌疑后，用 SCAN 分批拉 key，配合 MEMORY USAGE 测真实内存占用。不能只看 strlen 或 hlen，因为 Redis 内部编码（如 ziplist vs hashtable）会导致实际内存远大于逻辑大小。
示例流程：
-
SCAN 0 MATCH user:* COUNT 1000获取一批 key - 对每个 key 执行
MEMORY USAGE <key>，记录 >1MB 的结果 - 对集合类 key 补充
DEBUG OBJECT <key>，看serializedlength和encoding字段，判断是否因小元素过多触发了低效编码
特别提醒：MEMORY USAGE 返回的是近似值，但足够用于排序和筛选；DEBUG OBJECT 在部分生产环境被禁用，需提前确认权限。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
集群环境下删大key必须用 unlink + 渐进式清理
在集群中直接 DEL 一个含 50 万元素的 zset，该节点会卡住 800ms+，所有落在这个 slot 的请求全超时。更糟的是，如果这个 key 恰好是热点，还会放大故障。
正确做法分两层：
- 单次操作级：一律改用
UNLINK替代DEL（Redis 4.0+），释放内存交由后台线程处理，主线程几乎不阻塞 - 批量清理级：对超大集合，用
ZSCAN/HSCAN分批读出元素，再用ZREM/HDEL小批量删除，每次不超过 1000 个，中间加SLEEP 0.01（客户端控制节奏）
别依赖 EXPIRE 让大key“自然过期”——过期那一刻仍是同步删除，照样阻塞。
拆分大key必须考虑 slot 分布与业务一致性
把一个 user:1000:profile（2MB JSON）拆成 user:1000:profile:base、user:1000:profile:ext 看似简单，但若两个子 key 落在不同 slot，原子性就没了。业务侧读写必须容忍部分失败或引入事务协调（比如用 Lua 脚本包装多 key 操作）。
更稳妥的拆分方式：
- 按业务维度切分：比如把用户订单按月份拆成
order:1000:202608、order:1000:202609，天然保证同用户同月数据在一个 key 内，且可预估单 key 大小 - 加哈希后缀：如
user:1000:profile:0~:7，用1000 % 8决定后缀，确保同用户所有 profile 子 key 路由到同一 slot
拆分不是终点，要配套改客户端：原来一次 GET 变成多次并行 GET，失败需降级兜底，不能让拆分暴露为接口抖动。
