根本原因是MOVE命令迁移大Key时需原子性搬运整个value并阻塞slot读写；应通过业务层拆分（如SCAN+HSCAN）、人工slot迁移及提前识别大Key来解决，而非依赖reshard。
大Key导致Redis集群迁移卡顿的根本原因
Redis集群迁移卡顿不是因为网络慢或机器差，而是MOVE命令在迁移一个大Key时必须原子性地搬运整个value——比如一个500MB的hash或zset，它不会分片传输，而是阻塞当前slot的所有操作，直到整个结构序列化、发送、反序列化完成。这个过程会锁住源节点和目标节点上该slot的全部读写，其他小Key也得排队等。
用SCAN + HSCAN/ZSCAN手动拆分大Hash/ZSet
Redis原生不支持“把一个大hash拆到多个key”，但业务层可以主动做逻辑拆分。核心思路是：不再用单个hset user:1001:profile存全部字段，改用带分片标识的key，例如user:1001:profile:0、user:1001:profile:1……再配合HSCAN分批读取。
- 拆分前先用
hlen或zcard确认是否超阈值（建议单key > 10KB 或元素数 > 1k 就预警） - 拆分时用
HSCAN user:1001:profile 0 COUNT 100逐批拉数据，每批写入新key，避免单次操作太久 - 注意客户端缓存和旧key清理时机：确保所有读请求已切到新key结构后再
DEL旧key，否则会丢数据 - 别依赖
KEYS查大key——它会阻塞主线程，改用redis-cli --bigkeys或MEMORY USAGE定位
利用CLUSTER SETSLOT在业务低峰期手工迁移Slot
自动迁移（CLUSTER SETSLOT ... IMPORTING/MIGRATING）遇到大Key会卡死，但你可以跳过自动流程，用人工方式控制节奏：先停写对应slot的业务流量（如通过配置中心关掉相关功能），再执行迁移，最后恢复。
- 确认目标slot：用
CLUSTER KEYSLOT "somekey"算出key归属slot，再用CLUSTER SLOTS查当前分配 - 迁移前用
redis-cli -c -h src -p 6379 --cluster migrate dst_host:dst_port "" 0 1000 --copy --replace测试单key迁移耗时 - 真正迁移时，用
CLUSTER SETSLOT <slot> IMPORTING <node-id></node-id></slot>和MIGRATING两步手动设状态，再配合MIGRATE命令分批推key - 注意
MIGRATE默认同步等待响应，加TIMEOUT 60000防止超时中断，但timeout太长也会卡住节点
redis-cli --cluster reshard为什么不能直接解决大Key卡顿
很多人以为跑一遍redis-cli --cluster reshard就能“智能”避开大Key，其实它只是按key数量平均分slot，完全不感知value大小。一个含10万个field的hash仍会被当作1个key计入统计，最终可能整块被迁到新节点，照样卡。
- reshard本质是key-level调度，不是data-level拆分
- 它不触发
RDB生成或AOF重写，所以对内存压力无缓解 - 如果源节点已有大量大Key，reshard过程中一旦遇到，迁移命令会hang住，
CLUSTER NODES里能看到该节点长时间处于fail?或connecting状态 - 真正有效的做法是：先用
MEMORY DOCTOR或MEMORY STATS识别大Key，再结合业务逻辑提前拆，而不是指望集群命令自动兜底
大Key拆分不是运维动作，是数据建模决策；卡顿只是表象，背后是key设计没对齐Redis的单线程+全量搬运模型。上线前没压测大Key场景，后面就得在凌晨一边看监控一边手抖敲MIGRATE。
