Redis双机房容灾方案一、方案核心目标本方案针对Redis双机房部署场景，核心解决「机房级故障」下的数据安全与服务连

一、方案核心目标

本方案针对Redis双机房部署场景，核心解决「机房级故障」下的数据安全与服务连续性问题，明确两大核心目标，适配不同业务等级需求：

数据安全：确保任一机房完全故障（断电、断网、硬件瘫痪等）时，数据不丢失或仅丢失可接受范围内的少量数据（RPO≤5s，核心业务可优化至RPO≈0）；
服务可用：故障发生后，业务能快速切换至备用机房，恢复服务能力（RTO≤30s，核心业务可优化至RTO≤10s），避免业务中断。

方案兼顾实用性与扩展性，适配Redis单机、主从、Cluster三种部署模式，同时平衡资源成本与运维复杂度，满足从非核心业务到金融级核心业务的容灾需求。

二、核心容灾架构对比（三种方案）

业务类型	容灾架构	核心优势	适用场景	RPO	RTO	资源成本	运维复杂度
非核心业务（日志、临时缓存）	主从跨机房部署（1主1从）	部署简单、成本最低，满足基本容灾需求	数据量≤10GB、QPS≤1万，对可用性要求不高	≤10s	≤1min	低（仅2个Redis实例）	低
核心业务（电商、支付会话）	Cluster跨机房一主两从部署	支持分片扩展，自动故障转移，双重容错	数据量＞10GB、QPS＞1万，对可用性要求高	≤5s	≤30s	中（实例数=分片数×3）	中
金融级核心业务（交易、核心数据）	双活机房双向同步部署	双机房同时服务，数据零丢失，业务无感知切换	对数据一致性、可用性要求极高	≈0	≤10s	高（两个完整Cluster集群）	高

根据业务对可用性、数据一致性的要求，结合资源成本，提供3种主流架构，适配不同业务场景，核心基于Redis Cluster+主从复制的组合模式，兼顾分片扩展与高可用容灾能力。

三、场景一：非核心业务（低成本容灾）——主从跨机房部署（1主1从）

3.1 架构设计

采用「单主单从」跨机房部署，无需集群分片，适合数据量小（≤10GB）、QPS中等（≤1万）、对RPO/RTO要求不高（RPO≤10s，RTO≤1min）的非核心业务（如日志缓存、非关键业务临时存储）。

主节点（Master）：部署在主机房A，承担所有读写请求；
从节点（Slave）：部署在备机房B，通过Redis原生异步复制，实时同步主节点数据；
核心逻辑：主机房故障时，通过Redis哨兵（Sentinel）实现从节点自动晋升为主节点，业务通过哨兵集群自动切换至备机房新主节点，无需人工干预。

3.1.1 架构图（Redis哨兵+主从跨机房部署，矢量版）

暂时无法在豆包文档外展示此内容

架构图说明：矢量版架构图清晰区分三大层级（主机房、备机房、应用层），明确标注各节点IP、端口及核心角色；箭头清晰区分“主从同步”“哨兵监控”“应用连接”三种关系，契合方案中“哨兵跨机房部署、主从异步复制、应用通过哨兵切换”的核心逻辑，可直接适配矢量展示需求。

3.2 应用连接信息

应用需通过Redis哨兵集群连接Redis实例，而非直接连接主从节点，确保故障切换时应用能自动感知主节点变化，无需修改配置重启服务，核心配置如下：

3.2.1 连接方式

采用「哨兵模式」连接，应用通过哨兵集群获取当前可用的主节点地址，建立连接并执行读写操作；从节点仅作为容灾备用，不承担业务读写（可配置只读，分担少量查询压力）。

3.2.2 核心配置参数（以Java应用为例）

// 1. 哨兵集群地址配置（跨机房部署，确保哨兵高可用）
private static final String SENTINEL_ADDRESSES = "机房A-IP1:26379,机房A-IP2:26379,机房B-IP1:26379";
// 2. 主节点名称（与哨兵配置的主节点名称一致）
private static final String MASTER_NAME = "redis-master";
// 3. Redis密码（主从、哨兵密码统一）
private static final String REDIS_PASSWORD = "Redis@123456";
// 4. 连接池配置（适配跨机房网络延迟）
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(200); // 最大连接数
poolConfig.setMaxIdle(50);  // 最大空闲连接
poolConfig.setMinIdle(20);  // 最小空闲连接
poolConfig.setMaxWaitMillis(3000); // 连接超时时间（跨机房建议3000ms）
// 5. 哨兵模式连接初始化
JedisSentinelPool sentinelPool = new JedisSentinelPool(
    MASTER_NAME,
    Sets.newHashSet(SENTINEL_ADDRESSES.split(",")),
    poolConfig,
    REDIS_PASSWORD
);

3.2.3 关键注意事项

哨兵集群需跨机房部署（建议机房A部署2个，机房B部署1个，共3个哨兵节点），避免单机房故障导致哨兵集群失效，无法触发自动切换；
应用连接超时时间需适配跨机房网络延迟（建议2000-3000ms），避免因网络波动导致连接频繁断开；
所有应用需统一使用哨兵模式连接，禁止直连主从节点，否则故障切换时应用无法自动适配新主节点；
连接池最大连接数需根据业务QPS调整，避免跨机房连接瓶颈导致业务卡顿。

