Redis Cluster 迁移槽位时的客户端重试策略

Redis Cluster 迁移 hash slot 时，客户端最容易犯的错误，是把 -ASK 和 -MOVED 都当成“换一个节点再试”。正确做法是：ASK 只重试当前命令，并先发送一次 ASKING；MOVED 才表示槽位归属已经改变，应该刷新本地槽位映射。重试还必须有上限，不能让一次迁移把业务请求变成无限递归。

官方资料：https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/

我在梳理集群扩容和重分片方案时，真正需要解决的不是“客户端能不能重试”，而是重试之后本地拓扑要不要改变、写命令会不会重复执行，以及迁移尚未结束时如何避免把所有请求都压到目标节点。下面按这三个问题拆开。

先把一次槽位迁移拆成两个节点状态

Redis Cluster 把数据分到 16384 个 hash slot。重分片时，管理员会把某个 slot 从源主节点 A 移到目标主节点 B。迁移过程不是瞬间完成的，A 和 B 会短暂处于不同的角色：

• A 对该 slot 处于 MIGRATING 状态，仍然持有尚未搬走的键。
• B 对该 slot 处于 IMPORTING 状态，等待接收迁移过来的键。
• 已有键通常仍在 A；当请求的键在 A 不存在时，A 才会把这一次请求用 ASK 引向 B。

这解释了为什么 ASK 不能被当成永久路由：同一个 slot 里的不同键，可能仍然分散在 A 和 B。客户端如果看到第一次 ASK 就把整个 slot 改指向 B，后续访问仍在 A 的键时，反而会多出一次来回重定向。

ASK 只处理当前命令，不提前改槽位表

-ASK slot host:port 表示“这一次请求请去另一个节点试试”。客户端接到它后，需要按顺序向目标节点发送 ASKING 和原命令。ASKING 只为下一次请求打开一次性许可，不能被理解成把目标节点设成新的永久 owner。

因此，ASK 的处理逻辑应该有三个明确动作：

1. 保留当前 slot 到 A 的本地映射。
2. 在同一条目标连接上先发送 ASKING，再发送原始命令。
3. 只把这一次请求的结果返回给调用方，后续请求仍按原槽位表选择节点。

如果客户端库把 ASK 当成 MOVED 来刷新全量拓扑，迁移期间会不断抖动本地路由；如果只发送原命令而漏掉 ASKING，B 处于 IMPORTING 时又可能把请求继续重定向回真实 owner。

MOVED 才是刷新槽位映射的信号

-MOVED slot host:port 的语义不同：Redis 认为该 slot 已经由另一个节点永久服务。客户端可以更新单个 slot，也可以通过 CLUSTER SHARDS 或兼容场景下的 CLUSTER SLOTS 重新取得完整映射。工程上我更倾向于在 MOVED 后刷新一份完整拓扑，因为一次故障转移或重分片往往同时影响一段 slot，而不是只有报错中的一个数字。

给重试循环设置统一上限

重定向处理最好是一个有计数器的循环，而不是在异常回调里递归调用自身。下面的 Go 代码是客户端适配层的简化骨架，重点是把 ASK、MOVED 和普通网络错误分开；真实项目中应把错误类型替换成所用 Redis 客户端的具体类型。

type RedirectKind int

const (
	RedirectNone RedirectKind = iota
	RedirectAsk
	RedirectMoved
)

type RedirectError struct {
	Kind RedirectKind
	Slot int
	Addr string
}

func (e *RedirectError) Error() string {
	return fmt.Sprintf("redis redirect kind=%d slot=%d addr=%s", e.Kind, e.Slot, e.Addr)
}

func executeWithRedirect(ctx context.Context, cmd Command, maxRedirects int) (Reply, error) {
	// 限制重定向次数，避免迁移异常或拓扑震荡造成无限重试。
	for attempt := 0; attempt  node 映射。
			target := nodeForAddress(redirect.Addr)
			if err := target.Asking(ctx); err != nil {
				return nil, err
			}
			return target.Do(ctx, cmd)
		case RedirectMoved:
			// MOVED 表示拓扑已变化，先刷新映射，再让循环重新路由。
			refreshSlotMap(ctx, redirect.Slot, redirect.Addr)
		default:
			return nil, err
		}
	}

	return nil, fmt.Errorf("redis redirect retry limit exceeded: %d", maxRedirects)

示例里的 ASK 分支直接结束当前命令，是为了强调“只重试一次当前请求”。生产客户端可能会把 ASK 后的执行也纳入更大的重试预算，但预算必须是显式的，并且要防止 ASK 与 MOVED 交替出现时把次数无限叠加。

多键命令和写命令要单独设边界

槽位迁移策略不能脱离命令语义。Redis Cluster 对多键命令有同槽约束；如果键不在同一个 slot，客户端通常会在真正执行前遇到 CROSSSLOT，而不是靠 ASK 或 MOVED 解决。使用 hash tag 让相关键落到同一个 slot，可以让多键操作拥有明确的路由目标，但也会把热点集中到一个 slot，不能为了绕过重试问题而无条件添加相同的花括号标记。

写命令还要考虑重试是否可能重复产生副作用：

• GET、读取类命令通常可以安全地重新发送，但仍要受总超时约束。
• SET、带固定值的更新如果具备幂等语义，重试风险相对可控。
• INCR、追加、发布消息或调用外部副作用时，不能仅因为连接断开就断言“服务端没有执行”，需要业务幂等键、去重记录或明确的失败语义。

func sameSlotKeys(keys []string) error {
	if len(keys) 

这里的判断仍然需要结合具体客户端库和业务协议。不要把“Redis 返回了错误”简化为“Redis 一定没执行”，尤其是连接在服务端回复前断开时，客户端无法仅凭本地异常知道命令的最终状态。

用运行信号判断迁移是否正在收敛

一次短暂的 ASK 不一定是故障，它可能只是迁移窗口中的正常信号；真正值得警惕的是 ASK 比例长时间不降、MOVED 反复刷新同一批 slot，或者单条请求的 redirect 次数接近上限。可以把下面几项放进客户端指标：

• 按命令和 slot 统计 ASK、MOVED 次数。
• 统计每次请求的重定向次数、总耗时和最终结果。
• 记录槽位表刷新耗时，以及刷新后仍然收到 MOVED 的次数。
• 把超过重试上限的命令单独打点，区分读、幂等写和非幂等写。

如果只是扩容或重分片，运维侧还要关注迁移批次、big key 和目标节点的延迟。Redis 官方扩容文档明确把 resharding 定义为移动 hash slot；客户端策略解决的是请求如何穿过过渡状态，并不能替代对迁移速度和数据热点的控制。

我会采用的最小决策表

最终可以把策略压缩成一句话：ASK 是“这一次去问目标节点”，MOVED 是“以后把这个 slot 记到目标节点”。客户端只要把这两个状态分开，配合有限重试、同槽检查和写操作幂等性，槽位迁移就不会轻易演变成请求风暴。

常见追问

收到 ASK 后要不要刷新整个集群拓扑？

通常不要。ASK 只代表当前命令的临时转发，迁移完成前旧节点仍可能持有同一 slot 的其它键。应先发送 ASKING，再重试当前命令。

MOVED 只更新一个 slot 可以吗？

可以，但重分片或故障转移常常同时改变多个 slot。若客户端库支持，收到 MOVED 后刷新完整 slot map 通常更快恢复稳定路由。

为什么 ASKING 不能在普通连接上提前发送？

ASKING 是目标节点连接上的一次性状态。它必须紧挨着被重定向的命令发送；提前发送或复用到另一条连接，都可能让许可与实际命令错位。