Redisson集群扩容后数据读取异常问题分析与解决

问题现象

在使用Redisson客户端连接Redis集群时，当集群从3主3从扩容到4主4从后，出现了部分已存储数据读取为null的情况。具体表现为：

1. 扩容前集群节点为6381-6386端口
2. 扩容后新增了6387、6388节点
3. 通过Redisson客户端读取数据时，部分key返回null值
4. 直接连接Redis服务端查询这些key时，数据实际存在
5. 重启应用无法解决问题
6. 重新写入数据后，问题依然存在

技术背景

Redis Cluster采用哈希槽(16384个槽)的方式分配数据。当集群扩容时：

1. 新增节点会从现有节点中迁移部分哈希槽
2. 客户端需要感知新的集群拓扑结构
3. 客户端需要更新本地缓存的槽位-节点映射关系

Redisson作为Redis的Java客户端，需要正确处理集群拓扑变化，才能确保数据访问的正确性。

问题原因分析

根据现象描述，可以推断问题可能出在以下几个方面：

1. 拓扑刷新不及时：Redisson客户端可能没有及时获取最新的集群拓扑信息，导致部分请求仍被发送到旧的节点。

2. 槽位迁移过程中的一致性：在槽位迁移过程中，可能存在短暂的数据不一致窗口期。

3. 客户端缓存机制：Redisson的本地缓存可能没有正确处理槽位重新分配后的失效逻辑。

4. 连接池问题：连接池中可能保留了旧的连接，这些连接没有感知到集群拓扑变化。

解决方案

1. 检查拓扑刷新配置

确保Redisson配置了合理的集群拓扑刷新参数：

Config config = new Config();
config.useClusterServers()
    .setScanInterval(2000) // 集群拓扑扫描间隔(毫秒)
    .setSlaveConnectionMinimumIdleSize(1)
    .setMasterConnectionMinimumIdleSize(1);

建议将scanInterval设置为适当的值(如2000-5000毫秒)，确保及时获取集群变化。

2. 验证集群状态

在扩容完成后，应检查集群状态是否健康：

1. 使用CLUSTER INFO命令确认所有槽位都已分配
2. 使用CLUSTER NODES命令确认所有节点状态正常
3. 检查槽位迁移是否已完成

3. 客户端重启策略

在集群扩容后，建议：

1. 重启所有客户端应用，确保建立全新的连接
2. 或者实现优雅的重连机制，强制刷新本地缓存

4. 数据访问重试机制

在代码中实现重试逻辑，处理可能的暂时性访问失败：

public String getWithRetry(String key, int retryTimes) {
    for (int i = 0; i < retryTimes; i++) {
        try {
            String value = redisTemplate.opsForValue().get(key);
            if (value != null) {
                return value;
            }
            Thread.sleep(100);
        } catch (Exception e) {
            // 处理异常
        }
    }
    return null;
}

最佳实践建议

1. 扩容操作规范：

   • 在业务低峰期执行扩容
   • 监控槽位迁移进度
   • 验证数据完整性

2. 客户端配置优化：

   • 合理设置拓扑刷新间隔
   • 配置连接池大小
   • 启用读写分离(如适用)

3. 应用层容错设计：

   • 实现重试机制
   • 添加降级处理
   • 监控数据访问异常

总结

Redis集群扩容后出现数据读取异常，通常是由于客户端未能及时感知集群拓扑变化所致。通过合理配置Redisson的集群拓扑刷新参数、验证集群状态完整性以及在应用层实现适当的容错机制，可以有效解决这类问题。对于关键业务系统，建议在扩容前后进行全面验证，确保数据访问的正确性和一致性。