Redis哨兵实战：高可用架构部署、故障转移与踩坑经验

Redis 哨兵这套东西，我最早接触是在一个电商促销活动前夜。当时主从架构跑得好好的，结果主节点凌晨挂了，运维手动切了四十分钟，老板在群里连发十几条消息。从那以后我就把哨兵当成了高可用方案的标配。这篇文章不讲教科书定义，只聊我在实际项目里怎么理解它、怎么部署、怎么踩坑、怎么排查。如果你正在维护一套 Redis 主从、或者准备上高可用方案，这篇内容应该能帮你少走不少弯路。

1. 哨兵到底在解决什么问题

1.1 主从架构的天然短板

Redis 主从复制本身不复杂，配好replicaof就能跑。但它有个致命问题：主节点是单点。主节点一挂，写请求全部失败，从节点只能读不能写。更麻烦的是，客户端配置里写死的主节点地址不会自动变，就算你手动把某个从节点提升为主节点，所有客户端还得改配置重启。

我见过不少团队的做法是写个脚本监控主节点，挂了就调REPLICAOF NO ONE提升从节点，然后挨个改客户端配置。这种方案在节点少、业务简单的时候能凑合用，但节点一多、客户端一多，脚本本身就变成了新的故障点。而且脚本判断主节点是否真的挂了，靠的是 ping 通不通，网络抖动一下就可能误判，触发不必要的切换。

哨兵要解决的就是这几个问题：自动监控、自动判断、自动切换、自动通知客户端。它把原来需要人肉操作的流程全部自动化，而且通过多哨兵投票机制降低误判概率。

1.2 哨兵的核心能力拆解

哨兵不是一个单独的程序，它是一组运行在特殊模式下的 Redis 进程。每个哨兵进程做四件事：

• 监控：持续检查主节点、从节点以及其他哨兵的状态
• 通知：当被监控的实例出现问题时，通过 API 向管理员或其他程序发送通知
• 自动故障转移：主节点不可用时，从从节点中选一个提升为主节点，并让其他从节点指向新主节点
• 配置提供者：客户端连接哨兵集群，询问当前主节点地址，哨兵返回最新结果

这四件事里，最核心的是故障转移和配置提供。故障转移决定了系统能不能自愈，配置提供决定了客户端能不能自动找到新主节点。

1.3 为什么不用 Cluster 替代

经常有人问，既然有 Redis Cluster，为什么还要用哨兵。这个问题我在不同项目里被问过很多次。Cluster 解决的是分片和水平扩展问题，哨兵解决的是单点高可用问题。两者定位不同。

Cluster 的架构复杂度比哨兵高一个量级，数据分片、槽位迁移、跨槽事务限制，这些都会给开发和运维带来额外负担。如果你的数据量单机内存扛得住，QPS 单节点也能撑住，只是想要高可用，那哨兵是更轻量的选择。我个人的判断标准是：单机内存不超过 32G、QPS 不超过 8 万，优先考虑哨兵；超过这个量级再考虑 Cluster。

另外，哨兵对客户端的侵入性更小。大部分 Redis 客户端都支持哨兵模式，只需要配置哨兵地址列表，客户端自己会去问主节点在哪。而 Cluster 需要客户端支持集群协议，一些老客户端或者简单封装可能不支持。

2. 哨兵集群的部署与配置细节

2.1 节点数量与奇数原则

哨兵集群的节点数量必须是奇数，最少 3 个。这个规则背后的逻辑是投票机制。哨兵判断主节点是否客观下线，需要超过半数（quorum）的哨兵同意。3 个哨兵，quorum 设为 2，挂一个还能正常工作；2 个哨兵，quorum 设为 2，挂一个就废了，因为凑不够半数。

我实际部署时一般用 3 个哨兵，分布在不同的物理机或虚拟机上。如果条件允许，最好分布在不同机架甚至不同可用区。哨兵之间通过发布订阅互相发现，它们不需要配置彼此地址，只要配置同一个主节点，就能自动找到对方。

