rdb/aof不参与slot迁移，但迁移过程可能触发持久化行为；迁移是内存点对点搬运，不依赖磁盘文件，但save时机、aof always策略、migrate参数及批量操作会间接放大延迟或磁盘压力。
RDB/AOF 不参与 Slot 迁移，但迁移过程会触发持久化行为，可能意外放大延迟或磁盘压力
Redis集群迁移时RDB/AOF是否被调用？
不会主动触发 RDB 快照或 AOF rewrite。Slot 迁移本身是内存数据的点对点搬运（migrate 命令走 TCP 同步传输），不依赖磁盘文件。但注意两个隐式关联：
- 如果迁移期间恰好到了
save配置的时间点（如save 900 1），fork 子进程生成 RDB 会与迁移争抢 CPU 和内存带宽，导致migrate超时或客户端 ASK 重试堆积 - 若开启了 AOF 且使用
always策略，每个migrate操作本质是目标节点执行SET类命令，这些命令会被追加写入 AOF 缓冲区——在高 key 数量迁移时，AOF fsync 频率上升，可能拖慢目标节点响应
migrate 命令参数如何影响持久化负载？
migrate 的 timeout 和 replace 参数间接决定持久化压力大小：
-
timeout=5000（5秒）太短：网络抖动易导致迁移失败重试，重复写入目标节点 → 多次触发 AOF append 或 RDB dirty 计数上涨 -
replace=True是安全选择，但每次成功迁移都会在目标节点产生一次完整写命令；若用copy=True，源节点不删 key，后续需人工清理，且 AOF 日志里会多出冗余写入 - 批量迁移时避免单次
count过大（如cluster_getkeysinslot slot 1000）：一次取太多 key 导致单次migrate耗时飙升，可能卡住主线程，连带影响 RDB fork 或 AOF rewrite 的调度时机
为什么迁移中突然出现大量 ERR max number of clients reached？
这不是 Slot 迁移本身的错误，而是持久化副作用引发的资源挤占：
- RDB fork 会复制当前进程页表，若实例内存大（比如 20GB+），fork 可能阻塞数百毫秒，期间新连接排队，叠加客户端因 ASK 重试建立的临时连接，快速耗尽
maxclients - AOF rewrite 同样 fork 子进程，且 rewrite 过程中父进程需缓存新写命令（
aof_rewrite_buf_blocks），内存峰值可能翻倍，OOM killer 可能干掉 redis 进程 - 规避方式：
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf+sysctl vm.overcommit_memory=1，并确保maxmemory设置合理（别设为机器总内存）
Slot 迁移真正难的不是命令怎么敲，而是得盯着 INFO persistence 里的 rdb_bgsave_in_progress、aof_rewrite_in_progress、loading 这三个字段——只要任一为 1，就别启动迁移。没人告诉你，但这就是线上不出事的底线。
