搭建一套高可用的Redis哨兵集群，是很多团队从单机Redis迈向生产环境的必经之路。网上关于哨兵的教程不少，但多数要么只讲概念不讲落地，要么给了一堆命令但没解释为什么要这么配。这篇文章我基于实际部署经验，把一主两从三哨兵的完整过程、配置参数背后的原理、以及我踩过的坑一次性写清楚，希望能帮你少走弯路。
这套架构解决的核心问题很简单：主节点挂了怎么办。主从复制解决了数据备份和读扩展，但master宕机后需要人工切换，业务会中断。哨兵集群的职责就是自动发现master故障、选举新的master、并通知客户端更新连接信息。文章适合正在搭建Redis高可用方案的运维和开发同学，也适合准备面试时梳理哨兵机制的读者。
1. 架构设计与核心思路
1.1 为什么需要一主两从三哨兵
先想明白一个基础问题：主从复制本身有什么不足？Redis的主从复制解决了两个问题，一是数据冗余，master的数据实时同步到slave，即使master节点磁盘损坏，slave上还有副本；二是读写分离，把读流量分散到从节点上，减轻master压力。
但主从复制有个致命缺陷——master宕机后，整个写入能力直接丧失。你需要人工登录某台slave，执行REPLICAOF NO ONE把它提升为master，然后让其他slave重新指向它，再修改客户端的连接配置。这个过程少说也要几分钟，而且人很容易在紧张中出现操作失误。
哨兵（Sentinel）就是来解决这个问题的。它是一个独立运行的进程，专门监控Redis主从节点的健康状况。当master不可用时，哨兵集群通过投票选出一个新master，自动完成故障转移，整个过程不需要人工干预，业务中断时间可以控制在秒级。
再来说为什么是“一主两从”和“三哨兵”。
一主两从的拓扑是Redis官方推荐的底线配置。两个从节点保证master宕机后至少有一个从节点拥有完整数据可用于提升，另一个从节点则作为新master的备用，提供持续的读服务。如果你只有一主一从，master宕机后虽然也能用从节点顶上，但这台从节点既是新的master又承担所有读流量，一旦它再出问题，整个集群就彻底瘫痪了。两个从节点给了系统容错的缓冲。
三个哨兵则是保证故障转移决策的正确性。哨兵之间通过投票机制达成共识，只有当多数哨兵确认master不可用时才执行故障转移。两个哨兵时，如果一个哨兵宕机，剩下一个无法形成多数派，故障转移就永远无法触发——这是脑裂和可用性之间的权衡。三哨兵允许一个哨兵宕机，剩下两个哨兵还能正常协作完成故障转移，在保证正确性的前提下尽可能提升可用性。这也是为什么生产环境至少要部署三个哨兵的原因。
1.2 哨兵集群的工作机制速览
哨兵本质上是一个运行在特殊模式下的Redis服务器，但它不用来存储业务数据。它的核心工作可以概括为四件事：
- 监控（Monitoring）：哨兵每隔一秒向master和slave发送PING命令，检查它们是否存活。如果master在指定时间内没有响应，哨兵会先将其标记为主观下线（sdown，subjective down）。
- 通知（Notification）：当被监控的Redis节点状态发生变化时，哨兵通过Pub/Sub机制通知其他哨兵和客户端。
- 自动故障转移（Automatic Failover）：当足够多的哨兵（满足quorum数量）都认为master主观下线时，master被标记为客观下线（odown，objective down）。此时哨兵集群会选举出一个leader哨兵，由它执行故障转移流程：从从节点中选出新的master，让其余从节点复制新master，并通知客户端更新配置。
- 配置提供者（Configuration Provider）：客户端在初始化时连接哨兵集群，获取当前master的地址。当master发生切换后，哨兵会通知客户端连接新的master。
这里有一个非常关键的点：主观下线和客观下线的区别。
单个哨兵发现自己与master之间的心跳超时，只能说明这个哨兵自己联系不上master了，可能是master真挂了，也可能是网络分区导致这个哨兵与master隔离。如果只有这个哨兵认为master不可用就立刻触发故障转移，很容易因为网络抖动产生误判。因此引出了客观下线的概念：当至少quorum个哨兵都认为master主观下线时，才会真正触发故障转移流程。
+----------------+ PING +----------------+ | Sentinel 1 | -----------> | Master | +----------------+ +----------------+ +----------------+ PING +----------------+ | Sentinel 2 | -----------> | Master | +----------------+ +----------------+ +----------------+ PING +----------------+ | Sentinel 3 | -----------> | Master | +----------------+ +----------------+所有哨兵都独立监测master，并通过Pub/Sub频道互相沟通判断。这种设计保证了单个哨兵的误判不会导致整个集群做错误的切换。
1.3 方案选型：为什么不用Cluster
在动手部署之前，还有一个绕不开的问题：既然Redis Cluster也能实现高可用和分片，为什么还要用哨兵？我的建议是，两者解决的场景不同，不要混为一谈。
Redis Cluster主要解决的是数据量超出单机内存时的水平扩展问题。它通过哈希槽（hash slot）把数据分散到多个主节点，每个主节点有若干从节点，当某个主节点挂掉后，对应的从节点自动晋升。但Cluster架构的代价是客户端实现更复杂，而且多key操作在跨槽位时会受到限制，需要用户自己处理hash tag，运维的复杂性也更高。
哨兵集群解决的是单个master的可用性问题，架构简单、数据完整保留在同一份逻辑空间里，客户端只需连哨兵获取master地址，一体化程度高。如果业务数据量不大（单机内存能装下），但需要高可用和自动故障转移，哨兵是性价比更高的选择。
从我的实际经验看，很多团队在初期数据量不大时直接上Cluster，结果发现多key事务、Lua脚本跨槽位限制一大堆，反而把业务复杂度抬高了。正确的姿势是：先判断容量需求，单机Redis能搞定就上哨兵，搞不定再考虑Cluster。
2. 哨兵机制的核心细节与原理
2.1 三个定时任务：哨兵的心脏
哨兵的工作不是被动的，它通过三个定时任务维持对集群状态的感知：
第一个是每10秒一次的INFO任务。每个哨兵每10秒会向架构中的master和slave发送INFO命令，用来获取最新的主从拓扑信息。比如当前master挂了、某台slave被提升为master后，哨兵通过INFO感知到新的拓扑关系，然后更新自己的配置缓存。
第二个是每2秒一次的发布订阅任务。哨兵通过Redis的Pub/Sub频道__sentinel__:hello交换彼此的IP、端口、运行ID以及对自己所监控的master的判断结果。这个频道让所有哨兵形成一个松耦合的通信网络，任何哨兵都不需要把所有其他哨兵地址提前配置好，只要连接同一个master，就能通过hello频道互相发现。
第三个是每1秒一次的PING任务。每个哨兵每秒向所有已知的Redis节点（master、slave、其他哨兵）发送PING，用来检测节点是否在线。主观下线状态就是基于这个PING的响应情况来判断的。
这三个定时任务保证了监控的实时性、拓扑信息的一致性和哨兵之间的相互感知，是哨兵机制正常工作的基石。
2.2 客观下线与quorum玩法的门道
前面提到，sentinel monitor命令中有一个quorum参数，比如配置里写的是：
sentinel monitor mymaster 127.0.0.1 6379 2这个2就是quorum，代表触发客观下线需要的最小哨兵确认数。在3个哨兵的集群里，2的意思是最少要两个哨兵都认为master主观下线，才会把master标记为客观下线并启动故障转移流程。
值得注意的是，quorum并不是必须等于哨兵数量的一半以上，它可以是2，也可以是1，但设置过低会增大误判风险。比如quorum=1意味着只要任一个哨兵联系不上master就立刻触发切换，网络抖动很容易造成频繁切换，对业务影响反而更大。
故障转移的执行还需要另一个条件：在当前配置纪元（configuration epoch）内，哨兵必须以多数派（majority）的身份获得投票支持。这里有quorum和majority两个概念容易混淆：
- quorum用于判定master客观下线，它可以在配置中灵活调整，比如3个哨兵配2、5个哨兵配3。
- majority用于决定哪个哨兵来主导执行故障转移，它由当前存活的哨兵总数决定，必须超过一半。比如3个哨兵的集群中有一个挂了，剩下的2个中必须有2个投票一致（超过1个的半数是2）才能当选leader执行切换。
换句话说，3个哨兵能容忍1个哨兵宕机；4个哨兵理论上也能容忍1个，但如果挂了2个，剩下的2个虽然构成半数，但在某些极端情况下可能无法选出leader。官方推荐使用奇数个哨兵，就是出于这个考虑。
2.3 哨兵leader选举和Raft协议
客观下线只是宣布master“死了”，真正执行故障转移的哨兵还需要被选举出来。这里的选举机制借鉴了Raft协议的核心思想，逻辑非常精巧。
当哨兵A发现master达到客观下线条件后，它向其他哨兵发送SENTINEL is-master-down-by-addr命令，请求对方投票给自己成为故障转移的执行者。每个哨兵在同一个配置纪元内只能投一票，遵从先到先得原则。如果某个哨兵获得了半数以上（majority）的投票，它就当选为leader，负责执行故障转移流程。
这套机制防止了多个哨兵同时发起切换导致的数据混乱。比如两个哨兵同时把不同从节点提升为master，就会产生两个master的情况，这在Redis哨兵架构中是被严格禁止的。竞选出leader后，只能由leader操作拓扑变更，其他哨兵配合更新配置。
这里我建议不要被Raft这个名词吓倒。你不需要完整实现Raft，只需要理解“多数派投票 + 配置纪元”这个核心思想，就能解释哨兵集群在各种故障场景下的行为。
2.4 主节点选举规则：从节点晋升的优先序
leader哨兵确定后，接下来就是从节点中选新master的问题。选举规则是按照优先级降序筛选：
- 过滤掉处于断开状态的从节点。
- 过滤掉最近
down-after-milliseconds毫秒内没有响应过INFO命令的从节点（可以理解为近期与哨兵失联过的节点）。 - 过滤掉与master断连时间超过
down-after-milliseconds * 10毫秒的从节点。这个规则是为了防止选出一个数据落后太多的从节点——它和master断连太久，提升后数据丢失严重，不如不选。
筛选完成后，在剩余候选节点中按以下顺序比较：
- 优先级（
slave-priority，可以在配置中设置，数值越小优先级越高，0表示永远不提升）。 - 复制偏移量（offset，越接近master丢的数据越少，优先选择）。
- 运行ID（run id，字典序小的优先，纯粹为了打破平局）。
这里有一个很重要的实操点：slave-priority这个参数平时很容易被忽略，但它是规划故障转移时最有效的控制手段。比如某个从节点所在机器CPU更强、内存更大，或者所在机房距离客户端更近，你可以把它的slave-priority设为1，其他从节点设为2，这样故障转移时会优先提升它。
2.5 脑裂问题的深层理解与预防
哨兵架构中有一个比较隐蔽但后果严重的风险——脑裂（split-brain）。简单说，在master故障切换过程中，如果旧的master并没有真正宕机，而是因为网络分区与哨兵失联，那么哨兵可能已经把某个从节点提升为新的master，但旧的master在网络恢复后仍然存活，这时集群中短暂存在两个master，客户端写入的数据就会分散到两台机器上。
如果旧的master在分区结束后发现自己已经变成从节点，它会尝试复制新master，并清空自己身上在分区期间写入的新数据。这个过程对业务来说是灾难性的：分区期间写入旧master的数据全部丢失。
Redis提供了两个配置项来缓解这个问题：
min-replicas-to-write 1 min-replicas-max-lag 10含义是：如果当前master连接的从节点数量少于1个，或者从节点的延迟超过10秒，master就拒绝写入。这样在网络分区发生时，旧的master失去多数从节点的连接，很快会触发拒绝写入，避免脑裂期间产生不可同步的新数据。
当然，这两个配置本质上是在可用性和数据一致性之间做取舍。配置min-replicas-to-write 1意味着即使只有一个从节点在线，master也正常提供服务；如果追求更高的数据安全性，可以调大到2，但相应的，单从节点故障时会直接导致master拒绝写入，业务可用性受影响。需要根据业务对数据丢失的容忍度权衡。
3. 一主两从三哨兵部署实操
3.1 环境准备与架构规划
我的实验环境是三台Ubuntu 22.04的虚拟机，每台2核4G内存。实际生产环境建议物理隔离部署，每台机器放一个Redis实例和一个Sentinel实例，这样即使一台机器完全宕机，哨兵数量和Redis节点数量各减一，集群仍然可用。
版本我选的Redis 7.0.x。7.0相比6.x在内存效率、命令延迟方面都有优化，而且官方维护期更长。下载编译安装的过程很简单：
wget https://download.redis.io/releases/redis-7.0.12.tar.gz tar xzf redis-7.0.12.tar.gz cd redis-7.0.12 make -j4 make install PREFIX=/usr/local/redis编译安装完，二进制文件在/usr/local/redis/bin下，包含redis-server、redis-sentinel、redis-cli等。为了方便管理，我建议创建独立的运行用户和目录：
useradd -r -s /sbin/nologin redis mkdir -p /data/redis/{6379,6380,6381} mkdir -p /data/redis/sentinel/{26379,26380,26381} mkdir -p /var/log/redis chown -R redis:redis /data/redis /var/log/redis下面是节点规划表，我建议你按照这个表格准备配置文件，后面所有操作都围绕这个拓扑展开：
| 角色 | 节点IP | Redis服务端口 | Sentinel端口 | 数据目录 |
|---|---|---|---|---|
| master | 192.168.56.101 | 6379 | 26379 | /data/redis/6379 |
| slave1 | 192.168.56.102 | 6379 | 26379 | /data/redis/6379 |
| slave2 | 192.168.56.103 | 6379 | 26379 | /data/redis/6379 |
看到这个表格你可能会疑惑：为什么每个机器上Redis端口和Sentinel端口都是6379和26379？这样安排完全没问题，因为Redis和Sentinel进程分别在各自机器上占用这些端口，互不冲突。三台机器都是相同的端口配置，更易于批量管理和自动化脚本处理。当然，如果你只有两台机器或者想在同机部署，端口规划就需要改变，后面我会单独说明。
3.2 Redis主从节点配置详解
先配置master节点，也就是192.168.56.101上的Redis。修改/data/redis/6379/redis.conf，关键配置如下：
# 绑定IP，生产环境务必改为实际网卡IP，不要用127.0.0.1 bind 0.0.0.0 # 启用保护模式。如果设置了密码或者绑定非本机地址，建议开启 protected-mode yes # Redis服务端口 port 6379 # 后台运行 daemonize yes # PID文件和日志文件位置 pidfile /var/run/redis_6379.pid logfile /var/log/redis/redis_6379.log # 数据持久化目录 dir /data/redis/6379 # 设置访问密码，生产环境必须配置 requirepass Redis@2024 # 设置从节点访问master的认证密码 masterauth Redis@2024这里requirepass和masterauth是两回事：requirepass用来认证客户端访问本节点的请求；masterauth用来让本节点作为从节点连接master时进行认证。实际配置中两个都要设置，因为master在故障转移后可能变成从节点，需要提前准备好认证信息。
然后是配置两个从节点。slave1（192.168.56.102）上的/data/redis/6379/redis.conf和master的大部分配置一致，只需要额外增加一行：
# 指定master节点的IP和端口（host为master的IP，port为master的端口） replicaof 192.168.56.101 6379有些老教程里写的是slaveof，Redis 5之后统一改成了replicaof，两者含义相同，但新版本建议用replicaof。slave2（192.168.56.103）同样加上这一行，指向master的IP和端口。
重点说一下protected-mode这个参数。很多人第一次搭哨兵时Redis能从本机连上，但远程访问时总被拒绝，看日志提示DENIED Redis is running in protected mode，原因就是bind 127.0.0.1加protected-mode yes的组合，Redis默认只允许本机回环地址访问。如果你设置了bind为实际IP，并且配置了requirepass密码，保护模式不会拦截连接。但如果你只是临时测试，把protected-mode设为no也可以，生产环境不建议。
配置完启动三个Redis服务：
# master上执行 redis-server /data/redis/6379/redis.conf # slave1和slave2上分别执行 redis-server /data/redis/6379/redis.conf启动后验证主从关系，在master上执行：
redis-cli -a Redis@2024 info replication输出应该包含：
# Replication role:master connected_slaves:2 slave0:ip=192.168.56.102,port=6379,state=online,offset=xxx,lag=1 slave1:ip=192.168.56.103,port=6379,state=online,offset=xxx,lag=1看到两个从节点都是online状态，主从复制链路就通了。这里我建议你在master上写几条测试数据，然后在从节点上执行redis-cli -a Redis@2024 get testkey验证数据是否同步，确认无误后再进入哨兵配置环节。
3.3 哨兵配置：monitor参数与常用选项
哨兵的配置文件路径通常是/etc/redis/sentinel.conf或我们之前规划的目录。每台机器上的Sentinel配置大体相同，唯一区别是sentinel monitor这行指定的master地址。为了保证可维护性，我建议三台机器上的Sentinel配置尽量保持一致。
看一份完整的Sentinel配置，以master机器（192.168.56.101）上的/data/redis/sentinel/26379/sentinel.conf为例：
# 哨兵监听端口 port 26379 # 后台运行 daemonize yes # 日志和PID文件 pidfile /var/run/redis-sentinel_26379.pid logfile /var/log/redis/sentinel_26379.log # 工作目录 dir /data/redis/sentinel/26379 # 监控的master信息： # sentinel monitor <master-group-name> <ip> <port> <quorum> sentinel monitor mymaster 192.168.56.101 6379 2 # 主观下线判断时间：master在10秒内没有响应PING即判定为主观下线 sentinel down-after-milliseconds mymaster 10000 # 故障转移超时时间：3分钟 sentinel failover-timeout mymaster 180000 # 故障转移后，同时向新master发起同步的从节点数量 sentinel parallel-syncs mymaster 1 # 如果Redis配置了密码，此处需要配置Sentinel连接Redis的密码 sentinel auth-pass mymaster Redis@2024这里每行参数都值得展开说。
sentinel monitor mymaster 192.168.56.101 6379 2是哨兵的核心配置。mymaster是这个master组的逻辑名称，可以自定义，但所有哨兵必须保持一致。192.168.56.101 6379是master的初始地址。注意，如果master发生故障转移，Sentinel会自动更新这个配置项为新master的地址，并重写配置文件。
quorum（配置中最后的2）的含义前面已经讲过：最少需要多少个哨兵确认master主观下线才触发客观下线和故障转移。3个哨兵配2是标准做法。
down-after-milliseconds设多长需要根据网络状况权衡。设太短——比如1000——在网络抖动的情况下很容易触发误判，频繁切换反而影响业务；设太长——比如60000——意味着master宕机后业务要等1分钟才能恢复。我的建议是本地网络环境设置10000，跨机房环境适当上调到15000或20000。这个参数不是死的，生产环境要通过演练找到适合自己网络延迟的值。
parallel-syncs控制的是故障转移完成后，同时向新master发起全量同步的从节点数量。设置为1的意思是逐台从节点进行同步，避免多台从节点同时触发全量同步对master造成过大压力。如果从节点数量少、数据量也不大，调成3甚至更大也不会造成太大问题，但保险起见，我建议保持1。
三台机器的sentinel.conf内容是完全一样的。等等，这里有一个细节要注意：配置里sentinel monitor mymaster 192.168.56.101 6379 2中的IP是master的初始IP。在从节点和哨兵同机的场景下，这个IP不会变，因为故障转移后哨兵会自动更新配置文件。所以三份配置保持相同是完全没问题的。
启动三个哨兵：
# 三台机器分别执行 redis-sentinel /data/redis/sentinel/26379/sentinel.conf启动后验证哨兵集群状态，在任意一台机器上执行：
redis-cli -p 26379 sentinel master mymaster输出中应该包含当前master的IP和端口，以及从节点信息：
1) "name" 2) "mymaster" 3) "ip" 4) "192.168.56.101" 5) "port" 6) "6379" ...再执行：
redis-cli -p 26379 sentinel replicas mymaster redis-cli -p 26379 sentinel sentinels mymaster分别能查到两个从节点和另外两个哨兵的信息，说明一主两从三哨兵的架构已经生效。
3.4 启动顺序与各节点启动脚本
关于启动顺序，我的建议是固定的三步走：
- 先启动所有Redis节点，确保主从同步正常。顺序上先master后slave。
- 再启动所有哨兵节点。三个哨兵的启动顺序没有严格要求，但建议一个一个起，观察每个哨兵是否正常加入
__sentinel__:hello频道。 - 最后做验证检查。
这个顺序背后的逻辑是：哨兵启动后需要立即从master获取拓扑信息，如果master还没起，哨兵会进入待机状态，虽然最终也能恢复，但日志里会大量刷连接错误，影响排查问题的效率。
为了方便以后管理，我建议写一个启动脚本来统一处理这些事。脚本内容很简单：
#!/bin/bash # Redis哨兵集群启动脚本 # 用法: ./start-all.sh [redis|sentinel|all] case "$1" in redis) for port in 6379; do redis-server /data/redis/${port}/redis.conf done ;; sentinel) for port in 26379; do redis-sentinel /data/redis/sentinel/${port}/sentinel.conf done ;; all) for port in 6379; do redis-server /data/redis/${port}/redis.conf done sleep 2 for port in 26379; do redis-sentinel /data/redis/sentinel/${port}/sentinel.conf done ;; *) echo "Usage: $0 {redis|sentinel|all}" exit 1 ;; esac同样的脚本放在三台机器上，各机器执行需要启动的部分。这里我踩过的坑是在阿里云ECS等云主机上，Sentinel配置文件如果被修改过权限（比如chmod 777），redis-sentinel启动时会报*** FATAL CONFIG FILE ERROR (Redis 7.0.12) ***的错，原因是Sentinel会实时改写配置文件，必须确保运行用户对配置文件有写权限。
3.5 故障转移演示：kill掉master观察自动切换
部署完成不代表万事大吉，我强烈建议做一次故障转移演练，验证哨兵集群真的能如预期工作。
先在master（192.168.56.101）上写入一个测试key：
redis-cli -a Redis@2024 set testkey before-failover然后模拟master宕机，在master机器上直接kill掉Redis进程：
# 找到Redis进程 ps -ef | grep redis-server | grep 6379 # 杀掉进程 kill -9 <pid>此时观察哨兵日志（tail -f /var/log/redis/sentinel_26379.log），你会看到一系列状态变化：
+sdown master mymaster 192.168.56.101 6379 +odown master mymaster 192.168.56.101 6379 #quorum 2/2 +try-failover master mymaster 192.168.56.101 6379 +failover-state-select-slave master mymaster 192.168.56.101 6379 +selected-slave slave 192.168.56.102:6379 192.168.56.102 6379 +failover-state-send-slaveof-noone slave 192.168.56.102:6379 192.168.56.102 6379 +failover-state-wait-promotion-slave slave 192.168.56.102:6379 192.168.56.102 6379 +promoted-slave slave 192.168.56.102:6379 192.168.56.102 6379 +failover-state-reconf-slaves master mymaster 192.168.56.101 6379 +slave-reconf-sent slave 192.168.56.103:6379 192.168.56.103 6379 +slave-reconf-inprog slave 192.168.56.103:6379 192.168.56.103 6379 +slave-reconf-done slave 192.168.56.103:6379 192.168.56.103 6379 +failover-end master mymaster 192.168.56.101 6379 +switch-master mymaster 192.168.56.101 6379 192.168.56.102 6379这段日志完整展示了故障转移的流程。关键事件是+switch-master，它表示master已经从192.168.56.101切换到了192.168.56.102。整个过程从sdown到switch-master大约耗时十几秒，主要取决于down-after-milliseconds的配置。
切换完成后，验证一下数据：
# 在新的master上执行 redis-cli -a Redis@2024 get testkey应该返回before-failover，说明数据完整地转移到了新master上。如果你在slave上执行同样的命令，会发现步骤中slave2从新master同步到了这条数据。
这时候查看各节点的角色：
# 在新master（192.168.56.102）上 redis-cli -a Redis@2024 info replication # role:master，slave1是192.168.56.103 # 在旧master（192.168.56.101）上 redis-cli -a Redis@2024 info replication # 重启后会发现角色已经变成slave，并且replicaof新master看到旧master在重启后自动变成了新master的从节点，这一点很重要。因为哨兵集群在切换后会把旧master的信息更新到配置中，所以旧master一旦恢复上线，会被要求复制新的master，它的数据会自动对齐。
如果你发现故障转移后数据丢失了，优先检查从节点的复制偏移量。日志中+selected-slave slave 192.168.56.102:6379这一步，Sentinel其实已经比较过所有从节点的复制偏移量，选择偏移量最接近旧master的从节点晋升。但如果你手动调整过优先级，就可能选出一个偏移量较小的节点，数据可能不是最新的。
3.6 通过Docker部署哨兵集群的注意事项
如果你不想在三台物理机或虚拟机上部署，也可以使用Docker Compose在一台机器上模拟全套架构。Docker方式的好处是能快速拉起环境做测试和演练，坏处是网络模型和容器生命周期管理给哨兵部署增加了一些细节坑。
一个常见问题是Sentinel在容器里默认使用容器内IP作为自己的地址，如果这个IP在宿主机网络之外不可达，其他Sentinel就无法和它通信。解决办法是给Sentinel容器配置network_mode: host，或者指定sentinel announce-ip为宿主机的实际IP。
另一个问题是如果只使用Docker的默认bridge网络，容器重启后IP会变化，Sentinel之间依赖IP的通信会紊乱。建议使用Docker Compose时固定网络或使用自定义网络并关闭自动分配IP，配合container_name使用更稳。
Docker Compose的编写思路：
version: '3.8' services: redis-master: image: redis:7.0.12 container_name: redis-master restart: always network_mode: host command: ["redis-server", "--port", "6379", "--requirepass", "Redis@2024", "--masterauth", "Redis@2024", "--appendonly", "yes"] redis-slave1: image: redis:7.0.12 container_name: redis-slave1 restart: always network_mode: host command: ["redis-server", "--port", "6380", "--replicaof", "127.0.0.1", "6379", "--requirepass", "Redis@2024", "--masterauth", "Redis@2024", "--appendonly", "yes"] redis-slave2: image: redis:7.0.12 container_name: redis-slave2 restart: always network_mode: host command: ["redis-server", "--port", "6381", "--replicaof", "127.0.0.1", "6379", "--requirepass", "Redis@2024", "--masterauth", "Redis@2024", "--appendonly", "yes"] sentinel1: image: redis:7.0.12 container_name: sentinel1 restart: always network_mode: host command: ["redis-sentinel", "/etc/redis/sentinel.conf"] volumes: - ./sentinel1.conf:/etc/redis/sentinel.conf上面这种方式用network_mode: host把容器网络直接绑定到宿主机，哨兵报告给其他哨兵的地址就是宿主机的实际IP，避免了很多容器网络的坑。相应的，Docker容器内redis的端口就变成宿主机端口了，如果你本机已经装了Redis，需要调整端口规划，比如Redis用6379、6380、6381，Sentinel用26379、26380、26381。
4. 常见问题排障与配置细节
4.1 主观下线但始终无法客观下线
现象是某个Sentinel日志显示+sdown master mymaster，但一直停留在sdown状态，迟迟没进入+odown。
这个问题通常出在sentinel monitor配置的quorum值上。如果quorum设置为2，但实际只有1个Sentinel对这个master做了sdown判断，就无法满足客观下线条件。
另一个常见原因是Sentinel之间网络不通。比如E CS安全组只放行了6379端口，没放行26379端口，那么Sentinel之间无法通过__sentinel__:hello频道交流心跳和投票信息，所有Sentinel都各自为政，永远凑不够quorum。排查时检查每个Sentinel能否通过redis-cli -h <其他哨兵IP> -p 26379 ping，返回PONG说明Sentinel间网络正常。
还有一个原因是Sentinel配置的master IP端口不正确。如果你在配置里写的是sentinel monitor mymaster 127.0.0.1 6379 2，而Sentinel部署在其他机器上，它连的127.0.0.1是它自己，永远连不上master，自然无法参与后续判断。配置里必须写master在网络上可访问的实际IP。
4.2 故障转移后客户端无法连接新master
这种情况多发生在客户端没有使用哨兵机制连接Redis，而是直接配置了master的地址。当master切换后，客户端还在连旧master，自然会连接失败。
正确做法是客户端通过哨兵获取master地址。以Java生态中最常用的Lettuce为例：
RedisURI sentinelUri = RedisURI.sentinel("192.168.56.101", 26379, "mymaster") .withPassword("Redis@2024"); RedisClient client = RedisClient.create(sentinelUri);使用Spring Boot时配置更简单：
spring: data: redis: sentinel: master: mymaster nodes: - 192.168.56.101:26379 - 192.168.56.102:26379 - 192.168.56.103:26379 password: Redis@2024Spring Data Redis内部会自动通过Sentinel节点发现当前master并与之建立连接，当master切换时也会自动感知并重连。
4.3 哨兵日志报错-denied或权限不足
Sentinel在运行期间需要写入自己的配置文件来记录拓扑变化，如果配置文件的属主是root，而Sentinel进程以redis用户运行，就会报权限错误，故障转移也无法正常记录。
我在生产环境遇到过的报错是：
*** FATAL CONFIG FILE ERROR (Redis 7.0.12) *** Reading the configuration file, at line xx >>> 'sentinel monitor mymaster 192.168.56.101 6379 2' Can't open file '/data/redis/sentinel/26379/sentinel.conf' for writing解决办法是确认文件权限：
chown redis:redis /data/redis/sentinel/26379/sentinel.conf chmod 644 /data/redis/sentinel/26379/sentinel.conf另外，如果配置了protected-mode yes，Redis Sentinel默认只允许本机连接，远程客户端执行SENTINEL命令会报错。如果你需要远程查看Sentinel状态，需要在配置里加上bind 0.0.0.0，并考虑设置Requirepass密码，或者用protected-mode no关闭保护模式（生产环境不推荐）。
4.4 down-after-milliseconds设置太短的教训
我有一次在测试环境把down-after-milliseconds设成了3000，结果某次网络设备更新，导致所有节点之间的连接同时中断了3秒左右，哨兵立刻把master标记为下线并触发故障转移，但network恢复后旧master其实没宕机，集群里出现了短暂的双master现象。虽然最终靠min-replicas-to-write和哨兵的配置收敛机制恢复了，但那次事件给我上了一课：哨兵的参数要结合网络真实延迟来设置，不能只看数值越小恢复越快。
PING是每秒一次，网络闪断如果只是1秒内，其实不至于触发sdown，但3秒就能连续丢3个心跳。在本地网络带宽稳定、RTT通常在1ms以内的环境，down-after-milliseconds设10000是合理的，但如果你在跨机房或者公网环境部署，建议先做一次网络抖动测试，再决定这个值。
4.5 遇到问题时的排查命令汇总
需要快速定位问题时，以下命令能帮你快速判断目前集群状态：
| 命令 | 用途 |
|---|---|
redis-cli -h <ip> -p 26379 sentinel master mymaster | 查看当前master地址 |
redis-cli -h <ip> -p 26379 sentinel replicas mymaster | 查看从节点列表及状态 |
redis-cli -h <ip> -p 26379 sentinel sentinels mymaster | 查看其他哨兵信息 |
redis-cli -h <ip> -p 26379 info sentinel | 查看哨兵整体状态摘要 |
redis-cli -a <pass> -h <ip> -p 6379 info replication | 查看Redis节点主从角色和复制状态 |
tail -f /var/log/redis/sentinel_26379.log | 实时追踪哨兵判断和切换日志 |
这些命令组合基本上能覆盖大多数哨兵集群问题的排查需求。最关键的是养成看日志的习惯，Sentinel日志已经按事件标记了状态变化，比猜配置快得多。
4.6 客户端侧集成与高可用验证
完成集群部署后，建议在客户端写一段简单的验证程序，确认通过哨兵获取的master地址是正确的。我用Spring Boot做了个简单测试。
启动应用后，在日志里能看到类似这样的输出：
Starting SentinelConnection... SentinelConnection established with 192.168.56.101:26379 Redis master discovered: 192.168.56.101:6379然后做一个实验：往Redis写一个key，再kill掉master，观察应用的自动重连行为。正常情况下，故障转移完成后日志里会输出：
Redis connection to 192.168.56.101:6379 lost, attempting reconnect... Redis master switched to: 192.168.56.102:6379如果你的应用没有自动重连能力，就需要依赖客户端连接池的配置了。Redis的Jedis和Lettuce都内置了故障转移感知功能，但需要正确配置，否则故障转移后连接池里还是旧master的连接。
4.7 真实场景中的扩展思考
哨兵集群解决了单点故障，但它不解决容量问题。随着业务增长，单master的内存和写能力会成为瓶颈。这时候可以分两步走：第一步是给master挂更多的从节点，把读流量分摊得更细；第二步是当单机内存快撑不住时，把数据按业务拆分到多个哨兵集群，每个集群服务自己的业务线。
关于持久化，建议哨兵集群的Redis节点开启AOF并且设置为appendfsync everysec，这样在故障转移时最多丢失1秒的数据，配合min-replicas-to-write等配置，能在可用性和数据安全性之间取得较好的平衡。
最后一个建议：部署完后一定要做定期演练。我见过不少团队配置完哨兵集群后觉得很安全，结果半年后第一次真实故障时发现Sentinel配置文件权限早就被某次上线脚本改了、或者auth-pass密码过期，导致故障转移完全没触发。高可用系统最重要的是持续验证，而不是部署那天证明它能用。
我个人的体会是，哨兵集群本身并不复杂，但它的价值完全体现在细节上。参数调优、权限管理、网络规划、客户端适配，任何一个环节掉链子，都可能让这个“高可用”名存实亡。按照上面的步骤搭建并完成一次完整的故障转移演练，你对哨兵机制的理解会上升一个层次，面试中涉及Redis高可用的问题也能从容应对。