注意：哨兵节点本身不存储数据，资源消耗很低，1 核 1G 的机器就能跑。但不要和 Redis 数据节点部署在同一台机器上，否则机器挂了，数据和哨兵一起没，高可用就失去意义了。

2.2 核心配置参数逐条解读

哨兵的配置文件叫sentinel.conf，核心配置项不多，但每一项都影响故障转移的行为。我按重要性逐个说。

# 监控的主节点，quorum 为 2 sentinel monitor mymaster 192.168.1.10 6379 2 # 主节点多久无响应算主观下线，单位毫秒 sentinel down-after-milliseconds mymaster 30000 # 故障转移时最多同时有几个从节点同步新主节点 sentinel parallel-syncs mymaster 1 # 故障转移超时时间 sentinel failover-timeout mymaster 180000 # 认证密码 sentinel auth-pass mymaster yourpassword

sentinel monitor里的 quorum 是判断客观下线所需的最少票数。注意，quorum 只用于判断下线，真正执行故障转移还需要选举出领头哨兵，领头哨兵需要获得多数哨兵的授权。所以 quorum 设为 2，但选举领头需要 3 个哨兵中的 2 个同意，这两个条件要分开理解。

down-after-milliseconds这个值很关键。设太短，网络抖动就触发切换；设太长，故障恢复慢。我一般设 30000，也就是 30 秒。如果业务对恢复时间敏感，可以降到 10000 到 15000，但要确保网络足够稳定。

parallel-syncs控制故障转移后，同时有多少个从节点去同步新主节点。设大了，新主节点压力大；设小了，从节点逐个同步，整体恢复慢。我一般设 1，稳一点。

failover-timeout影响多个阶段：从节点晋升失败后的重试间隔、新主节点出现后等待其他从节点同步的时间等。默认 180000 也就是 3 分钟，大部分场景够用。

2.3 部署实操步骤

假设你有三台机器，IP 分别是 192.168.1.11、192.168.1.12、192.168.1.13，主节点在 192.168.1.10:6379。三台机器上都部署哨兵。

第一步，在每台机器上创建配置目录：

mkdir -p /etc/redis-sentinel

第二步，写入配置文件。三台机器的配置基本一致，只有sentinel myid不同，但这个值哨兵启动时会自动生成，不用手动配。配置内容：

port 26379 daemonize yes logfile "/var/log/redis-sentinel/sentinel.log" dir "/var/lib/redis-sentinel" sentinel monitor mymaster 192.168.1.10 6379 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 sentinel auth-pass mymaster yourpassword

第三步，启动哨兵：

redis-sentinel /etc/redis-sentinel/sentinel.conf

第四步，验证。连上任意一个哨兵，执行：

redis-cli -p 26379 sentinel master mymaster sentinel sentinels mymaster

sentinel master mymaster会返回主节点信息，包括 ip、port、num-slaves、num-other-sentinels 等。sentinel sentinels mymaster会列出其他哨兵。如果 num-other-sentinels 是 2，说明三个哨兵互相发现了。

2.4 客户端接入方式

哨兵模式下，客户端不直接连主节点，而是连哨兵集群。以 Java 的 Jedis 为例：

Set<String> sentinels = new HashSet<>(); sentinels.add("192.168.1.11:26379"); sentinels.add("192.168.1.12:26379"); sentinels.add("192.168.1.13:26379"); JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels, "yourpassword"); Jedis jedis = pool.getResource(); jedis.set("key", "value");

客户端启动时会连接哨兵，问mymaster的主节点在哪，然后连主节点。主节点切换后，客户端会收到哨兵的通知，重新获取主节点地址。不同客户端的实现细节不同，但核心逻辑一致。

提示：客户端配置哨兵地址时，建议把三个哨兵都配上。只配一个的话，那个哨兵挂了，客户端就找不到新主节点了。

3. 故障转移的完整流程与内部机制

3.1 主观下线与客观下线

哨兵判断一个节点是否下线，分两个阶段。第一阶段是主观下线（SDOWN），单个哨兵自己认为节点挂了。触发条件是：在down-after-milliseconds时间内，ping 没有收到有效回复。

