综合 Redis 原子槽迁移:CLUSTER MIGRATION 把 -ASK 和 TRYAGAIN 从扩缩容里拿掉了

2026-10-24 21:06:09

Redis 8.4 原子槽迁移:用 CLUSTER MIGRATION 替代逐 key MIGRATE

Redis 8.4(GA 2025-11-18)增加了一个新命令 CLUSTER MIGRATION,也就是原子槽迁移(Atomic Slot Migration,ASM):把一个槽和它关联的数据以一次原子操作搬走,消除过去槽迁移期间短暂不可用、不可靠的窗口。同一版本还新增 CLUSTER SLOT-STATS,提供每个槽的使用指标——key 数量、CPU 时间、网络 IO。

旧方案:逐 key MIGRATE 的几类问题

  • 重定向与客户端复杂度:迁移过程中一部分 key 已搬走、一部分没搬走。客户端访问已迁走的 key 会收到 -ASK,需要重试,增加复杂度和网络延迟,也会打断朴素的 pipeline。
  • 多 key 命令不可靠:MGET key1 key2 这类命令,只要其中一个 key 已迁走,就会收到 TRYAGAIN,客户端必须等整个槽迁移完才能完成这条命令。
  • 迁移中断留下脏状态:部分 key 已移动,但 Redis 没能删掉源上的额外 key(例如目标内存不足),实例会停在需要人工处理的状态,且常导致数据丢失。
  • 副本信息不同步:replica 并不总能知道某个槽正在迁移,于是可能把「key 已迁走」返回成「key 被删除」,而不是返回 -ASK。
  • 性能:逐 key 迁移本质上是慢的,多出额外的查找与网络往返。

ASM 怎么工作

可以把它理解为 replica 全量同步在槽级别的版本:整个槽的内容先复制到目标节点,同时跟一条实时增量(类似 replication backlog);只有复制完成后,才做一次原子所有权移交。客户端在复制期间继续与源节点通信,因此不会遇到上面的 -ASK、TRYAGAIN 和副本回「key 被删除」这类问题。

上线流程

  1. 选槽。用 CLUSTER SLOT-STATS 看每个槽的 key 数量、CPU 时间、网络 IO,据此挑出需要迁走的热点槽,而不是凭感觉切分。
  2. 迁移。对选定槽执行 CLUSTER MIGRATION,具体语法与参数以 redis.io 官方文档为准,不同小版本的选项会变。
  3. 观察。迁移期间盯住源端与目标端的 CPU、内存、网络,以及 slot 统计值的变化;目标端内存不足是旧方案里最容易留下脏状态的原因,同样要提前留出余量。
  4. 校验。移交完成后核对槽归属(CLUSTER SLOTS / CLUSTER SHARDS 一类命令)与 key 数量是否符合预期,再回收源端的遗留数据。

8.4 的限制

使用 Redis 8.4 时需注意:在原子槽迁移期间,搜索命令(FT.SEARCH、FT.AGGREGATE、FT.CURSOR、FT.HYBRID)与时间序列命令(TS.MGET、TS.MRANGE、TS.MREVRANGE、TS.QUERYINDEX)可能返回部分结果或重复结果。依赖这些命令做精确去重或分页的业务,要按「迁移窗口内结果可能不完整」来设计。

FT.HYBRID 相关还有几处缺口:FT.PROFILE、FT.EXPLAIN、FT.EXPLAINCLI 不包含 FT.HYBRID 选项;FT.HYBRID 的指标不在 FT.INFO 和 INFO 中显示;若干选项(EXPLAINSCORE、SHARD_K_RATIO、YIELD_DISTANCE_AS、WITHCURSOR)尚不可用;COMBINE 之后用 FILTER 做后置过滤目前也不支持。

8.4 的其他相关变更

  • SET 扩展 IFEQ / IFNE / IFDEQ / IFDNE,可用于 compare-and-set;另有 DELEX / DIGEST、MSETEX(多 key 原子写 + TTL)、XREADGROUP CLAIM min-idle-time。
  • AOF 尾部损坏自动修复参数 aof-load-corrupt-tail-max-size。
  • lookahead 默认 16。
  • search-default-scorer 默认 BM25STD;新增 search-on-oom、search-io-threads。

什么时候仍然挑业务低峰

ASM 消掉的是「迁移过程中命令行为异常」这一类问题,并没有消掉迁移本身的成本:整槽复制会占用源端和目标端的 CPU、网络与目标端内存,大槽尤其明显;搜索与时间序列命令在迁移期间仍可能给出部分或重复结果。因此以下几种情况仍建议放到业务低峰执行:

  • 槽内 key 数量大或单 key 体积大,复制阶段的内存与网络峰值不可忽视;
  • 业务强依赖 FT.SEARCH、FT.AGGREGATE、FT.CURSOR、FT.HYBRID 或 TS.* 的结果完整性,无法容忍迁移窗口内的部分结果与重复;
  • 目标节点内存余量接近临界值,或副本延迟本身已经偏高,需要留出人工介入的时间;
  • 集群同时在跑其他变更(版本升级、扩缩容),不希望两件事的观察窗口重叠。

反之,小槽、纯 KV 读写、目标端资源充足的场景,ASM 已经把迁移窗口压缩到可以随时执行的程度。

复制全文 生成海报 Redis 集群 运维

推荐文章

程序员茄子在线接单