场景二：脑裂（Split Brain） 网络分区导致原 Master 与哨兵/集群失联，哨兵误判为 Master 宕机并选举了新 Master。此时存在两个 Master，客户端可能继续往原 Master 写数据（如果网络还通的话）。等网络恢复后，原 Master 变成 Slave，所有在"双 Master"期间写入原 Master 的数据都会被丢弃（Slave 要同步新 Master 的数据）。

可以限制的数据丢失量：

# redis.conf 主从复制配置
# Master 要求至少 1 个 Slave 在线才接受写操作
min-replicas-to-write 1
# 要求 Slave 的复制延迟不超过 10 秒
min-replicas-max-lag 10

这个配置的含义：如果所有 Slave 的复制延迟都超过 10 秒（说明 Master 可能已经孤立），Master 停止接受写操作，返回错误。这样可以避免脑裂期间数据大量写入即将被丢弃的情况。

代价是：Slave 都挂了或网络全断时，Master 也无法写入，可用性降低。

Cluster 的数据一致性

Cluster 同样是异步复制，每个分片的主从复制延迟问题与单主从模式相同。此外，Cluster 还有一个特殊问题：slot 迁移期间的数据一致性。

当扩容时（新增节点，需要迁移 slot），迁移过程中同一个 key 可能在源节点和目标节点都有数据，客户端的请求可能路由到任一节点，读到不同的值。Cluster 使用 ASKING 命令来解决这个问题，但客户端需要正确处理 MOVED 和 ASK 响应。

三、完整代码实现

哨兵模式配置

spring:
  data:
    redis:
      sentinel:
        master: mymaster              # 主节点名称（与 sentinel.conf 一致）
        nodes:
          - 127.0.0.1:26379
          - 127.0.0.1:26380
          - 127.0.0.1:26381
        password: sentinel-password   # 哨兵密码
      password: redis-password        # Redis 密码
      lettuce:
        pool:
          max-active: 64
          min-idle: 10
          max-wait: 3000ms
        # 哨兵模式下，读操作可以走 Slave
        sentinel:
          read-from: REPLICA_PREFERRED  # 优先读 Slave，Slave 不可用则读 Master

Cluster 模式配置

spring:
  data:
    redis:
      cluster:
        nodes:
          - 127.0.0.1:7001
          - 127.0.0.1:7002
          - 127.0.0.1:7003
          - 127.0.0.1:7004
          - 127.0.0.1:7005
          - 127.0.0.1:7006
        max-redirects: 3              # MOVED 重定向最大次数
      password: redis-password
      lettuce:
        pool:
          max-active: 64
        cluster:
          refresh:
            adaptive: true            # 自适应刷新集群拓扑（推荐）
            period: 60s               # 定期刷新间隔

连接池与故障处理

@Configuration
public class RedisConfig {

    @Bean
    public LettuceConnectionFactory lettuceConnectionFactory(
            RedisProperties redisProperties) {

        // Cluster 模式配置
        RedisClusterConfiguration clusterConfig =
            new RedisClusterConfiguration(redisProperties.getCluster().getNodes());
        clusterConfig.setPassword(RedisPassword.of(redisProperties.getPassword()));
        clusterConfig.setMaxRedirects(3);

        // Lettuce 连接池
        GenericObjectPoolConfig<StatefulRedisClusterConnection<String, String>> poolConfig =
            new GenericObjectPoolConfig<>();
        poolConfig.setMaxTotal(64);
        poolConfig.setMinIdle(10);
        poolConfig.setMaxWaitMillis(3000);
        poolConfig.setTestOnBorrow(true);  // 获取连接时校验可用性

        LettucePoolingClientConfiguration clientConfig =
            LettucePoolingClientConfiguration.builder()
                .poolConfig(poolConfig)
                .commandTimeout(Duration.ofMillis(3000))
                // Cluster 拓扑自动刷新
                .clientOptions(ClusterClientOptions.builder()
                    .topologyRefreshOptions(
                        ClusterTopologyRefreshOptions.builder()
                            .enableAdaptiveRefreshTrigger(
                                ClusterTopologyRefreshOptions.RefreshTrigger.MOVED_REDIRECT,
                                ClusterTopologyRefreshOptions.RefreshTrigger.PERSISTENT_RECONNECTS)
                            .adaptiveRefreshTriggersTimeout(Duration.ofSeconds(30))
                            .enablePeriodicRefresh(Duration.ofMinutes(1))
                            .build())
                    .build())
                .build();

        return new LettuceConnectionFactory(clusterConfig, clientConfig);
    }
}

Cluster 模式下的多 key 操作

Cluster 模式不支持跨 slot 的多 key 操作（MGET、MSET、MULTI 等），需要特殊处理：

@Service
@Slf4j
public class ClusterSafeRedisService {

    @Autowired
    private StringRedisTemplate redisTemplate;