第二阶段是客观下线（ODOWN），多个哨兵都认为节点挂了。当一个哨兵把主节点标记为主观下线后，它会向其他哨兵发送SENTINEL is-master-down-by-addr命令询问。如果收到足够数量（达到 quorum）的哨兵回复也认为主节点下线，那么这个哨兵就把主节点标记为客观下线，触发故障转移流程。

这里有个细节：主观下线和客观下线的判断标准不同。主观下线只看 ping 响应，客观下线看的是其他哨兵的反馈。这样设计是为了避免单个哨兵因为网络问题误判。

3.2 领头哨兵的选举

主节点被标记为客观下线后，多个哨兵都可能同时想执行故障转移。为了避免冲突，需要先选出一个领头哨兵。选举用的是 Raft 算法的简化版。

每个想当领头的哨兵向其他哨兵发送请求，说自己要当领头，请求投票。其他哨兵如果还没投过票，就投给它。一个哨兵获得超过半数（注意是哨兵总数的一半以上，不是 quorum）的票，就成为领头，开始执行故障转移。如果一轮没选出来，等一个随机时间后重新选。

这个随机等待时间很重要，它避免了多个哨兵同时竞选导致一直选不出来。我实际观察下来，三个哨兵的集群，通常几秒内就能选出领头。

3.3 新主节点的挑选规则

领头哨兵选出后，开始从从节点中挑一个提升为主节点。挑选规则按优先级排序：

1. 排除已经下线、断线时间过长的从节点
2. 选择replica-priority最高的从节点，这个值默认 100，设 0 表示永不晋升
3. 优先级相同，选择复制偏移量最大的，也就是数据最新的
4. 偏移量相同，选择 runid 最小的

这个规则里，replica-priority是最容易被人忽略的。我遇到过一种情况：某台从节点配置比主节点差很多，但优先级没改，结果主节点挂了，哨兵把这台弱机器提升为主节点，性能直接崩了。后来我把那台机器的replica-priority设成 0，问题解决。

3.4 切换后的数据一致性处理

新主节点选出来后，领头哨兵会让其他从节点指向新主节点。这里有个数据一致性的问题：旧主节点可能还有部分写请求没同步到从节点，切换后这部分数据就丢了。

Redis 的复制是异步的，哨兵切换无法保证零丢失。要降低丢失风险，可以配置min-replicas-to-write和min-replicas-max-lag，让主节点在从节点数量不足或延迟过大时拒绝写入。但这两个参数会影响可用性，需要根据业务容忍度权衡。

我一般建议对数据一致性要求高的业务，在应用层做补偿，比如写操作记录到消息队列，切换后检查是否有未同步的数据。完全依赖 Redis 自身保证零丢失是不现实的。

4. 常见故障场景与排查实录

4.1 频繁切换的排查思路

频繁切换是最常见的哨兵问题。表现是主节点反复切换，日志里能看到多次+switch-master事件。原因通常有三类：

第一类是网络抖动。哨兵和主节点之间的网络不稳定，ping 偶尔超时，触发主观下线。排查方法是看哨兵日志里+sdown和-sdown的时间间隔，如果很短就恢复，基本是网络问题。解决办法是调大down-after-milliseconds，或者排查网络设备。

第二类是主节点负载过高。主节点 CPU 跑满，处理 ping 请求变慢，超过down-after-milliseconds没响应。这种情况要看主节点的慢查询日志和 CPU 使用率。解决办法是优化慢查询，或者升级主节点配置。

第三类是哨兵之间时钟不同步。哨兵判断下线依赖时间，如果哨兵所在机器时钟差异大，可能导致判断混乱。解决办法是配置 NTP 同步。

4.2 切换后客户端连不上的问题

主节点切换后，客户端应该自动连到新主节点。但实际中经常出现客户端连不上的情况。我总结了几种原因：

• 客户端只配置了一个哨兵地址，那个哨兵恰好挂了
• 客户端没有正确处理哨兵返回的新地址，缓存了旧地址
• 新主节点的防火墙规则没放开，客户端连不上
• 新主节点的密码和旧主节点不一致

