Redis 集群迁移期间出现 TRYAGAIN 报错，通常表示集群正在处理槽位迁移且暂时无法服务该请求，客户端应实施重试机制并等待迁移完成。
先说结论：TRYAGAIN 是集群中间状态的临时响应，并非数据丢失，核心处理方式是客户端重试配合运维侧确认迁移进度。
- 先确认：检查集群状态是否为 ok，确认是否有槽位正在 MIGRATING 或 IMPORTING。
- 先处理：客户端启用自动重试逻辑，运维侧暂停非紧急的写操作直至迁移结束。
- 再验证：观察报错频率是否随迁移完成而消失，确认集群状态稳定。
命令速用版
# 查看集群整体状态，确认 cluster_state 是否为 ok
redis-cli -c -p 6379 CLUSTER INFO
# 查看节点槽位迁移状态，寻找 MIGRATING 或 IMPORTING 标记
redis-cli -c -p 6379 CLUSTER NODES
# 查看槽位分布，确认是否有槽位处于不一致状态
redis-cli -c -p 6379 CLUSTER SLOTS为什么会这样
TRYAGAIN 报错的本质是集群在槽位迁移期间处于临时不可用状态。当 Redis 集群执行 resharding 或 slot migration 时，部分槽位会进入 MIGRATING（迁出）或 IMPORTING（迁入）状态，在此期间若请求命中这些槽位且集群配置未完全同步，节点会返回 TRYAGAIN 告知客户端稍后重试。公开资料中没有看到可靠的量化数据说明具体触发概率，但该行为符合 Redis Cluster 协议规范。
分步处理
步骤 1：确认集群迁移状态
适用场景：收到 TRYAGAIN 报错初期。
操作动作：执行 CLUSTER INFO 命令，检查 cluster_state 字段。
验证结果：若 cluster_state 为 fail 或 cluster_known_nodes 数量异常，需优先修复节点通信。
风险边界：不要强制重启节点，否则可能加剧槽位不一致。
步骤 2：检查具体槽位迁移进度
适用场景：集群状态为 ok 但仍有报错。
操作动作：执行 CLUSTER NODES 命令，筛选包含 migrating- 或 importing- 的行。
验证结果：若存在未完成的迁移任务，等待迁移自然结束或手动完成迁移。
风险边界：迁移期间避免执行跨槽位的多 key 命令（如 MGET 涉及不同槽）。
步骤 3：调整客户端重试策略
适用场景：业务侧无法立即停止写入。
操作动作：在客户端代码中捕获 TRYAGAIN 异常，增加指数退避重试机制。
验证结果：业务日志中 TRYAGAIN 错误率逐渐下降至零。
风险边界：重试次数过多可能增加集群负载，需设置上限。
怎么验证是否生效
执行 CLUSTER INFO 命令，确认 cluster_state 显示为 ok 且 cluster_slots_assigned 与 cluster_slots_ok 数值一致。观察应用端监控日志，TRYAGAIN 错误计数停止增长。若正在迁移，CLUSTER NODES 输出中不应再出现持续不变的 migrating 标记。
常见坑
1. 误以为是数据丢失：TRYAGAIN 仅表示请求暂时无法处理，数据未丢失，无需回滚数据。
2. 客户端无重试逻辑：部分老旧客户端库不自动处理集群重定向错误，需手动升级或配置。
3. 迁移期间执行多 key 操作：Redis 集群限制多 key 命令必须在同一槽位，迁移期间更容易触发错误。
4. 忽略网络抖动：迁移期间流量增大，网络波动可能被误判为集群错误，需结合网络监控排查。
常见问题
TRYAGAIN 报错会导致数据丢失吗？
不会。TRYAGAIN 是协议层的临时拒绝响应，请求未被执行，数据保持一致。
迁移完成后报错会自动消失吗？
会。只要槽位迁移结束且集群状态稳定，不再命中中间状态，报错将停止。
需要手动重启 Redis 节点吗？
不需要。重启可能中断迁移过程，除非节点进程已崩溃，否则应等待迁移完成。
参考来源
- Redis Official Documentation - Cluster Spec, https://redis.io/docs/latest/develop/interact/programmability/cluster-spec/
- Redis Official Documentation - Cluster Tutorial, https://redis.io/docs/latest/develop/interact/programmability/cluster/