大Key导致主从同步卡住时，需同时观察INFO replication中slave_repl_offset与master_repl_offset差值长期不缩小、net_output_bytes突增、从节点日志出现Timeout waiting for bulk read；三者共现即为大Key单次传输阻塞复制流。
主从同步卡住时怎么确认是大Key导致的
直接看 INFO replication 输出里的 slave_repl_offset 和 master_repl_offset 差值是否长期不缩小，再结合 net_output_bytes 是否突增、从节点日志里有没有 Timeout waiting for bulk read —— 这三者同时出现，基本就是大Key在单次传输中把复制流堵死了。
别只信 redis-cli --bigkeys，它只告诉你“哪个key大”，不告诉你“它正在拖垮同步”。更准的方式是：MEMORY USAGE bigkey_name 查实际内存占用，再用 OBJECT FREQ bigkey_name 和 OBJECT IDLETIME bigkey_name 判断是不是冷数据、值不值得立刻拆。
用 HSCAN/SSCAN 拆分大Hash或大Set时不踩坑的关键点
不能直接 HDEL 或 DEL，否则主节点CPU瞬间拉满，且删除命令本身又会作为一条大指令同步到从节点，形成二次冲击。
- 必须在主节点执行：所有
HSET、HDEL、SADD、SREM都要走复制流，从节点只读，不参与任何写逻辑 -
HSCAN myhash 0 COUNT 100每次最多拉 100 个 field；SSCAN myset 0 COUNT 500同理，别贪多——从节点同步时单条命令超 500KB 就容易触发client-output-buffer-limit断连 - 每次操作后加
SLEEP 0.01（比如用redis-cli --eval调 Lua），避免连续高密度命令压垮主线程或复制缓冲区 - 新 key 命名要有规律，比如
myhash:shard001、myset:part1，方便后续清理和监控
UNLINK 在主从同步场景下到底有没有用
UNLINK 不是“分段释放”，只是把删除任务扔给后台线程，主线程不卡了，但对从节点完全没帮助：主节点写入 AOF 和复制流的仍是 DEL 命令，从节点收到后照样得同步执行一次阻塞删除。
所以 UNLINK 单独用，解决不了主从同步问题。它只有配合渐进式拆分才有意义——比如先用 HSCAN 把大 Hash 拆成小份，再对每个小 key 用 UNLINK 清理，这时每条删除都轻量，复制流才安全。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
注意：即使用了 UNLINK，也得提前调大关键配置，否则照样断连：client-output-buffer-limit slave 512mb 128mb 60、repl-backlog-size 1024mb 必须在出问题前就设好。
集群模式下大Key带来的隐藏风险
Redis Cluster 不会自动拆分大Key，一个几MB的 ZSET 如果 hash 到某个 slot，就会让那个节点内存和网络带宽双双吃紧，造成数据倾斜——其他节点空闲，它却频繁 OOM 或复制延迟飙升。
业务侧必须自己做分片：比如把原 key user:orders:123 改成 user:orders:123:001 ~ user:orders:123:010，按时间或 ID 取模分桶，读取时聚合。别指望 Cluster 自动帮你扛。
监控不能只盯单实例的 bigkey 数量，得叠加看每个 slot 的内存使用率和 slave_repl_offset 差值——倾斜往往发生在某几个 slot 上，而不是整 cluster 均匀分布。
