四种重定向与错误
集群客户端必须理解四类响应：MOVED 表示键永久属于另一个节点，客户端应更新本地路由表；ASK 表示槽正在迁移，本次请求要先向目标节点发送 ASKING 再重试，但不更新路由；CROSSSLOT 表示一条命令涉及的多个键不在同一个槽；CLUSTERDOWN 表示集群整体不可用。它们的处理方式完全不同，混用就会产生难以复现的随机失败。
基本信息
| MOVED | 键的槽归属已确定在其它节点，更新路由并重试 |
|---|---|
| ASK | 槽正在迁移中，临时问询目标节点，不更新路由 |
| CROSSSLOT | 一条命令的多个键不在同一槽 |
| CLUSTERDOWN | 集群不可用，常见原因是槽未全覆盖或多数派丢失 |
| 前提 | 必须使用集群感知客户端，不能直连单节点当单机用 |
典型使用场景
- 排查应用侧「偶尔失败、重试又成功」的随机错误
- 搬槽期间观察 ASK 重定向比例与延迟变化
- 批量命令报 CROSSSLOT 时确定键设计怎么改
- 集群整体报错时快速区分是网络问题还是槽问题
- 客户端选型评审，确认重定向处理能力
手工验证
手工验证
redis-cli -c -p 6379 GET user:1001 # -c 让工具自动跟随重定向
redis-cli -p 6379 CLUSTER KEYSLOT user:1001 # 查键落在哪个槽
redis-cli -c -p 6379 MGET user:1 user:2 # 不同槽会报 CROSSSLOT
redis-cli -c -p 6379 MSET user:{1}:a 1 user:{1}:b 2 # hash tag 固定到同槽
redis-cli -p 6379 CLUSTER INFO | grep -E "state|slots_assigned|slots_fail"错误与处理方式
| 返回 | 含义 | 正确处理 |
|---|---|---|
| MOVED | 键属于其它槽或节点 | 更新本地路由表并重试到目标节点 |
| ASK | 槽正在迁移中 | 本次先发 ASKING 再重试，不更新路由 |
| CROSSSLOT | 多个键不在同一槽 | 用 hash tag 或者拆成多条命令 |
| CLUSTERDOWN | 集群不可用 | 检查槽覆盖与多数派是否正常 |
| TRYAGAIN | 多键命令涉及正在迁移的多个槽 | 短暂延迟后重试即可 |
客户端不支持重定向就会出现随机失败：选型阶段必须确认它是集群感知客户端，例如 Java 的 Lettuce、Jedis 集群模式与 Python 的 redis-py 集群客户端。
把 ASK 当 MOVED 处理会错误地更新路由表，迁移期间的请求持续打到错误节点，表现为「偶尔失败、重试有时成功」这种极难定位的现象。
键设计要提前考虑槽归属：大括号里的内容决定槽（hash tag），把需要一起操作的键固定在同一槽，是避免 CROSSSLOT 的根本手段。