团队有段时间天天被线上 Redis 单点问题折腾主节点一宕机整个应用层跟着雪崩半夜爬起来手动切从库的日子真的够呛。后来花了两天时间把 Redis 哨兵集群完整落地从主从复制到三节点哨兵再到故障演练和客户端接入整个过程踩了不少坑也把 Sentinel 的机制摸了个透。这篇文章就完整复盘这次搭建过程从原理到实操再到排障希望能帮同样被单点问题困扰的人少走弯路。1. 项目定位哨兵集群到底解决了什么问题1.1 单机与裸主从的痛点先看我们当时的状态。线上只有一个 Redis 实例读写都走它数据量不算大但业务对 Redis 的依赖度极高缓存、分布式锁、热点数据全在里面。单机的问题很直白宕机即全部不可用磁盘故障直接丢数据而且容量和性能都被锁死在一台机器上。后来加了主从复制主节点负责写从节点负责读和备份。这确实解决了部分问题读压力被分摊了数据也有了副本。但裸主从有个致命短板——主节点挂了以后从节点不会自动上位。从库明明有全量数据却只能眼睁睁等人工干预。DBA 手动执行slaveof no one把某个从库提升为主库再把其他从库重新指向新主库这个过程涉及修改配置、重启服务快则几分钟慢则十几分钟业务损失已经造成了。所以我们真正需要的是一个能自动感知主节点故障、自动完成从库晋升、自动通知所有客户端更新连接信息的机制。这就要靠哨兵集群来兜底。1.2 为什么用哨兵而不是直接上 Cluster很多人会有这个疑问既然 Redis 官方有 Cluster 集群模式为什么还要用哨兵这俩解决的确实不是同一个问题。Redis Cluster 面向的是数据分片它把数据按照 slot(哈希槽) 分布在多个主节点上每个主节点又有自己的从节点做冗余解决的是单机存不下、写不动的横向扩容问题。而哨兵模式面向的是高可用它的前提是仍然有一个主节点承担全部写请求可以配多个从节点分担读请求哨兵做的事情是如何在主机故障时快速恢复写入能力。选择哪个取决于业务规模。我们线上的数据量和 QPS 还没到必须分片的程度一个主节点完全扛得住写压力多挂几个从节点分摊读就够了。这类场景用哨兵模式明显更轻量架构简单客户端接入也不需要感知 slot 路由规则。如果用 Cluster单节点内存动辄 10GB 的存量数据做分片迁移纯属给自己找事。所以结论是数据没到分片规模优先上哨兵到了分片规模再考虑 Cluster 或者分库分表。2. 哨兵的核心机制拆解2.1 三阶段运作逻辑监控、通知、自动故障转移Sentinel 本质上是一个运行在特殊模式下的 Redis 服务。它不存业务数据专门做三件事监控持续检查主节点和从节点是否存活。这个存活不是简单 ping 一下而是通过一套主观下线SDOWN和客观下线ODOWN机制来判定。通知当被监控的 Redis 节点状态发生变化时哨兵可以通过发布订阅、脚本等方式通知运维或应用程序。自动故障转移当主节点被多数哨兵判定为客观下线时触发切换流程。从健康的从节点中选出一个提升为新主节点再把其他从节点的复制目标指向新主节点最后通知客户端新主节点的地址。这个过程和人类社会处理领导失联很像哨兵就是监事会平时盯着管理层状态一旦确认一把手彻底失联就按预案从备选干部里挑一个顶上再让所有人重新向他汇报。关键是不需要人出面拍板全靠投票规则自动执行。2.2 主观下线与客观下线的区别主观下线sdown是单个哨兵根据自己的检测结果做出的判断。每个哨兵每隔 1 秒可以配置向主从节点发送 ping 命令当在down-after-milliseconds指定的时间内没有收到有效回复这个哨兵就把该节点标记为主观下线。客观下线odown则是由哨兵集群协商出来的结论只在主节点判定上有意义。当某个哨兵认为主节点主观下线后它会向其他哨兵节点发送SENTINEL is-master-down-by-addr命令询问对方的看法。当超过 quorum 数量的哨兵都认为主节点不可达时才真正确认主节点客观下线从而触发故障转移流程。举一个典型场景三节点哨兵quorum 配置为 2此时哨兵 A 发现与主节点通信超时它会发消息询问哨兵 B 和 C只要至少一个也确认主节点无法连接就达成共识进入切换流程。这个设计避免了单点误判——比如主节点只是网络抖动一台哨兵误以为它挂了而另外两台认为它没问题那就不会贸然切换。2.3 领导者选举与投票机制一旦确认主节点客观下线哨兵集群还需要选出代表来执行故障转移操作这个代表被称为 leader。选举底层用的是 Raft 算法每个哨兵都可以给自己投票然后拉票得票超过半数超过哨兵总节点数的一半注意不是 quorum的哨兵成为 leader。这里有个必须记牢的坑如果哨兵集群只有两个节点quorum 设置 1 或者 2都可能出现脑裂问题或者无法完成切换。比如两节点中一台哨兵宕机剩下一个哨兵想发起切换但它无法凑齐超过半数的票切换就失败了。所以哨兵节点数量必须是奇数至少 3 个这是生产环境的硬性要求。3. 搭建前的准备3.1 节点规划与架构设计建议的部署方式是把哨兵和 Redis 数据节点分机部署。因为哨兵的内存、CPU 占用都不高如果机器资源紧张也可以混部但生产环境还是尽量隔离。我们的原部署是3 台 Redis 数据节点1 个主节点master2 个从节点slave1、slave23 台哨兵节点sentinel-1、sentinel-2、sentinel-3Redis 数据节点之间走主从复制哨兵节点则监控这些数据节点。哨兵的三台机器组成集群彼此之间通信通过投票机制决策。之所以是三哨兵而不是三数据节点是因为哨兵集群的可用性决定了故障转移流程的可用性宁可数据节点少一个哨兵节点也不能省。端口规划方面默认情况下Redis 数据节点端口6379哨兵节点端口26379版本方面我们用了 Redis 6.2.x较新的特性是对 ACL 支持更好同时replicaof指令已经替代了旧的slaveof虽然slaveof仍可用。建议至少用 5.0 以上的版本哨兵机制本身差别不大但高版本修复了很多稳定性问题。3.2 Redis 安装与基础配置安装方式我推荐直接编译安装虽然二进制发行版也有但编译安装可以精确控制版本和参数方便用redis-server --version验证。步骤如下wget https://download.redis.io/releases/redis-6.2.14.tar.gz tar -zxvf redis-6.2.14.tar.gz cd redis-6.2.14 make make install PREFIX/usr/local/redis编译完成后二进制文件在/usr/local/redis/bin下。建议把redis-server、redis-sentinel、redis-cli都加入环境变量或用 ln 做软链接到/usr/local/bin。主从节点的 redis.conf 关键配置如下# 主节点 redis.conf bind 0.0.0.0 protected-mode no port 6379 daemonize yes dir /data/redis pidfile /var/run/redis_6379.pid logfile /var/log/redis/redis.log appendonly yes appendfsync everysec # 从节点 redis.conf 额外增加 replicaof 192.168.1.101 6379这里有几个点要强调。bind 0.0.0.0在生产环境要小心如果机器有公网 IP暴露出去是会被攻击的。我们是在内网环境且加了防火墙白名单才这么配。protected-mode no同理。如果 Redis 设置了密码从节点的复制配置还需要加上masterauth因为从节点连主节点做全量同步或增量同步时需要带密码认证。我们在实际配置中用的是requirepass your_strong_password masterauth your_strong_passwordmasterauth在主节点上其实也应该配上因为它有可能在故障转移后变成从节点到时候它也需要带着密码去连新主节点。这个细节很多人会漏掉导致切换成功后复制链路建立失败。3.3 主从复制初始化与验证启动顺序是先主后从。分别启动三个 Redis 实例后登录从节点执行redis-cli -h 192.168.1.102 -p 6379 -a your_password info replication正常情况下能看到# Replication role:slave master_host:192.168.1.101 master_port:6379 master_link_status:up slave_repl_offset:12345master_link_status:up表示复制链路正常。另外还有一个容易忽略的检查项是主从之间的延迟。可以看master_repl_offset和slave_repl_offset的差值正常情况下主从延迟非常小如果差值持续拉大说明网络或者从节点的处理能力有瓶颈。4. 三节点哨兵集群部署4.1 哨兵配置文件详解哨兵配置文件的核心内容可以这样理解它告诉哨兵进程监控谁、怎么判死、切换策略是什么。我们的 sentinel.conf 配置文件如下bind 0.0.0.0 port 26379 daemonize yes dir /data/redis-sentinel logfile /var/log/redis/sentinel.log # 监控的主节点名称、IP、端口、quorum sentinel monitor mymaster 192.168.1.101 6379 2 # 主节点密码 sentinel auth-pass mymaster your_strong_password # 哨兵实例间通信密码Redis 6.2 以上支持 sentinel auth-user mymaster default # 判定主节点主观下线的阈值毫秒 sentinel down-after-milliseconds mymaster 5000 # 故障转移超时时间毫秒 sentinel failover-timeout mymaster 15000 # 故障转移时允许从新主节点同步数据的从节点最大数量 sentinel parallel-syncs mymaster 1逐个解释关键参数。sentinel monitor mymaster 192.168.1.101 6379 2这个配置里的最后一个数字 2 就是 quorum代表至少有 2 个哨兵认为主节点不可达才判定客观下线。注意这里 quorum 是确认下线的阈值和执行故障转移所需的 leader 票数是两个概念。down-after-milliseconds 5000表示哨兵连续 5 秒联系不上主节点就标记为主观下线。这个值不宜过大也不宜过小。太大会导致故障发现慢业务长时间不可写太小则容易因为网络抖动引发误切换。生产环境建议 10 秒左右起步我们最开始配的 5 秒后来发现偶尔网络抖动会让主节点被误判于是调到了 10000。failover-timeout 15000表示一次故障转移的总体超时时间包括选举、从节点同步等所有步骤。如果切换过程超过这个时间哨兵会认为切换失败重新发起下一轮选举。parallel-syncs 1表示故障转移后同一时刻只允许 1 个从节点跟新主节点做复制同步。如果配置成 2 或 3多个从节点同时全量同步如果数据量大会瞬间把新主节点的带宽打满导致新主节点也出问题。4.2 启动哨兵并验证集群感知三个节点都写好各自的 sentinel.conf 后注意监控的 IP 都是同一个主节点用下面的命令启动redis-sentinel /etc/redis/sentinel.conf # 或用 redis-server 以哨兵模式启动 redis-server /etc/redis/sentinel.conf --sentinel启动后马上检查日志。正常的话每个哨兵都会发现监控的主节点和其他哨兵的存在13:32:11.123 * Sentinel started. 13:32:11.456 monitor master mymaster 192.168.1.101 6379 quorum 2 13:32:12.101 slave slave 192.168.1.102:6379 192.168.1.102 6379 mymaster 192.168.1.101 6379 13:32:12.102 slave slave 192.168.1.103:6379 192.168.1.103 6379 mymaster 192.168.1.101 6379 13:32:13.890 sentinel sentinel 4f3a8f6f0c1f0b2d2a0f8c1e2e3d4a5b6c7d8e9 192.168.1.202 26379 mymaster 192.168.1.101 6379看到类似日志说明哨兵已经互相发现并建立通信。再用redis-cli -p 26379 sentinel master mymaster查看主节点状态关键的几个字段包括num-slaves从节点数量num-sentinels哨兵节点数量flags主节点标记正常情况下是master如果变成s_down或o_down就说明有节点判定它下线了另外在任意哨兵节点上执行下面命令都能看到当前哨兵集群的成员列表redis-cli -p 26379 sentinel sentinels mymaster4.3 哨兵之间的相互感知机制哨兵集群没有单独的注册中心它的节点发现机制利用了 Redis 的发布订阅功能。每当一个哨兵实例启动并连上主节点后它会在__sentinel__:hello这个频道上发送自己的信息所有连接到同一个主节点的哨兵都能收到。通过这种方式三台哨兵即使各自的配置文件里没有写明其他哨兵的地址也能互相发现并维护一个完整的哨兵节点列表。这个机制的好处是部署非常方便只需要保证每个哨兵都监控同一个主节点即可。缺点是需要依赖主节点的发布订阅通路来交换信息这也是为什么哨兵配置里必须要有主节点的正确地址并且哨兵之间不能完全网络隔离。5. 故障转移实操演练5.1 模拟主节点宕机配置全部就绪后最关键的一步是验证故障转移真的能工作。我们选了业务低峰期做故障演练目的是确认三个问题主节点宕机后哨兵能否在预期时间内完成切换、从节点能否自动同步到新主节点、客户端能否自动感知并恢复写入。模拟方式有三种直接杀进程、模拟网络隔离、暴力断电。杀进程最直接redis-cli -p 6379 -a your_password shutdown nosave # 或者更恶意一点直接 kill -9模拟进程崩溃 kill -9 redis-server的pid用kill -9模拟的效果最接近真实故障。执行完之后立刻在哨兵节点上观察日志。预期流程如下13:40:00.001 sdown master mymaster 192.168.1.101 6379 13:40:00.452 odown master mymaster 192.168.1.101 6379 #quorum 2/2 13:40:00.453 new-epoch 1 13:40:00.454 try-failover master mymaster 192.168.1.101 6379 13:40:00.510 vote-for-leader 4f3a8f6f0c1f0b2d2a0f8c1e2e3d4a5b6c7d8e9 13:40:00.521 elected-leader master mymaster 192.168.1.101 6379 13:40:00.522 failover-state-select-slave master mymaster 192.168.1.101 6379 13:40:00.600 selected-slave slave 192.168.1.102:6379 192.168.1.102 6379 mymaster 192.168.1.101 6379 13:40:00.601 failover-state-send-slaveof-noone slave 192.168.1.102:6379 192.168.1.102 6379 mymaster 192.168.1.101 6379 13:40:00.902 failover-state-wait-promotion slave 192.168.1.102:6379 192.168.1.102 6379 mymaster 192.168.1.101 6379 13:40:01.203 promoted-slave slave 192.168.1.102:6379 192.168.1.102 6379 mymaster 192.168.1.101 6379 13:40:01.205 failover-state-reconf-slaves master mymaster 192.168.1.101 6379 13:40:01.308 slave-reconf-sent slave 192.168.1.103:6379 192.168.1.103 6379 mymaster 192.168.1.101 6379 13:40:01.606 slave-reconf-inprog slave 192.168.1.103:6379 192.168.1.103 6379 mymaster 192.168.1.101 6379 13:40:03.208 slave-reconf-done slave 192.168.1.103:6379 192.168.1.103 6379 mymaster 192.168.1.101 6379 13:40:03.160 failover-end master mymaster 192.168.1.101 6379 13:40:03.160 switch-master mymaster 192.168.1.101 6379 192.168.1.102 6379 13:40:03.161 sdown slave 192.168.1.101:6379 192.168.1.101 6379 mymaster 192.168.1.102 63795.2 切换过程深度解读上面的日志就是整个故障转移的完整时间线。我来拆解关键节点第 1 行sdown哨兵自己判定主节点主观下线。这个发生在down-after-milliseconds超时之后。第 2 行odownquorum 2/2两个哨兵都确认主节点无法连接达成客观下线共识。第 4 行try-failover哨兵集群开始尝试故障转移。第 6 行vote-for-leader哨兵之间开始选举 leader日志里的 hex 字符串就是 leader 哨兵的 runid。第 8 行selected-slaveleader 从健康的从节点列表中选出新主节点。选举的优先级顺序是 slave-priority 配置值越小越优先然后看复制偏移量是否最新最后看 runid 的字典序。我们统一把从节点的slave-priority设置为 100没有单独调低过所以当时选出的是偏移量更新的 102 节点。第 9 行failover-state-send-slaveof-noone向选中的从节点发送replicaof no one让它脱离原主节点成为独立主节点。第 11 行promoted-slave确认从节点已成功晋升。第 12 行failover-state-reconf-slaves开始让其他从节点重新指向新主节点。第 15 行switch-master整个切换完成新的主节点变成 192.168.1.102。整个过程从 sdown 到 switch-master耗时约 3 秒。这个时间可以接受但对于写敏感的在线业务仍可能造成若干秒写入中断。如果想缩短可以把down-after-milliseconds调小但代价是误判概率增加。这是一个必须做的权衡。5.3 旧主恢复后的重新加入演练时我们故意保留了一段时间不恢复旧主节点。等切换完成后再把旧主节点重新启动看它会以什么身份加入集群。预期行为是旧主节点启动后发现集群中已经存在新的主节点它会自动执行replicaof把自己变成新主节点的从节点重新挂载到新的复制链路下。这个自动降级行为靠的是哨兵向旧主节点发送重新配置命令。观察日志会看到convert-to-slave slave 192.168.1.101:6379 192.168.1.101 6379 mymaster 192.168.1.102 6379意思是旧主节点 101 已转换为从节点复制新主节点 102 的数据。这里有一个细节需要提醒旧主节点上的旧数据在恢复后会首先做一次全量同步把新主节点的数据完整拉过来。如果新主节点在切换期间写入了大量新数据全量同步的时间和带宽占用会比较可观。所以在切换期间不要让旧主节点以读写模式继续接受业务流量否则切换完成后的数据回刷会造成短暂的不一致。我们当时在切换前就把旧主节点的访问从负载均衡上摘掉了避免这个问题的干扰。6. 客户端连接与验证6.1 客户端连接哨兵的两种方式故障转移完成后客户端需要感知新主节点的地址否则应用还是往旧地址写必然失败。客户端接入哨兵集群有两种典型方式。第一种是直接连哨兵。大多数官方客户端都实现了 Sentinel 模式比如 Java 的 Lettuce、JedisPython 的 redis-pyNode 的 ioredis。应用先连哨兵节点通过SENTINEL get-master-addr-by-name master-name拿到当前主节点的地址然后建立真实连接。同时客户端会订阅哨兵的发布订阅频道一旦主节点发生切换哨兵会推送新主节点地址客户端自动断开旧连接、建立新连接。第二种是通过代理或负载均衡。接入层用 HAProxy、LVS 等方式做抽象后端指向哨兵维护的动态 VIP切换时通过脚本更新。这种方式更适用于老旧的客户端或不想改代码的场景但运维复杂度高一些我们当时用的 Lettuce直接走第一种方式。6.2 实际代码接入示例下面是一个 Spring Boot 项目通过 Lettuce 连接哨兵集群的配置方法。先定义一个哨兵模式的 RedisConnectionFactoryBean public RedisConnectionFactory redisConnectionFactory() { RedisSentinelConfiguration sentinelConfig new RedisSentinelConfiguration() .master(mymaster) .sentinel(192.168.1.201, 26379) .sentinel(192.168.1.202, 26379) .sentinel(192.168.1.203, 26379); sentinelConfig.setPassword(RedisPassword.of(your_strong_password)); return new LettuceConnectionFactory(sentinelConfig); }注意master(mymaster)的值要和 sentinel.conf 里的sentinel monitor mymaster ...保持一致否则哨兵集群不知道该返回哪个主节点。这个坑我们踩过一次配置文件里写的redis-master代码里写的mymaster启动后一直报Unable to connect to Redis master。Java 客户端本身不具备感知哨兵的能力它也是向哨兵发命令获取主节点地址然后建立连接。但它和直连主节点的差异在于连接是懒建立的每次获取连接时都向哨兵询问当前主节点所以切换期间已经建立的连接可能短暂不可用新的连接请求会立即指向新主节点。因此应用层面要做合理的重试策略。Python 端同样很简单from redis.sentinel import Sentinel sentinel Sentinel([(192.168.1.201, 26379), (192.168.1.202, 26379), (192.168.1.203, 26379)], socket_timeout0.5) master sentinel.master_for(mymaster, socket_timeout0.5) slave sentinel.slave_for(mymaster, socket_timeout0.5) master.set(foo, bar)6.3 验证客户端自动切换能力接入完成后我们做了一次端到端测试应用持续向 Redis 写数据同时手动杀掉主节点进程观察应用是否自动恢复写入。从客户端日志看先是连接异常报错刷屏紧接着哨兵推送新主节点地址应用自动重连从断写开始到恢复耗时约 5 秒左右。其中有约 2 秒是哨兵判定下线的等待时间。这个测试提醒我们一个关键点客户端必须有连接池和重试机制。在哨兵切换的窗口期所有向旧主节点发起的写请求都会失败。Lettuce 默认的共享连接在切换后会自动重连但应用层如果没有任何重试失败的请求照样会导致业务报错。因此建议在 Service 层对 Redis 操作做 AOP 层重试或者引入 spring-retry重试两到三次基本能覆盖切换窗口。7. 常见问题与运维排障记录7.1 高并发排障速查表在实际运行过程中我们遇到了不少问题。整理成速查表方便大家快速定位。现象可能原因排查方法哨兵无法启动配置文件权限或格式错误用redis-check-rdb或直接尝试redis-server sentinel.conf --sentinel前台启动看报错信息哨兵日志显示主节点 sdown但没有继续切换quorum 未达成或哨兵之间网络隔离检查sentinel sentinels mymaster输出确认哨兵节点互相可见故障转移后新主节点没有接管写请求客户端没有走哨兵模式仍直连旧 IP检查应用配置确认连接工厂用的是 Sentinel 模式切换完成后从节点复制失败masterauth 密码不一致在从节点执行info replication检查master_link_status如果 down查看错误日志修正 masterauth哨兵日志大量仲裁日志主节点频繁抖动down-after-milliseconds配置过小适当调大该参数同时检查网络抖动原因切换后数据不一致故障期间旧主节点仍接受了写请求用 Sentinel 的min-replicas-to-write机制限制主节点在从节点不足时拒绝写入哨兵进程频繁重启daemonize 和 supervised 模式冲突正确配置 supervised 为 systemd避免重复拉起这里额外说一个容易被忽略的点min-replicas-to-write。Redis 主从复制的默认行为是即使从节点全部失联主节点依然可以正常写入。这在主节点网络分区但自身存活时会埋下可怕的隐患——一边旧主节点还在接收写入另一边哨兵已经把某个从节点提升为新主节点两边的数据都在增长等网络恢复后旧主节点降级为从节点它多写的数据会被全量覆盖丢弃造成大量数据丢失。要规避这个问题可以在主节点配置min-replicas-to-write 1 min-replicas-max-lag 5含义是至少有 1 个从节点与主节点的复制延迟在 5 秒以内才允许主节点处理写请求。当从节点全部掉线时主节点自动进入只读保护模式写请求被拒绝。这个配置的代价是牺牲了一定可用性但换来了数据一致性的底线。7.2 实际踩坑经验实录第一个坑是哨兵配置文件在启动后被自动重写。哨兵运行期间会维护一个已知状态的持久化文件也就是配置里的dir目录下的 sentinel.conf 文件本身。它启动后会自动修改这个文件记录当前 epoch、已知的哨兵节点地址、切换后的主节点地址等。这意味着如果你想手动改 sentinel.conf 然后再重启哨兵需小心它会覆盖掉你的修改。正确的做法是改完配置后先让哨兵正常关闭redis-cli -p 26379 shutdown再启动或者修改后用SENTINEL SET命令在线更新。第二个坑是系统 cron 里如果有 redis 进程守护脚本会在故障转移时顺手把降级的旧主节点拉起来。我们线上有一个巡检脚本检测 Redis 进程是否存在如果发现进程没了就自动拉起。演练时旧主节点宕机后脚本把它重新拉起来此时它已经是被哨兵降级的从节点了但由于我们手动把它从负载均衡摘掉了问题不大。但如果是没人值守的自动拉起旧主以从节点身份恢复后如果它配置里写死的是replicaof 旧主IP它会在新主节点和旧配置之间反复横跳非常难排查。这个坑的教训是要么彻底关掉自动拉起要么把自动拉起脚本改成调用哨兵 API 查询当前角色后再决定。第三个坑是哨兵节点上的时间同步问题。三台哨兵如果系统时间漂移太大会让主观下线的判定和选举超时出现偏差。我们当时有一台虚拟机时间长飘了 30 秒结果哨兵日志里经常出现同一事件在不同节点上时间先后错乱导致判断逻辑互相矛盾。解决办法是给所有节点统一配置 NTP 时间同步服务。第四个坑是故障转移后应用缓存了主节点地址。我们的一个老服务用了 Jedis但走的是直连主节点模式没有接哨兵。主节点切换后这个服务一直连旧 IP连接失败后也没有自动更新主节点信息的能力。排查了很久才定位到问题根源。如果碰到这类历史遗留系统最稳妥的方式是给主从节点绑定 VIP切换时通过哨兵脚本动态漂移 VIP防止客户端感知地址变化。7.3 运维自动化和监控建议搭建完哨兵集群后运维层面的工作并没有结束监控才是保障高可用持续有效的手段。建议至少做好两件事一是监控哨兵自身状态。哨兵节点都挂了相当于守护者失明集群的自动故障转移能力归零。对哨兵进程、26379 端口、以及SENTINEL master mymaster命令能否正常返回结果做探活监控。二是关注切换事件。故障转移不应该频繁发生一旦发生就说明有节点真的出问题了。把哨兵日志接入 ELK 或者用 Prometheus 采集 Redis exporter 的指标在主节点发生切换时报警运维人员需要知道切换为什么发生避免下次真故障时机器处于不健康状态却无人感知。8. 一次演练后的性能与稳定性验证8.1 读流量分担策略哨兵模式下从节点天然可以用来分担读流量。主节点负责写从节点负责读业务侧通过客户端把读请求打到从节点上。Java 的 Lettuce 中可以通过ReadFrom.REPLICA_PREFERRED策略让读取优先走从节点LettuceClientConfiguration config LettuceClientConfiguration.builder() .readFrom(ReadFrom.REPLICA_PREFERRED) .build();这个策略的好处是如果从节点都不可用它自动回退到主节点读取不会让读请求全部失败。但要思考一个语义问题Redis 主从复制是异步的从节点的数据可能滞后主节点几百毫秒。如果业务对读一致性要求很高比如刚写入立刻就要读到从节点分担读策略就会出问题。我们的做法是按业务区分允许一定延迟的缓存读走从节点要求强一致的数据只走主节点。8.2 压测和容量评估切换验证通过后我们顺手做了一轮轻量压测。单从节点读写混合场景下QPS 在 5 万左右时延迟还在几毫秒内当从节点数量增加到两个时整体读吞吐量有明显提升。哨兵本身的额外开销很小它和 Redis 数据节点之间的通信频率是每秒一次 ping对数据节点几乎没有性能影响。有一个容量评估上的建议哨兵模式没有解决写容量上限的问题。主节点的写能力仍是集群的瓶颈如果业务增长导致写入 QPS 到顶就得考虑升级到 Redis Cluster 或者分库分表。所以在设计架构时要把哨兵集群看作高可用方案而不是水平扩展方案。9. 关于这套架构的一点总结思考9.1 什么场景最适合哨兵集群运行了这么长时间我对哨兵集群的适用场景有了更具体的判断。最适合的场景有三个特征数据量在单机可容纳范围内、写多读少或读写比例适中、对自动故障转移要求高但不需要分片。如果数据量超过单机物理内存哨兵集群就无能为力了因为即使把所有从节点加进去每个节点都要存全量数据这是哨兵模式的天然限制。此时不如直接用内存淘汰策略或者引入分片逻辑然后再考虑 Cluster。对中小团队来说哨兵模式是 Redis 高可用的最佳起点。它不要求额外引入复杂的代理层、路由层官方客户端支持成熟运维学习成本低。但一定要记住哨兵不是万能药它对主节点的写能力没有提升对数据容量没有扩展核心价值只有一个——在主节点故障时把不可用的窗口从人工介入的十几分钟压缩到自动切换的几秒钟。9.2 未来演进方向如果业务量继续增长下一步完全可以平滑过渡到 Redis Cluster。Cluster 本身就内嵌了主从复制和故障转移机制不需要外部哨兵。但切换过程不是换一个参数就能完成的需要重新规划分片策略、槽位分配、客户端升级、数据迁移等。另一个演进方向是加一层缓存代理把客户端从 Redis 的变更中解放出来运维对主从切换、集群扩缩容都可以透明处理。不过这个方案引入了新的依赖和单点风险优势是业务侧代码基本零改动。归根结底架构没有最优解只有最合适的解。哨兵集群搭建完成只是起点后续的运维精细程度、故障应对预案、容量趋势评估才真正决定线上 Redis 的稳定水位。这次搭建完哨兵后我们最大的感受是别再让运维同学半夜爬起来手切主从了先把自动化和高可用交给哨兵把人的精力留给更重要的事。