    /**
     * Cluster 安全的批量获取（按 slot 分组）
     */
    public Map<String, String> mgetSafe(List<String> keys) {
        // 按 slot 分组
        Map<Integer, List<String>> slotGroups = keys.stream()
            .collect(Collectors.groupingBy(key ->
                JedisClusterCRC16.getSlot(key) // 计算 slot
            ));

        Map<String, String> result = new HashMap<>();

        // 对每个 slot 组单独执行
        slotGroups.values().forEach(slotKeys -> {
            try {
                List<String> values = redisTemplate.opsForValue().multiGet(slotKeys);
                if (values != null) {
                    for (int i = 0; i < slotKeys.size(); i++) {
                        if (values.get(i) != null) {
                            result.put(slotKeys.get(i), values.get(i));
                        }
                    }
                }
            } catch (Exception e) {
                // 如果还是跨 slot，降级为单个查询
                log.warn("批量查询失败，降级为单查，keys={}", slotKeys);
                slotKeys.forEach(key -> {
                    String value = redisTemplate.opsForValue().get(key);
                    if (value != null) {
                        result.put(key, value);
                    }
                });
            }
        });

        return result;
    }

    /**
     * 使用 Hash Tag 强制多个 key 落在同一 slot
     * Hash Tag：key 中 {} 内的部分决定 slot
     * 例如：{user:1}:profile 和 {user:1}:orders 都落在 user:1 对应的 slot
     */
    public void setUserData(Long userId, String profile, String orders) {
        String profileKey = "{user:" + userId + "}:profile";
        String ordersKey = "{user:" + userId + "}:orders";

        // 使用 pipeline（同一 slot 可以 pipeline）
        redisTemplate.executePipelined((RedisCallback<Void>) connection -> {
            connection.set(profileKey.getBytes(), profile.getBytes());
            connection.set(ordersKey.getBytes(), orders.getBytes());
            return null;
        });
    }
}

主从切换的客户端恢复

@Component
@Slf4j
public class RedisSentinelFailoverHandler {

    @Autowired
    private LettuceConnectionFactory lettuceConnectionFactory;

    /**
     * 监听哨兵事件（Lettuce 提供了事件订阅机制）
     */
    @PostConstruct
    public void registerSentinelListener() {
        // Lettuce 的哨兵连接工厂
        if (lettuceConnectionFactory.getSentinelConfiguration() != null) {
            log.info("注册哨兵事件监听器");
            // Lettuce 会自动处理哨兵切换，这里主要做监控上报
        }
    }

    /**
     * 带重试的 Redis 操作（应对主从切换期间的短暂不可用）
     */
    @Retryable(
        retryFor = {RedisConnectionFailureException.class},
        maxAttempts = 3,
        backoff = @Backoff(delay = 500, multiplier = 2)
    )
    public String getWithRetry(String key) {
        return redisTemplate().opsForValue().get(key);
    }

    @Recover
    public String getRecovery(RedisConnectionFailureException e, String key) {
        log.error("Redis 连接失败，已达最大重试次数，key={}", key, e);
        return null; // 降级返回 null，业务层处理
    }

    @Autowired
    private StringRedisTemplate redisTemplate;

    private StringRedisTemplate redisTemplate() {
        return redisTemplate;
    }
}

四、生产选型建议

三种方案选型矩阵

场景	推荐方案	理由
单机开发	单节点	简单
读写比 7:3，数据 < 单节点上限	哨兵	自动 Failover，读写分离
数据量大（> 单节点上限）	Cluster	水平扩展
对数据丢失零容忍	不能只依赖 Redis	配合 DB 持久化
跨机房	哨兵（机房内）+ 跨机房同步	Cluster 跨机房延迟高

数据丢失容忍度

不论哪种方案，Redis 的异步复制本质上无法完全避免数据丢失（除非配置 wait 命令要求同步复制，但会大幅降低性能）。

生产建议：Redis 作为缓存时，可以接受数据丢失（重启后从 DB 重建即可）。Redis 作为持久化存储时（存储 Session、分布式锁等），需要配置 AOF 持久化 + min-replicas-to-write，并接受一定的可用性代价。

五、踩坑实录

坑一：开篇哨兵切换数据丢失的复盘

改进措施：

添加 min-replicas-to-write 1 + min-replicas-max-lag 10，限制 Master 孤立时继续写入。
对积分这类不能丢的业务数据，改用数据库存储，Redis 只做缓存加速。
监控 Redis 主从同步延迟（repl_backlog_active、repl_offset 的差值），超过 5 秒报警。

无论哪种方案，都要接受一个事实：Redis 不是强一致的持久化存储，异步复制意味着总有丢数据的可能。重要数据的最终权威来源应该是关系型数据库，Redis 只是加速缓存。

Redis集群方案对比：主从、哨兵、Cluster模式的数据一致性分析

Redis集群方案对比：主从、哨兵、Cluster模式的数据一致性分析

开篇故事

一、三种方案的架构对比

主从复制（Master-Slave）

哨兵模式（Sentinel）

Cluster 模式

二、数据一致性深度分析

主从复制的数据丢失场景