Redis哨兵集群搭建实战：1主2从+3哨兵高可用架构全解析

凌晨两点你负责的Redis主节点突然宕机从节点倒是还活着可应用写入全部失败因为只做了主从复制没有自动故障转移。你能做的只有爬起来手动把从节点提升为主节点重启服务改应用配置。这场景我去过一次就再也不想去了。后来我把这套架构升级成1主2从3哨兵主节点挂了以后哨兵自动把候选从节点提升起来应用基本无感知总算把熬夜通宵的事儿解决了。这篇就把我在Linux上从零搭建哨兵集群的全过程写出来包含所有配置文件、启动命令、验证方法以及那些不跑一遍根本发现不了的坑。本文面向已经会装Redis、知道主从复制大概逻辑、但对哨兵模式只停留在概念层面的后端和运维同学。虽然标题写的是1主2从3哨兵但理解原理之后你自己扩展到3主3从或者其他规模也没什么难度。我会把每个配置项为什么这么设、故障转移时内部发生了什么事都拆开讲而不是丢给你一堆命令就完事。1. 先搞懂哨兵在集群里的定位主从复制到底缺了什么1.1 主从复制的分工与局限Redis的主从复制本质上是数据层面的冗余。主节点负责写从节点通过SYNC/PSYNC机制拉取主节点的RDB文件或增量命令保持数据同步。这样即使主节点挂了数据还在从节点上不会彻底丢完。但问题也随之而来——从节点只是默默存数据它不会主动顶上来应用如果继续连原主节点直接连接拒绝。更麻烦的是从节点和主节点之间的复制是单向的主节点挂了以后从节点并不会自动和其他从节点建立新关系。你需要登录一台从节点执行slaveof no oneRedis 5.0以后是replicaof no one让它变成独立主节点再手动把其他从节点重新指向它。一次完整的人工切换快则10分钟慢则半小时。而这期间业务已经断了。靠人肉应对高可用的需求本质上是不现实的。主从复制还有一个容易被忽略的问题它不提供任何“谁该当主节点”的决策机制。如果有多个从节点你要选数据最新的那一个还得自己对比info replication里的offset。一次判断失误可能做了切换之后数据回退比不切换还糟糕。所以需要有一个额外的部件专门盯住所有Redis节点判断谁死谁活然后在必要时发起切换——这就是哨兵。1.2 哨兵带来的三个核心能力Redis Sentinel并不是什么新出来的东西它是Redis官方自带的分布式协调组件。一个哨兵进程就是一个运行在特殊模式下的Redis服务器它不存储业务数据而是通过向主从节点定时发送命令来感知整个集群的健康状态。哨兵群带来的能力可以归成三条监控每10秒定时任务周期可配置向所有主节点和从节点发送INFO命令1秒发送一次PING来判断节点是否存活。通知当被监控的Redis实例发生故障时哨兵通过发布订阅Pub/Sub机制通知客户端或其他哨兵。自动故障转移当主节点被判定为客观下线后哨兵之间会进行投票选举一个leader由leader从从节点里挑选一个新的主节点并让其他从节点改变复制目标同时把旧主节点降级为从节点。第三个能力是主从复制完全不具备的也是我们搭哨兵模式的核心目标。但要注意哨兵模式解决的是“高可用中的自动切换”它不解决数据分片问题。如果你有海量数据需要分摊到多台机器上那该用Redis Cluster不是哨兵。可以这么理解哨兵管的是“确保有人干活”Cluster管的是“让很多人一起干活”。我用一个表格来说明主从复制和哨兵模式的差异方便你判断自己到底需要哪种架构对比项主从复制哨兵模式数据冗余有有自动故障转移无有客户端感知变化无通过Pub/Sub通知主节点选举无哨兵leader负责配置复杂度低中等适用规模单主多从单主多从多个哨兵监控解决分片不解决不解决如果只是读写分离主从复制够用如果要求7×24小时服务不中断必须上哨兵。我见过一些团队把主从复制当成高可用等到事故发生了才后悔这个成本真的没必要省。2. 搭建前的资源规划与Redis安装版本、端口、目录一个都不能乱2.1 版本选择Redis 5.x还是6.x哨兵配置有什么差异我这套方案用的Redis 6.0.16原因很简单稳定、社区资料多、CentOS 7和Ubuntu 20.04上都能顺利编译。Redis 6.0引入了ACL、新版多线程I/O但对哨兵模式的核心机制影响不大。如果你还在用Redis 4.x甚至3.x强烈建议升级到6.x因为低版本的哨兵配置里还在用slaveof和slave-read-only这类老叫法和现在的文档对不上容易配置出错。Redis 5.0开始官方用replicaof替换slaveof但是为了兼容旧参数也还能用。6.x版本里哨兵配置基本没太大变化不过你如果在网上搜到2020年以前的教程命令里多少会有差异比如redis-sentinel和redis-server /etc/sentinel.conf --sentinel两种启动方式其实指向同一个功能用哪个都可以但混着用容易让自己绕晕。版本选好了就是安装。我推荐直接源码编译安装不要用apt/yum里的老版本。源码编译多花两分钟但可以精准控制安装路径后续起多实例的时候目录清晰排查问题也快。2.2 IP与端口分配1主2从3哨兵的网络拓扑在动手之前先把节点规划好。这篇文章用的是内网环境三台机器每台机器上同时跑一个Redis节点和一个哨兵进程。生产环境有条件的话Redis和哨兵最好分机器部署避免哨兵劫持宿主机资源。不过个人实验环境一台机器开6个进程也行只是不要指望它能模拟出网络分区和脑裂那是另一码事。这次的拓扑如下节点角色IPRedis端口哨兵端口master192.168.1.10637926379slave-1192.168.1.11637926379slave-2192.168.1.12637926379端口说明三个Redis都用6379三个哨兵都用26379。IP不同进程之间不冲突。哨兵默认端口就是26379如果改了要记得在自己配置里保持一致别出现启动要求连26379但实际监听26389这种低级的网络错误。所有机器之间的防火墙要放行这两个端口。CentOS 7/8上执行firewall-cmd --permanent --zonepublic --add-port6379/tcp firewall-cmd --permanent --zonepublic --add-port26379/tcp firewall-cmd --reloadUbuntu上用ufw的话ufw allow 6379/tcp ufw allow 26379/tcp这一步别跳过我见过太多人配置文件和命令全都正确最后因为云安全组或本地防火墙拦着哨兵之间互相看不到Quorum的天数永远凑不够白白浪费几个小时。2.3 Linux环境初始化关闭大页内存、设置内核参数如果你的Redis写入压力比较大还需要先处理几个Linux内核层面的参数否则高并发下会出现RT抖动甚至卡顿。这些是生产环境走了弯路才总结出来的虽然和哨兵本身没直接关系但顺手做掉没坏处。第一关闭透明大页THP。Redis官方文档里明确建议对透明大页禁用因为THP会在后台触发内存紧凑和内存移动导致突然的延迟尖峰。检查是否开启cat /sys/kernel/mm/transparent_hugepage/enabled输出always就要关闭echo never /sys/kernel/mm/transparent_hugepage/enabled同时写进/etc/rc.local或systemd服务里重启后仍然生效。第二修改vm.overcommit_memory为1哨兵和Redis在Fork子进程做持久化的时候需要一次性分配内存系统如果overcommit拒绝分配Fork会失败可能导致Redis直接退出。临时生效sysctl vm.overcommit_memory1持久化写进/etc/sysctl.confvm.overcommit_memory1 net.core.somaxconn1024第三net.core.somaxconn改成1024这是接收TCP连接队列的长度。Redis主线程处理短连接能力有限队列短了在高并发下会丢连接哨兵本身的连接也会受影响。做完这些就能专心配置Redis自身了。要想哨兵模式跑得稳底子要打好我搭建环境时习惯先在每台机器上执行一遍这三步再往下走。3. 一主两从复制链路搭建先把数据同步跑起来3.1 主节点redis.conf关键配置虽然哨兵会自动切换主从但初始状态下还是要有一个固定主节点和一个/多个从节点这是数据流的基础。先配置192.168.1.10上的主节点。我一般单独复制一份配置文件不直接用make install自带的redis.conf避免改错了影响全局。进入Redis源码目录mkdir -p /data/redis6379 cp redis.conf /data/redis6379/redis-6379.conf编辑配置文件下面这些是我实际用的关键项bind 0.0.0.0 port 6379 daemonize yes pidfile /var/run/redis_6379.pid dir /data/redis6379 logfile /data/redis6379/redis-6379.log appendonly yes appendfilename appendonly-6379.aof requirepass redisSecurePass2024 masterauth redisSecurePass2024bind 0.0.0.0意思是允许所有网卡访问生产环境按实际网段收紧为192.168.1.10也行但注意如果设成127.0.0.1哨兵从其他机器连接不了。dir配置文件存放路径和日志路径我习惯以端口命名好处是所有实例的文件一眼能对上号。appendonly yes开启AOF持久化比RDB更能保证故障切换后的数据完整性故障转移时新主节点如果只有RDB快照会丢更多数据。requirepass和masterauth这两项必须一起设置。requirepass是客户端认证密码masterauth是主从复制时从节点连接主节点的认证密码。很多人只配了requirepass忘记配masterauth结果是客户端能认证但从节点却复制不了数据日志里反复出现MASTER - REPLICA sync started却一直卡住。3.2 从节点配置与replicaof指令接下来在192.168.1.11和192.168.1.12上配置从节点。其实从节点的配置基本和主节点一致唯一不同的是多了replicaof这一行指向主节点的IP和端口。192.168.1.11上的相关配置bind 0.0.0.0 port 6379 daemonize yes dir /data/redis6379 logfile /data/redis6379/redis-6379.log appendonly yes appendfilename appendonly-6379.aof requirepass redisSecurePass2024 masterauth redisSecurePass2024 replicaof 192.168.1.10 6379 replica-read-only yesreplicaof指定了主节点的地址和端口从节点启动后会立刻向主节点发起握手和同步。replica-read-only yes让从节点只读避免客户端误写。这里补充一句Redis 5.0开始用replicaof旧版本是slaveof自己写配置时注意和版本对应起来。启动方式我用redis-server /data/redis6379/redis-6379.conf依次把三台节点启动起来然后用redis-cli -a redisSecurePass2024 -p 6379 info replication查看状态。3.3 验证复制状态info replication输出怎么看主节点上执行redis-cli -a redisSecurePass2024 -p 6379 info replication你会看到类似这样的输出# Replication role:master connected_slaves:2 slave0:ip192.168.1.11,port6379,stateonline,offset455,lag0 slave1:ip192.168.1.12,port6379,stateonline,offset455,lag0 master_replid:0f9a3b2aec32f457ab6f1b1e1c8d7a2e2c011c4a master_replid2:0000000000000000000000000000000000000000 master_repl_offset:455 second_repl_offset:-1 repl_backlog_active:1重点是connected_slaves:2说明两台从节点已经成功连接。slave0和slave1里的offset字段显示复制偏移量两个偏移量如果和主节点偏移量一样代表数据已经实时同步。还有一点看两个从节点的state是否为online如果显示broken多半是网络连不通或者masterauth配错。在任何一个从节点上执行同样的命令输出里的role应该是slave或replica并且能看到master_host和master_port字段。如果这一步验证没问题就说明1主2从的复制链路已经跑通。在进一步配置哨兵之前你还可以写一个测试key到主节点然后从节点上读一下直观确认数据同步没有障碍。到这里严格来说还没涉及“高可用”只是把基础的数据冗余链路做好了。但千万别小看这一步我见过有人跳过验证直接配置哨兵结果哨兵起来后切换方主节点上根本没有数据就是因为从节点复制链路压根没建立成功。4. 哨兵节点部署三个实例的配置模板与启动顺序4.1 sentinel.conf核心参数逐项解读哨兵进程可以通过redis-sentinel命令启动它本质上就是一个运行在特殊模式的Redis服务器。配置文件不再叫redis.conf而叫sentinel.conf。三个哨兵实例的配置几乎一样唯一的区别是port不同这里因为分了三台机器端口可以都用26379以及sentinel announce-ip需要指向各自的IP。先看基础模板以192.168.1.10为例port 26379 daemonize yes pidfile /var/run/redis-sentinel-26379.pid logfile /data/redis6379/sentinel-26379.log dir /data/redis6379 sentinel monitor mymaster 192.168.1.10 6379 2 sentinel auth-pass mymaster redisSecurePass2024 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000 sentinel parallel-syncs mymaster 1逐项拆解这里面的每个参数都代表一个决策sentinel monitor mymaster 192.168.1.10 6379 2监控的名字叫mymaster初始主节点是192.168.1.10的6379最后的数字2是quorum阈值表示至少2个哨兵同意主节点下线才会执行客观下线。注意这不是投票选举leader的票数只是“判定死亡的法定人数”。3个哨兵里quorum2意味着可以容忍1个哨兵故障这是最小的高可用容错组合。sentinel auth-pass mymaster redisSecurePass2024连接被监控Redis所需的密码。这里必须和Redis配置文件里的requirepass一致否则哨兵连不上Redis永远发现不了主节点。sentinel down-after-after-milliseconds mymaster 5000哨兵在5秒内没有收到主节点的有效回复就主观判定这个节点挂了。这个值要结合实际网络延迟设局域网内设5秒问题不大跨机房建议10秒以上否则公网抖动容易误判。sentinel failover-timeout mymaster 15000故障转移超时时间从开始故障转移到结束最多15秒。超过这个时间还没完成哨兵会再次重新选举。设得太短在重负载的机器上容易超时设得太长则业务中断时间变长。sentinel parallel-syncs mymaster 1故障转移完成后同时允许几个从节点向新主节点发起复制同步。设1意味着一次只有一个从节点同步最轻量但完成整个集群收敛的时间会长一点。设2或3同步速度更快但新主节点的磁盘IO和网络开销会陡增容易造成短时间内复制积压。4.2 三个哨兵实例的差异化配置三台机器上的哨兵配置大体相同但注意几个地方sentinel monitor mymaster 192.168.1.10 6379 2这一行在三个哨兵配置里保持一致都指向初始主节点IP。每个哨兵的port可以都用26379因为各自在不同的物理机上如果在一台机器上用三个哨兵模拟端口就要改成26379、26380、26381。每个哨兵配置里建议加上sentinel announce-ip指定本机的实际IP防止多网卡环境下哨兵之间广播的地址错误。192.168.1.11上的哨兵配置port 26379 daemonize yes pidfile /var/run/redis-sentinel-26379.pid logfile /data/redis6379/sentinel-26379.log dir /data/redis6379 sentinel monitor mymaster 192.168.1.10 6379 2 sentinel auth-pass mymaster redisSecurePass2024 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000 sentinel parallel-syncs mymaster 1 sentinel announce-ip 192.168.1.11192.168.1.12上的配置类似只把announce-ip改成192.168.1.12。这说明哨兵集群之间是通过相互通信来感知彼此存在的初始时它们都只知道mymaster的IP和端口彼此之间通过主节点上的__sentinel__:hello频道自动发现。所以如果第一个哨兵和第二个哨兵不能通过网络互相访问它们也能通过主节点中转最终发现彼此但如果主节点网络隔离了哨兵之间就彻底失联了这也是为什么生产环境把哨兵和Redis实例分开部署价值更大。4.3 启动与确认哨兵集群如何感知彼此启动顺序上我先启动三台Redis节点再逐个启动三个哨兵。哨兵启动命令/usr/local/bin/redis-sentinel /data/redis6379/sentinel-26379.conf或者用/usr/local/bin/redis-server /data/redis6379/sentinel-26379.conf --sentinel两者等价。推荐用第一种更明确这是哨兵服务。启动后查看日志cat /data/redis6379/sentinel-26379.log正常日志里会出现XRUN sentinel inited monitor master mymaster 192.168.1.10 6379 quorum 2 slave 192.168.1.11:6379 192.168.1.11 6379 mymaster 192.168.1.10 6379 slave 192.168.1.12:6379 192.168.1.12 6379 mymaster 192.168.1.10 6379 sentinel 1 mymaster 192.168.1.10 6379 sentinel 2 mymaster 192.168.1.10 6379在这里能看到哨兵不仅自动发现了两个从节点还通过发布订阅发现了另外两个哨兵。如果只有sentinel 1 mymaster一行说明第二个哨兵没有成功进入同一个监控组优先检查网络是否通了、quorum阈值是否一致。另外我在压测环境里遇到过多台哨兵的announce-ip配错导致哨兵互相发现不了后来在配置里显示加上announce-ip问题就解决了。验证哨兵认知状态可以用redis-cli -p 26379 sentinel master mymaster redis-cli -p 26379 sentinel slaves mymaster redis-cli -p 26379 sentinel sentinels mymastersentinel master会输出当前已知的主节点IP和端口sentinel slaves能列出所有从节点sentinel sentinels列出其他哨兵的信息。只要这三个命令输出的信息和你规划的一致哨兵集群就已经建立好了。5. 高可用验证手动杀掉主节点看哨兵怎样完成HA切换5.1 模拟主节点宕机的常用方法配置完毕后必须做一次真正的故障转移测试否则你把哨兵丢到生产环境心里一点底都没有。最常见的模拟方法是直接杀掉主节点上的Redis进程redis-cli -a redisSecurePass2024 -p 6379 shutdown nosave或者为了更贴近真实故障用kill -9杀死进程这样不会走正常关闭流程AOF也不落盘能模拟硬件掉电、进程直接崩溃的场景kill -9 $(cat /var/run/redis_6379.pid)执行完立即查看哨兵日志这是观察故障转移全过程的最好窗口。5.2 故障转移过程中的日志解读杀掉主节点后的5秒内日志顺序大概是sdown master mymaster 192.168.1.10 6379 odown master mymaster 192.168.1.10 6379 #quorum 2/2 try-failover master mymaster 192.168.1.10 6379 failover-state-select-slave master mymaster 192.168.1.10 6379 selected-slave slave 192.168.1.12:6379 192.168.1.12 6379 mymaster 192.168.1.10 6379 failover-state-send-slaveof-noone slave 192.168.1.12:6379 192.168.1.12 6379 mymaster 192.168.1.10 6379 failover-state-wait-promote-slave slave 192.168.1.12:6379 192.168.1.12 6379 mymaster 192.168.1.10 6379 promoted-slave slave 192.168.1.12:6379 192.168.1.12 6379 mymaster 192.168.1.10 6379 failover-state-reconf-slaves master mymaster 192.168.1.10 6379 slave-reconf-sent slave 192.168.1.11:6379 192.168.1.11 6379 mymaster 192.168.1.10 6379 slave-reconf-inprog slave 192.168.1.11:6379 192.168.1.11 6379 mymaster 192.168.1.10 6379 failover-end-for-timeout master mymaster 192.168.1.10 6379 failover-end master mymaster 192.168.1.10 6379 switch-master mymaster 192.168.1.10 6379 192.168.1.12 6379这段日志值得逐行解释一下。sdown代表某个哨兵主观认为主节点宕机紧接着odown出现意味着已经凑够quorum2客观下线成立。这说明多个哨兵之间信息同步成功了而不是只有一个哨兵在自嗨。然后进入try-failover说明开始执行故障转移。这里有一个关键机制并非所有哨兵都能发起故障转移而是会通过Raft协议选举出一个leader只有leader才能执行后续动作。日志里selected-slave告诉我们新主节点被选中为192.168.1.12的6379。选从节点时会根据优先级replica-priority、复制偏移量、运行ID排序来选择最合适的一个。所以平时可以把某个性能更好的从节点设置更低的replica-priority比如1其他配2这样切换时会优先选到它。再后面failover-state-send-slaveof-noone是让被选中的从节点断开与旧主节点的复制关系变成独立主节点。最后switch-master一行表示哨兵更新了自身的监控目标新主节点是192.168.1.12。所有客户端如果连接的是哨兵也应该通过哨兵拿到新主节点的地址。5.3 切换后的角色确认与业务主从关系更新故障转移完成后需要确认三件事情第一新主节点上角色是否正确redis-cli -a redisSecurePass2024 -p 6379 -h 192.168.1.12 info replication输出里role应该是master并且能看到另一个从节点192.168.1.11已经同步过来。第二原主节点恢复后是否自动变成从节点。重新启动192.168.1.10上的Redis进程然后查看它的日志或info replication会发现它已经变成role:slave并且指向192.168.1.12。这是哨兵的convert-to-slave过程它会在旧主恢复后自动发送replicaof命令确保集群收敛回1主2从的状态。第三验证哨兵视角下主节点是否已经更新。执行redis-cli -p 26379 sentinel master mymaster输出的ip和port字段应该指向192.168.1.12。如果一切正常说明哨兵模式已经真正具备自动故障转移能力。测试完成后如果你想把主节点切回192.168.1.10可以手动做一次failover触发redis-cli -p 26379 sentinel failover mymaster这条命令让哨兵立即执行一次故障转移不需要等待节点实际宕机。很多人在验证环境里都靠它来快速演示切换过程比杀进程要优雅得多。执行后再次查看日志和info replication一般几秒内主节点就会切回去。6. 生产环境必须避开的坑脑裂、密码、网络超时6.1 哨兵与Redis认证requirepass和sentinel auth-pass的正确联动如果你给Redis配了requirepass但哨兵的sentinel auth-pass没写或者写错了日志里会持续出现-DOWN master mymaster 192.168.1.10 6379这不是节点真的挂了而是哨兵无法通过认证发起的PING被Redis拒绝。这个坑让我栽过一次——当时主从复制一切正常客户端也没问题但哨兵状态一直是sdown后来发现是sentinel auth-pass里有一个特殊字符没转义导致密码错了。另外如果从节点将来会升级为主节点它的masterauth也必须保存原密码这样才能让新从节点正常连接不然切换之后新的主节点无法接受其他从节点的复制请求。6.2 主观下线与客观下线的阈值设置别让误判拖垮业务sentinel down-after-milliseconds的值是哨兵判断节点是否存活的关键。设太长故障转移慢业务中断时间长设太短网络瞬时抖动就会让哨兵误判。我通常建议内网环境5000ms起步跨机房或公网环境10000-15000ms宁可牺牲一点点切换速度也不要因为误判高频切换。故障转移本身是有成本的——每次切换都会重置主从关系、重新同步数据频繁误切比偶尔宕机危害更大。另外注意failover-timeout也需要结合实际调。我之前在压测时设置30000ms但某次从节点数据量大同步超时哨兵在故障转移中重复尝试把切换时间拖到了快两分钟。后来把parallel-syncs调小、failover-timeout调大问题才缓解。6.3 脑裂场景剖析为什么仲裁数必须过半所谓脑裂Split Brain是指在网络分区时原本只有一个主节点却同时出现两个主节点都认为自己才是合法主节点。哨兵通过quorum机制尽量防止这种情况3个哨兵quorum2意味着只有至少2个哨兵一致认为主节点挂了才允许切换。如果网络分区把主节点和两台从节点分开但三个哨兵仍能互相通信那么当主节点联系不上其他哨兵的一半时不会满足客观下线条件因为quorum需要2/3此时哨兵不会发起切换旧主节点在分区隔离区外被暂时“孤立”避免了两个主节点同时写入产生数据冲突。但是脑裂在极端场景下仍然可能发生——比如旧主节点所在的网络分区仍能访问部分哨兵同时又不满足客观下线条件。这时旧主节点可能继续接受写入但哨兵已经选了新主节点恢复后两个主节点的数据就不一致了。生产应对方案通常是保证哨兵数量为奇数至少3个避免偶数节点导致quorum无法判定在客户端配置里让哨兵来决策主节点地址而不是硬编码IP设置合理的min-replicas-to-write和min-replicas-max-lag参数主节点在从节点不足时拒绝写入降低脑裂期间的数据丢失范围。6.4 我踩过的几个低级错误数据丢失、配置覆盖最后简单分享几个我实际踩过的坑每个都花了不少时间排查。第一哨兵配置被动态覆盖。Sentinel在运行中会频繁修改自己的sentinel.conf文件它会记录当前的epoch、发现的从节点、其他哨兵信息等。如果你在配置里写了旧地址一旦哨兵重写配置它会自动把新地址写进去。我在测试时直接改配置文件想改监控地址重启后发现里面被写入了乱七八的旧信息后来才明白正确做法是使用sentinel monitor命令动态修改而不是手工编辑重启。第二所有进程都在一台机器上模拟多实例时端口冲突极其隐蔽。比如把三个哨兵的logfile和dir写成了同一个路径日志互相覆盖排查起来一头雾水。建议每个实例的日志文件、pid文件、持久化目录全部独立最好用端口号做目录名区分。第三防火墙只放行了6379没放行26379结果最终失败转移时哨兵之间无法通信quorum永远算不出。这个问题只有在做完故障转移测试时才暴露出来事后想想最应该做的就是配置完哨兵后我先用telnet测一下26379端口通不通。总结下来哨兵模式不是搭完就完事的它需要你认真设计阈值、经常做切换演练并且理解它背后每个参数的含义。我在生产环境用了这套架构几年从Redis 4.x升级到6.x最明显的感受是哨兵模式解决的是自动化运维部分真正考验你的还是对原理的理解和运维习惯。前面这几节提到的每个坑都是我实际遇到过、搜集过资料、最后通过日志一点点排查出来的。如果你在搭建过程中遇到类似问题不妨先从哨兵日志和sentinel master输出下手它们会直接告诉你答案。