Redis双机高可用部署方案：两种架构实现主从与哨兵模式

在规划Redis高可用架构时，一个常见的误区是试图在仅有两台服务器的情况下部署原生Redis Cluster。这里必须先明确一个核心原则：原生Redis Cluster集群无法仅用双机实现高可用，其最少要求是三个主节点。因此，对于只有两台机器的标准企业环境，唯一可行的方案是采用「主从复制 + 哨兵（Sentinel）」架构。

双机环境下的Redis高可用架构选型

面对两台服务器，资源分配非常清晰：

• 节点A：作为主节点（Master），承担主要读写流量。
• 节点B：作为从节点（Slave），同时部署一个哨兵进程，实现数据冗余和故障监控。
• 关键点：两台服务器都必须部署Sentinel哨兵，组成一个最小的、具备选举能力的哨兵集群。

最终形成的架构是1主1从 + 双哨兵。这个方案的优势在于：

• 支持自动故障转移与主从切换，实现高可用。
• 配置相对简单，运维成本较低。
• 注意，这不是Redis Cluster分片集群，因此没有哈希槽，也不具备数据分片能力，其核心目标是保障服务连续性而非横向扩展。

Redis双机部署拓扑与核心优势

机器1 (10.0.0.1)： Redis-Master + Sentinel-1
机器2 (10.0.0.2)： Redis-Slave  + Sentinel-2

这个拓扑结构完美契合了两台机器的物理限制，并带来了几个核心优势：

1. 合规与资源匹配：刚好满足等保或双机热备的基本要求，不浪费服务器资源。
2. 自动故障切换：当主库意外宕机，哨兵集群能自动将从库提升为新主库，业务中断时间极短。
3. 自愈能力：原主库恢复后，会自动以从库身份重新加入集群，同步新主库的数据。
4. 实施友好：架构和配置都较为直观，降低了部署和后期维护的复杂度。

Redis主从哨兵关键配置详解

配置是架构落地的关键，以下是三份核心配置文件。

主节点配置（机器1的redis.conf）

port 6379
bind 0.0.0.0
daemonize yes
requirepass 123456       # 设置Redis访问密码
masterauth 123456       # 主库也需要此配置，用于与从库认证

从节点配置（机器2的redis.conf）

port 6379
bind 0.0.0.0
daemonize yes
requirepass 123456
masterauth 123456
# 最关键的一行：指向主库的IP和端口
replicaof 10.0.0.1 6379

哨兵配置（两台机器的sentinel.conf配置相同）

port 26379
daemonize yes
# 监控名为“mymaster”的主库，法定票数设为1
sentinel monitor mymaster 10.0.0.1 6379 1
sentinel auth-pass mymaster 123456  # 哨兵访问Redis的密码
# 主库失联30秒则判定为客观下线
sentinel down-after-milliseconds mymaster 30000
# 故障转移超时时间
sentinel failover-timeout mymaster 60000

关于投票数“1”的特别说明：在双哨兵环境中，法定票数必须设置为1。这是为了保证当其中一个哨兵进程或所在机器故障时，剩下的那个哨兵依然能独立达成选举共识，触发故障转移。如果设置为2，则永远无法满足票数条件，导致故障转移机制瘫痪。

Redis服务严格的启动顺序

服务的启动顺序不能错，否则可能导致主从关系或哨兵监控建立失败：

1. 首先，启动机器1上的主库Redis服务。
2. 接着，启动机器2上的从库Redis服务。
3. 最后，分别在两台机器上启动哨兵服务。

redis-sentinel /etc/redis/sentinel.conf

Redis高可用故障模拟验证

部署完成后，务必进行一次故障模拟，以验证高可用机制是否生效：

1. 主动停止机器1上的Redis主进程。
2. 观察哨兵日志，确认其感知到主库下线，并成功将机器2的从库提升为新的主库。
3. 验证业务应用是否能够自动切换到新的主节点进行写入。
4. 重新启动机器1的Redis，观察其是否会自动作为从库同步新主库（机器2）的数据。

业务端连接Redis哨兵的方式

这是很多开发者容易出错的地方。业务应用程序不应该直接连接固定的Redis主从地址，而应该连接哨兵集群。客户端通过哨兵来动态查询当前可用的主节点地址。

连接字符串示例如下（具体格式取决于客户端驱动）：

sentinel://10.0.0.1:26379,10.0.0.2:26379/mymaster

这种方式实现了“无感切换”：当主库发生故障转移后，业务端通过重新查询哨兵就能获得新的主库地址，无需修改配置或重启应用。

Redis双机部署禁忌与最佳实践

1. 绝对不要在双机环境强行部署Redis Cluster。这会导致集群因节点数不足而无法正常工作，极易产生脑裂和数据不一致问题。
2. 双机热备的标准答案就是「主从 + 哨兵」。这是经过大量生产环境验证的成熟方案。
3. 数据一致性强化：如果对数据一致性要求极高，可以在从库配置中增加 replica-serve-stale-data no。这样当从库与主库失同步时，会拒绝对外提供数据，避免读到过期数据。

Redis双机高可用方案总结

• 限制明确：双服务器无法部署原生Redis集群（Cluster）。
• 标准方案：采用1主1从 + 双哨兵架构。
• 达成目标：满足双机部署、自动故障切换、高可用性，且具备生产级稳定性。
• 适用场景：非常适合中小型项目、数据库双机热备、以及任何需要在不增加服务器的情况下提升Redis服务可靠性的场景。