排查时先确认哨兵返回的主节点地址是否正确，用sentinel master mymaster看。然后从客户端机器上直接 telnet 新主节点的端口，确认网络通不通。最后检查客户端日志，看它有没有收到哨兵的通知。

4.3 哨兵集群自身故障

哨兵集群本身也可能出问题。比如三个哨兵挂了两个，剩下的一个无法完成故障转移，因为凑不够多数票。这时候系统就失去了自愈能力。

还有一种情况是哨兵之间网络分区，分成两个部分，每部分都以为自己这边是多数，可能导致脑裂。不过哨兵的选举机制要求多数票，分区后只有包含多数哨兵的那部分能执行切换，另一部分不会乱动。

预防哨兵集群故障的办法是部署足够多的哨兵节点，并且分布在不同故障域。我一般建议至少 3 个，重要业务用 5 个。

4.4 常见问题速查表

5. 生产环境的经验与优化建议

5.1 监控指标要盯哪些

哨兵本身提供的监控信息有限，我一般会额外采集这些指标：

• 主节点切换次数，短时间内多次切换说明有问题
• 哨兵数量，少于预期要告警
• 主从复制延迟，延迟过大影响切换后的数据一致性
• 哨兵与主节点的 ping 延迟，延迟高说明网络有问题

这些指标可以通过哨兵的INFO命令获取，也可以用 Redis 的INFO replication看复制状态。我习惯用 Prometheus 加 redis_exporter 采集，配 Grafana 看板，切换事件直接告警到群里。

5.2 切换演练怎么做

哨兵配置好了不代表切换一定能成功。我建议定期做切换演练，手动 kill 主节点，观察哨兵是否正常切换，客户端是否自动重连。

演练时要注意几点：选择业务低峰期，提前通知相关方，准备好回滚方案。演练后检查数据一致性，确认没有异常丢失。我一般一个季度做一次，每次都能发现一些配置或客户端的问题。

5.3 参数调优的实际经验

down-after-milliseconds我一般设 30000，但如果是内网环境且网络很稳，可以降到 10000。failover-timeout默认 180000 够用，如果切换慢可以适当调小。parallel-syncs设 1 最稳，从节点多且机器性能好可以设 2 到 3。

还有一个容易被忽略的参数是sentinel deny-scripts-reconfig，默认 yes，禁止哨兵通过脚本修改配置。生产环境保持默认就好，不要开。

5.4 哨兵与容器化环境的配合

在容器环境里跑哨兵有几个坑。第一，哨兵的myid是自动生成的，容器重启后如果配置文件没持久化，myid会变，其他哨兵会认为这是一个新哨兵。解决办法是把配置目录挂载出来持久化。

第二，容器 IP 可能变化，哨兵之间互相发现依赖 IP，IP 变了会导致发现失败。解决办法是用固定 IP 或者用 StatefulSet 保证网络标识稳定。

第三，健康检查要配好，容器编排平台的健康检查如果太激进，可能误杀哨兵。我一般把健康检查的超时设得比down-after-milliseconds长。

6. 哨兵方案的边界与替代思路

哨兵不是万能的。它解决的是单主节点的高可用，不解决容量和性能问题。如果业务增长到单机扛不住，哨兵帮不了你，得上分片方案。

另外，哨兵的故障转移有时间窗口，通常是几十秒。这个窗口内写请求会失败。如果业务完全不能接受写失败，需要在应用层做降级或重试。

还有一种情况是跨机房部署。哨兵跨机房部署时，机房之间的网络延迟会影响判断。我一般建议哨兵和主节点在同一个机房，从节点可以跨机房。这样主节点故障时，同机房的哨兵能快速判断并切换。

我在实际项目里用哨兵跑了三年多，经历过几次真实的主节点故障，切换都在 30 秒内完成，客户端自动重连，业务基本无感知。但也有一次因为客户端只配了一个哨兵地址，那个哨兵恰好和主节点在同一台机器上，机器挂了之后客户端找不到新主节点，手动介入才恢复。从那以后，我要求所有客户端必须配全哨兵地址，这个习惯一直保持到现在。