Redisson集群模式下移除从节点后的持续重连问题分析

问题背景

在使用Redisson客户端连接Redis集群时，当集群配置发生变化（特别是从节点被移除并替换）时，Redisson客户端会出现持续尝试重连已移除从节点的问题。这种情况主要发生在Redis集群模式下，配置了3主3从的架构，并且Redisson使用了默认配置。

问题现象

当Redis集群中的一个从节点被移除并替换为新节点后，虽然DNS解析能够立即反映IP地址的变化，但Redisson客户端仍会持续尝试重新连接已被移除的从节点。值得注意的是，相同操作在主节点上不会出现此问题。

技术分析

问题根源

1. 连接管理机制：Redisson在默认配置下（BaseMasterSlaveServersConfig.isSlaveNotUsed() == true），从节点连接的管理存在缺陷。

2. 连接保持：Redisson会选择一个从节点发送"cluster nodes"命令，并将该连接保持在MasterSlaveConnectionManager#nodeConnections中。

3. 节点变更处理：当该从节点被移除并替换后，虽然DNS解析更新了，但ConnectionWatchdog会持续尝试重连已被移除的从节点。

4. 检查机制缺陷：在下次调用scheduleClusterChangeCheck()时，Redisson无法看到已移除从节点的IP，因此不会主动连接该节点，同时也失去了关闭MasterSlaveConnectionManager#nodeConnections中保持的连接的机会。

修复过程

开发团队在收到问题报告后进行了多次修复尝试：

1. 初步修复：尝试通过修改连接断开逻辑来解决问题，但未能完全解决。

2. 深入修复：发现当isSlaveNotUsed()为true时，MasterSlaveEntry的实际类型是SingleEntry，导致getEntry()方法对于从节点地址总是返回null，进而使MasterSlaveEntry.slaveDown()总是返回false。

3. 最终解决方案：调整了disconnectUri()方法的调用位置，将其移出条件判断语句，确保在节点变更时能够正确断开连接。

解决方案

对于遇到此问题的用户，建议：

1. 升级到已修复该问题的Redisson版本（3.26.1及更高版本）。

2. 如果仍遇到问题，可以检查配置中关于从节点使用的设置，确保符合实际需求。

3. 在集群节点变更时，监控Redisson客户端的连接行为，确保没有异常的重连尝试。

总结

这个问题揭示了分布式系统中客户端连接管理的重要性，特别是在集群配置动态变化的场景下。Redisson团队通过多次迭代修复，最终解决了这个复杂的连接管理问题，为Redis集群的稳定运行提供了更好的支持。对于开发者而言，理解这类问题的根源有助于更好地设计和实现分布式系统的客户端连接管理机制。