3.3 关键配置（redis.conf + sentinel.conf）

3.3.1 Redis主从核心配置（从节点配置）

# 主从同步核心配置（从节点配置）
slaveof 主机房MasterIP 6379  # 指向主节点地址（机房A主节点IP+端口）
masterauth Redis@123456        # 与主节点密码一致，确保同步正常
repl-timeout 120000            # 跨机房同步超时调整为120s，避免网络延迟导致同步断开
repl-diskless-sync yes         # 开启无盘同步，减少跨机房磁盘IO开销，提升同步效率
cluster-enabled no             # 非集群模式，关闭Cluster
appendonly yes                 # 开启AOF持久化，确保数据持久化不丢失
appendfsync everysec           # AOF刷盘策略，每秒刷盘一次，平衡性能与数据安全
save 0 86400                   # 每天凌晨执行一次RDB快照，作为数据备份补充
slave-read-only yes            # 从节点设为只读，避免误写导致数据不一致

3.3.2 哨兵核心配置（所有哨兵节点统一配置）

# 哨兵监控主节点（名称、主节点IP、端口、投票数量）
sentinel monitor redis-master 主机房MasterIP 6379 2  # 2个哨兵检测到主节点故障，即触发故障转移
# 主节点密码（与Redis主从密码一致）
sentinel auth-pass redis-master Redis@123456
# 主节点无响应超时时间（跨机房建议3000ms）
sentinel down-after-milliseconds redis-master 3000
# 故障转移超时时间
sentinel failover-timeout redis-master 180000
# 故障转移时，最多有多少个从节点同时同步新主节点
sentinel parallel-syncs redis-master 1

3.4 主节点故障自动切换技术原理

本架构基于Redis Sentinel（哨兵）实现主节点故障自动切换，核心是哨兵集群的「监控-检测-故障转移」闭环，全程无需人工干预，具体技术原理分为4个阶段，结合跨机房部署特点优化如下：

3.4.1 阶段1：哨兵集群监控（实时心跳检测）

3个哨兵节点（跨机房部署）持续向主节点（机房A）和从节点（机房B）发送PING命令，进行心跳检测，默认每1秒发送一次；
同时，哨兵节点之间也会互相发送心跳，确保哨兵集群自身的可用性，避免单个哨兵节点故障导致监控失效；
监控核心指标：节点是否在线、响应时间、主从同步状态（从节点复制偏移量是否与主节点一致）。

3.4.2 阶段2：故障检测（主观下线+客观下线）

当主节点（机房A）因机房故障（断电、断网）或自身故障（进程崩溃、硬件损坏）无法响应哨兵的PING命令时，触发故障检测流程：

主观下线（SDOWN）：单个哨兵节点连续3秒（down-after-milliseconds配置）未收到主节点响应，判定该主节点为「主观下线」（仅该哨兵认为主节点故障）；
客观下线（ODOWN）：该哨兵节点向其他哨兵节点发送询问请求，统计认为主节点下线的哨兵数量；当达到配置的投票数量（本方案为2个），则判定主节点为「客观下线」（集群一致认为主节点故障），触发故障转移流程。

关键优化：跨机房网络可能存在瞬时波动，通过延长down-after-milliseconds至3000ms，避免误判主节点故障，减少不必要的故障转移。

3.4.3 阶段3：故障转移（自动选举新主节点）

客观下线后，哨兵集群自动发起故障转移，核心是从备机房的从节点中选举新主节点，步骤如下：

筛选候选从节点：排除处于离线状态、同步延迟过大（复制偏移量与原主节点差距超过10000）、故障状态的从节点（本方案仅1个从节点，直接作为候选）；
选举新主节点：哨兵集群通过「投票机制」选举候选从节点为新主节点，投票原则是「复制偏移量最大」（确保数据最完整，减少数据丢失）；
执行故障转移：

哨兵向候选从节点发送「slaveof no one」命令，将其晋升为新主节点；
哨兵向原主节点（若后续恢复）发送「slaveof 新主节点IP 6379」命令，将其变为新主节点的从节点，同步新主节点数据；
故障转移全程耗时≤30s（符合RTO要求），核心耗时在从节点晋升、同步数据环节。

3.4.4 阶段4：应用自动切换连接

故障转移完成后，哨兵集群会实时更新主节点信息，应用通过以下机制自动切换至新主节点：

应用连接池（如JedisSentinelPool）会定期向哨兵集群查询当前主节点地址，默认每3秒查询一次；
当查询到主节点地址变更（从机房A变为机房B的新主节点），连接池会自动关闭与原主节点的无效连接，建立与新主节点的连接；
应用层面无需做任何修改，读写请求会自动路由至新主节点，实现业务无感知切换（少量请求可能因连接切换出现短暂超时，可通过重试机制规避）。

3.5 优势与局限

优势：部署简单、资源成本低（仅2个Redis实例+3个哨兵节点），运维难度低；通过哨兵实现主节点故障自动切换，无需人工干预，满足非核心业务基本容灾需求；应用连接无需手动调整，切换成本低。
局限：仅支持单节点，无分片能力，无法应对高并发、大数据量场景；主从异步复制存在少量数据丢失风险（RPO≤10s）；哨兵故障转移虽自动，但跨机房网络延迟可能导致切换耗时略长，不适合核心业务。