moved表示槽已永久迁移，客户端必须更新本地槽映射表，否则每次请求都重定向；ask表示槽正在迁移，需先发asking命令再执行原命令，且不更新映射。
Redis集群的MOVED/ASK重定向本身不增加延迟，但客户端处理不当会让单次请求变成多次往返，穿透延迟翻倍甚至更高。
MOVED错误触发后必须更新槽映射表，否则每次请求都重定向
客户端收到MOVED 1234 10.0.1.5:6379，说明槽1234已永久归属新节点。如果只重试本次请求、不更新本地slot→node映射，下一次对同一槽的请求仍会打到旧节点，再次触发MOVED——等于多出一次RTT（通常1~5ms）。
- 正确做法：解析地址后，把槽1234与
10.0.1.5:6379写入本地路由表，并持久化（比如存进内存map或带过期时间的缓存） - 常见错误：用完即弃，或仅更新临时变量，没同步到全局映射结构
- 影响：高并发下大量请求反复打错节点，集群入口节点CPU飙升，实际延迟从1ms变成6ms+
ASK错误必须前置ASKING命令，否则目标节点直接拒绝
收到ASK 1234 10.0.1.6:6379时，目标节点处于“导入中”状态，默认只服务自己负责的槽。不发ASKING就直接发GET key，目标节点会返回MOVED或ERR，导致二次重试。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须顺序执行：先
ASKING，再原命令（如GET key），不能合并成一条pipeline - 不能复用连接池里已有连接：新节点可能未配置密码/TLS，需按目标节点参数重建连接
- 典型坑：某些客户端在重试时漏掉
ASKING，或把ASKING和业务命令发到不同连接上
拓扑缓存过期策略比轮询更关键
靠定时调用CLUSTER SLOTS刷新路由表，不如用“懒更新+兜底过期”。因为迁移过程中CLUSTER SLOTS返回的是中间态，强行刷新反而让客户端路由分裂。
- 推荐方式：首次收到MOVED时更新对应槽；同时给整个映射表设5分钟软过期（非强制清除），超时后仅标记为“待验证”，下次命中该槽时再触发一次
CLUSTER SLOTS校验 - 避免高频轮询：每30秒拉一次
CLUSTER SLOTS，在扩缩容窗口期会导致大量无效解析和连接重建 - 注意
nodes.conf不可信：它是节点本地缓存，可能滞后数秒；真正权威的是当前节点返回的CLUSTER SLOTS响应
最易被忽略的一点：ASK场景下，源节点返回错误前已查过本地key，没查到才转向——这意味着你看到ASK时，key大概率真不在源节点了。但若客户端没走通ASK流程，就会误判为key不存在，掩盖了迁移中的数据一致性问题。
