记录一下那天晚上的排查过程。Redis 6.2 的三主三从集群加了一组节点做扩容，槽迁移完成后部分 key 开始报 MOVED 1006 10.0.6.13:6379，客户端一直重试同一个地址，业务侧表现为间歇性失败。
刚开始盯着「有些客户端版本根本不支持集群模式，只是把节点当单机连」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。客户端把槽位映射缓存在本地，扩容后没有主动刷新，仍然按旧表发请求。还有一种是迁移过程中新槽位在主从切换，客户端不会处理 ASK 重定向。
还有一种情况，连接串里只写了一个节点地址，那个节点宕掉就全盘不可用。
第一件事是确认集群状态与槽分布
redis-cli -c -h 10.0.6.11 -p 6379 cluster info | grep -E 'cluster_state|known_nodes'再往下看每个节点的槽区间
redis-cli -c -h 10.0.6.11 -p 6379 cluster nodes随后用会跟随重定向的客户端复测同一个 key
redis-cli -c -p 6379 get user:1等前面都确认过，再确认应用使用的客户端版本
grep -rn 'predis\|redis-plus' /www/api/composer.json改完先别撤，确认这几项。同一个 key 连续读取都返回结果且不再抛 MOVED，应用日志里重定向报错归零，集群所有节点的槽覆盖完整。
补一句。MOVED 是长期有效的槽变更，ASK 是迁移中的临时跳转，客户端两种都要处理，只忽略报错会读到错的数据。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。