Redis Cluster 客户端怎样处理槽位迁移

Redis Cluster 客户端遇到槽位迁移时，关键不是“收到错误就重试”，而是先区分 MOVED 和 ASK：前者表示槽位的长期归属已经变了，客户端应更新本地拓扑；后者只表示迁移窗口中的本次请求需要临时转发，不能立刻改写槽位表。

官方地址：https://redis.io/

实用处理顺序是：启动时加载槽位映射；遇到 MOVED 时重试当前命令并刷新拓扑；遇到 ASK 时在目标连接上先发 ASKING，再发送当前命令，但保留原有槽位映射。生产代码还要限制重定向次数，并把刷新和错误类型记入指标。

先把槽位位置和客户端缓存分开

Redis Cluster 将键映射到 16384 个 hash slot，客户端通常维护一份“槽位范围对应节点”的本地表。它不必每次请求都重新拉取整张表，但启动时需要初始化；收到 MOVED 时也要把这份表当成可变缓存，而不是永久配置。

旧客户端常通过 CLUSTER SLOTS 获取范围、节点地址和节点 ID。Redis 文档说明该命令从 7.0 起已标记为弃用，新客户端可以优先考虑 CLUSTER SHARDS；无论采用哪个命令，客户端都应把返回结果转换成自己的槽位查找结构，并保留刷新入口。

# 启动检查：读取当前节点看到的槽位范围和目标节点信息
redis-cli -h redis-a -p 6379 CLUSTER SLOTS

# Redis 7 及以上的新客户端可用更完整的分片视图
redis-cli -h redis-a -p 6379 CLUSTER SHARDS

MOVED 表示槽位需要长期重绑定

客户端把命令发给错误节点时，Redis 可能返回类似 -MOVED 5798 10.0.0.12:6381 的重定向。它表达的是：这个槽位当前应该由另一个节点负责。当前命令要到新地址重试，后续同一槽位的请求也应优先走新地址。

我在接入 Cluster 客户端时，最容易遗漏的是“重试成功”和“拓扑修正”必须同时发生。只把当前命令发到目标节点，会让本地缓存继续指向旧节点；只更新缓存而不重试，又会让当前请求平白失败。更稳妥的逻辑是把两件事放在同一条重定向处理路径里：

// MOVED 表示槽位归属已经改变：当前命令重试，后续请求更新路由。
func handleMoved(slot int, endpoint string, command Command) (Reply, error) {
	// 先更新受影响槽位，避免下一次请求继续命中旧节点。
	topology.Set(slot, endpoint)
	// 当前命令仍要在新节点重试，并沿用原始参数和超时边界。
	return topology.Client(endpoint).Do(command)
}

实际客户端往往会在收到一次 MOVED 后重新拉取完整槽位表，而不是只更新一个槽位。原因是一次故障切换或批量迁移可能同时改变一组槽位；完整刷新能减少“局部修正后仍然频繁重定向”的窗口。

ASK 只影响这一次迁移请求

槽位处于迁移中时，源节点可能返回 -ASK 5798 10.0.0.12:6381。这并不等价于“槽位已经永久属于目标节点”。迁移期间，某个键可能还在源节点，另一个键已经被搬到目标节点，因此 Redis 要求客户端只把当前请求临时送过去。

临时请求必须在同一条目标连接上先发送 ASKING，紧接着发送原始命令；本次处理结束后，客户端仍按旧槽位表路由后续请求。把 ASK 当成 MOVED 处理，会让客户端过早改表，在迁移尚未完成时制造更多来回重定向。

// ASK 是一次性授权：只改变当前连接上的下一次请求，不改本地槽位表。
func handleAsk(endpoint string, command Command) (Reply, error) {
	conn, err := pool.Get(endpoint)
	if err != nil {
		return nil, err
	}
	defer pool.Put(conn)
	// ASKING 与原命令必须使用同一连接，授权只对下一条命令生效。
	if _, err = conn.Do("ASKING"); err != nil {
		return nil, err
	}
	return conn.Do(command)
}

用完整刷新处理批量迁移

遇到 MOVED 后，客户端可以只修正一个槽位，也可以重新获取整张槽位表。对生产客户端来说，完整刷新通常更容易保持一致：刷新线程拿到新的范围和节点列表后，再一次性替换本地快照；请求线程读取旧快照或新快照都可以，但不应看到半张表。

刷新动作本身也要去重。多个请求同时收到 MOVED 时，不要让每个请求都建立一次拓扑连接；可以使用单飞锁、版本号或短暂的刷新协程，让第一个请求触发刷新，其余请求等待或复用结果。刷新失败时，当前请求仍应保留明确的重试上限，并把失败原因交给上层。

# 伪代码：并发请求共享一次拓扑刷新，避免放大控制面压力
if redirect == MOVED {
    # 第一个请求触发全量刷新，其余请求复用同一个刷新结果
    topology.RefreshOnce()
    # 刷新后按新快照重试当前命令
    retry(command, redirect_limit)
}
if redirect == ASK {
    # ASK 不触发槽位表替换，只在目标连接上先发 ASKING
    send_asking_then_command(target, command)
}

上线前把重定向边界写死

还应给单个命令设置重定向次数上限，记录 MOVED、ASK、拓扑刷新失败和最终失败的计数，并避免多键命令跨槽位。使用 hash tag 让相关键落在同一槽位，只能解决多键命令的键分布问题，不能替代 MOVED/ASK 处理。

我最终保留的判断

槽位迁移并不要求业务代码理解 Redis 内部的每一步搬迁过程，但客户端必须理解两种重定向的语义：MOVED 是新的长期路由提示，ASK 是当前请求的临时许可。把两者分开后，启动加载、全量刷新、重试上限和观测指标就有了清晰边界。

相关问题

收到 MOVED 后只改一个槽位可以吗？

可以作为快速修正，但批量迁移或故障切换可能同时影响多个槽位。更稳妥的客户端通常会在合适的并发控制下重新获取完整拓扑。

ASKING 为什么必须和原命令共用连接？

ASKING 设置的是当前客户端连接上的一次性标记。如果换了连接，目标节点收不到这次授权，原命令仍可能被重定向回正常的槽位归属。

CLUSTER SLOTS 还能继续用吗？

Redis 文档将它标记为弃用，并建议新实现考虑 CLUSTER SHARDS。是否替换还要看客户端库的支持范围，但槽位刷新这一处理边界不变。