Redisson集群故障转移中的节点发现机制问题分析

问题背景

在使用Redisson 3.30.0连接Redis 6.2.14集群环境时，当集群发生主从切换（failover）后，客户端出现了节点未发现的异常。具体表现为：当原6379端口的master节点故障恢复并执行手动故障转移后，虽然集群状态显示正常，但Redisson客户端仍抛出"Node hasn't been discovered yet"错误。

技术细节分析

异常现象解读

错误信息中提到的关键点是MOVED重定向和节点发现失败。在Redis集群中，当客户端请求的key不在当前节点时，节点会返回MOVED响应，告知客户端正确的节点地址。Redisson客户端需要能够及时感知集群拓扑变化，才能正确处理这些重定向请求。

配置参数影响

从提供的配置可以看到几个关键参数：

• scanInterval: 1000ms（集群拓扑扫描间隔）
• retryAttempts: 5（操作重试次数）
• retryInterval: 100ms（重试间隔）

在故障转移场景下，这些参数的设置可能不足以保证客户端及时获取最新的集群拓扑信息。

解决方案

参数优化建议

1. 增加重试参数：

   • 将retryAttempts提高到10-20次
   • 将retryInterval增加到500-1000ms

2. 调整集群扫描间隔：

   • 在故障转移频繁的环境，可适当降低scanInterval至500ms

3. 连接池优化：

   • 确保masterConnectionPoolSize和slaveConnectionPoolSize足够大，避免连接耗尽

配置调整示例

clusterServersConfig:
  retryAttempts: 10
  retryInterval: 500
  scanInterval: 500
  # 其他保持原样

深入原理

Redisson的集群拓扑更新机制依赖于定时扫描（scanInterval）和MOVED/ASK响应。当发生故障转移时：

1. 客户端首次请求可能被重定向到新节点
2. 如果此时新节点尚未被客户端发现，就会抛出所述异常
3. 合理的重试参数给客户端留出足够时间完成拓扑更新

最佳实践建议

1. 生产环境中建议进行故障转移演练，测试不同参数下的恢复时间
2. 监控Redisson的拓扑更新日志，了解集群变化响应速度
3. 考虑使用更高版本的Redisson，新版可能优化了故障转移处理逻辑
4. 在应用启动时增加健康检查，确保集群拓扑已完全加载

通过以上调整和优化，可以有效解决Redisson在Redis集群故障转移后出现的节点发现问题，提高系统的稳定性和可用性。