凌晨两点半线上 Redis 主库突然挂了。没有哨兵的情况下值班同学的完整操作流程是这样的先被监控告警吵醒然后登录服务器从一堆从库里挑一个数据最新的执行SLAVEOF no one再手动把剩下从库的复制关系挨个指向新主库最后还要改客户端连接地址、重启服务。运气好十分钟搞完运气差折腾半小时中间任何一步手抖就是二次事故。哨兵Sentinel就是来根治这个流程的。它专门盯着你的 Redis 主库和从库一旦确认主库联系不上不需要人下指令自己选一个从库升为主库再通知其他从库和新主库建立复制关系同时把变更事件广播出去。这是 Redis 官方提供的高可用方案也是从“单点故障”迈向“自动化容灾”最基础的一步。这篇内容适合刚把主从复制跑起来、想进一步解决自动切换的运维和开发同学文章会从配置、原理、坑、落地经验四个角度把哨兵讲透。1. 为什么需要哨兵主从模式的高可用短板1.1 主从复制到底解决了什么问题先回头看看主从复制本身。Redis 主从复制解决的是“读容量”和“备份”问题主库扛写从库同步数据后扛读还能拿从库做日常备份主库出问题时从库里好歹有一份数据。很多团队第一套 Redis 架构就是“一主两从”这个阶段 Redis 的稳定性已经比单机强不少。但这里有个现实问题复制是单向的、异步的从库只认一个主库。主库宕机后从库不会自动接盘它只会持续尝试连接旧主库数据停在宕机前的复制位点。对外表现就是主库一挂所有写请求全部失败读请求如果也没做读写分离分流同样失败。从库们像一群等着队长归队的士兵队长没回来谁也不动。这个阶段的高可用是“半自动”的。所谓半自动就是哨兵还没有介入系统的人肉 SRE 就是哨兵。值班人员要先判断主库是彻底宕机还是网络抖动再从从库里面挑一个复制延迟最小的手动提升再调整其他从库和客户端的指向。做过一次人都知道手忙脚乱时还要操作命令行非常容易出错。1.2 从手动切换到自动切换手动切换最大的问题不是操作复杂而是“决策慢”。网络抖动、主库进程崩溃、宿主机宕机三种场景的处理方式都不一样人要在告警信息里快速判断这对晚间和节假日值班特别不友好。哨兵做的事情就是把“监控、决策、执行”三个环节全部自动化。它持续探测主从节点的健康状况一旦判定主库不可用自动完成“选新主、改从属关系、通知客户端”的完整流程。整个切换过程通常可以控制在十几秒到几十秒量级前提是参数配置合理。这也是为什么我建议哪怕你的 Redis 集群规模不大只要对可用性有要求都应该上哨兵。一套三节点的哨兵部署成本极低但它能把全人工的故障恢复流程变成全自动RTO恢复时间目标直接从“看人脸色”变成“看参数配置”。1.3 哨兵是什么、不是什么简单说哨兵本身也是一个 Redis 服务只是以特殊模式运行默认端口 26379。它不存储业务数据主要工作就是监控 Redis 数据节点并执行高可用决策。这里必须厘清两个容易混淆的点哨兵不是 Redis Cluster。Redis Cluster 解决的是数据分片和横向扩展哨兵解决的是单分片内的主从自动切换。一个主从组一套哨兵数据量大了主从变成分片后每个分片可以各配一套哨兵两者是叠加关系。哨兵不保证数据零丢失。因为主从复制是异步的主库宕机瞬间还没同步到从库的那部分写请求切换后就是丢了。哨兵能保证的是“快速恢复服务”不是“完全不丢数据”。理解了这个边界后面配置参数、做故障演练、设计降级方案时心态就不会跑偏。2. 搭建一套三节点哨兵配置与部署实操2.1 拓扑设计主、从、哨兵各几个先说结论生产环境建议主从模式用“一主两从”哨兵节点至少三个且哨兵节点不要全部部署在同一台物理机上。三台哨兵是经典配置也是最简单可靠的方案。为什么哨兵要奇数个因为哨兵之间要投票决策。以三个哨兵为例如果两个哨兵认为主库客观下线就可以执行切换两个哨兵的话其中一个挂了剩下的一个无法和任何人达成一致形同虚设四个哨兵虽然可用但容错能力和三个一样多一个节点反而多一份维护成本。奇数原则在这一类投票场景里是铁律。另外哨兵不一定非要单独部署。它可以和数据节点同机部署但要注意端口冲突和资源竞争。我的建议是如果机器充裕哨兵独立部署更好因为 Redis 本身是内存型服务主库在写高峰时 CPU 和内存波动很大哨兵和数据节点挤在一起会增加互相干扰的概率。Docker 部署主从时还有个小坑容器重启后 IP 会变如果配置里写死的是容器内网 IP主库一换哨兵就找不到原来的对象了。所以我一般建议哨兵配置中使用固定的宿主机 IP 映射端口或者干脆用 host 网络模式避免 IP 漂移带来的误判。2.2 一步步写哨兵配置下面以三个哨兵节点为例分别部署在三台机器上。假设你的 Redis 主库是 192.168.1.100:6379两个从库是 192.168.1.101:6379 和 192.168.1.102:6379三台哨兵分别是 192.168.1.200、192.168.1.201、192.168.1.202端口统一用 26379。每个哨兵节点的配置文件内容基本一致# sentinel.conf port 26379 daemonize yes logfile /var/log/redis/sentinel.log pidfile /var/run/redis-sentinel.pid # 监控的主库名称、地址、端口、判定客观下线所需票数 sentinel monitor mymaster 192.168.1.100 6379 2 # 连续多久联系不上就判定主观下线单位毫秒 sentinel down-after-milliseconds mymaster 10000 # 故障转移超时时间单位毫秒 sentinel failover-timeout mymaster 180000 # 故障转移后最多同时让几个从库同步新主库 sentinel parallel-syncs mymaster 1 # 如果 Redis 设置了密码这里需要配置 sentinel auth-pass mymaster YourStrongRedisPassword先解释几个关键参数后面原理部分会再展开mymaster是逻辑主库名可以自定义。客户端通过这个名字向哨兵查询当前主库地址所以取一个团队内约定好的名字很重要。quorum也就是配置里的最后一位2表示“至少有 2 个哨兵认为主库不可用才判定为客观下线”。三哨兵场景下设为 2 是合理的。down-after-milliseconds是主观下线阈值我生产环境一般设 10000 到 30000 毫秒之间。太短容易因为网络抖动误判太长会拖慢故障恢复速度。failover-timeout是故障转移超时时间默认 180 秒一般不需要频繁调整但如果你遇到过多次切换冲突可以检查这个值。parallel-syncs控制切换后同时有多少个从库去复制新主库。设为 1 是最保守的做法逐个同步避免瞬间多个从库同时全量复制把新主库压垮。需要注意down-after-milliseconds、failover-timeout、parallel-syncs这些参数都带mymaster这个主库名后缀写的时候别漏了。三个哨兵的配置只有两点不同一是云端部署时如果要用独特标识区分可以在配置中增加sentinel announce-ip和sentinel announce-port固定对外宣告的地址二是日志路径、运行目录可能需要独立。其余全部可以一样。2.3 启动与验证命令哨兵有两种启动方式效果完全相同redis-sentinel /etc/redis/sentinel.conf # 或者 redis-server /etc/redis/sentinel.conf --sentinel生产环境我建议用 systemd 或者 supervisor 托管哨兵进程保证它挂了能自动拉起。哨兵进程本身理论上可以多启动几个但同一台机器上跑多个哨兵节点意义不大反而增加了单点故障面。启动完成后用 redis-cli 连到哨兵端口执行几个命令就能确认运行状态# 查看哨兵监控的主库信息 redis-cli -p 26379 sentinel master mymaster # 查看当前监控到的从库列表 redis-cli -p 26379 sentinel replicas mymaster # 查看当前监控到的哨兵列表 redis-cli -p 26379 sentinel sentinels mymaster # 直接获取当前主库地址客户端就靠这个命令做自动发现 redis-cli -p 26379 sentinel get-master-addr-by-name mymaster正常情况下sentinel master mymaster会输出当前主库的 IP、端口、状态还会显示num-slaves从库数量和num-other-sentinels其他哨兵数量等信息。如果从库数或哨兵数没有达到预期说明节点的发现还没完成。哨兵发现彼此和发现从库需要一点时间通常是几秒到十几秒不用急着下结论。用包含密码时redis-cli 连接哨兵也需要带上密码redis-cli -p 26379 -a YourStrongRedisPassword。3. 哨兵内部机制拆解三个定时任务、状态判定与故障转移3.1 三个定时任务的分工协作哨兵看起来就是一个常驻进程但它内部其实是靠三个定时任务在驱动。理解了这三个任务哨兵的大部分行为就都能解释了。第一个任务每隔 10 秒向主库和从库发送INFO命令。这个动作有点像巡检员定期盘点库存主库会返回自己的身份信息、从库列表、复制偏移量等从库会返回自己的复制源地址、同步状态。哨兵通过这些信息自动发现新加入的从库也实时掌握每个从库的数据新鲜程度。这些数据在故障转移时选择新主库时非常关键。第二个任务每隔 2 秒向__sentinel__:hello频道发布一条包含自身信息的消息同时订阅这个频道解析其他哨兵发来的消息。每个哨兵都在这个频道上报“我是谁、我在监控谁、我认为主库状态如何”这样它们之间不需要额外的连接管理协议就能互相发现。你不需要提前在配置里告诉我其他哨兵在哪它们靠这个频道自动组建集群。第三个任务每隔 1 秒向所有已知的实例主库、从库、其他哨兵发送PING命令。这是心跳探测也是判断存活状态的依据。如果持续一段时间收不到某个节点的回复哨兵就开始怀疑对方可能挂了。三个定时任务的频率很有讲究10 秒的 INFO 用来收集拓扑、2 秒的频道消息用来同步认知、1 秒的 PING 用来快速感知故障。频率过快会消耗网络和 CPU过慢又会影响切换时效官方定的这几档是在大规模实践中验证的平衡值。3.2 从主观下线到客观下线为什么要有两段式判定哨兵对节点的判断分为两级主观下线sdown和客观下线odown。主观下线是单个哨兵的私人判断如果某个哨兵在down-after-milliseconds指定的时间内对主库的 PING 一直没有收到有效回复它就在本地把主库标记为 sdown。注意sdown 是局部状态只代表“这个哨兵自己觉得有问题”。客观下线是集体共识当哨兵把主库标记为 sdown 之后它会通过频道消息向其他哨兵喊话“我觉得主库挂了”其他哨兵如果也通过自己的 PING 发现主库联系不上就会响应。当同意主库下线的哨兵数量达到 quorum 时主库才会被标记为 odown。只有进入 odown 状态才会触发故障转移流程。两段式设计非常巧妙。如果只有单个哨兵做主库死亡判定那么这台哨兵和主库之间的网络抖动就会导致一次无意义的切换而主库其实活得好好的其他从库也连得上。通过 quorum 机制把“判断权”从单节点提升到群体决策极大地降低了误切风险。你可以把这个机制理解成开会表决一个同事说领导联系不上可能只是他手机没信号但如果有两个独立的同事都联系不上领导那才真的可能出事了。quorum 就是这个“需要多少人同时确认”的阈值。3.3 领导者选举与从库筛选主库被判定为 odown 后接下来要做的是从多个哨兵里选出一个“执行者”由它主导这次的故障转移。为什么不能所有哨兵一起动手因为如果多个哨兵同时给不同的从库发送SLAVEOF no one整个复制拓扑会乱成一锅粥。哨兵之间的领导者选举用的是一种简化版的 Raft 协议思路每个哨兵都可以成为候选人先到先得其他哨兵投票给比自己更早发起选举的候选人获得多数票的哨兵成为本轮故障转移的领导者。因为三哨兵场景下多数就是 2 票所以奇数个哨兵的意义在选举环节也体现了。领导者选定后第二步是从从库里挑一个“新主库候选人”。筛选条件分三层第一层过滤从库必须在线且最近与主库有通信记录切断了很久、明显数据落后的直接排除。第二层比较优先级每个从库可以通过replica-priority参数设置优先级数字越小优先级越高。可以在配置里指定某台硬件更好的从库优先升主。第三层比较数据完整性前面这些条件相同的情况下哨兵比较各个从库的复制偏移量偏移量越大说明数据越接近旧主库。如果偏移量还相同那就比较 runid小的胜出。这套筛选逻辑的执行优先级是“先靠谱再数据全最后随机兜底”。把一个看似简单的问题拆得这么细就是为了尽量选出最合适的新主库减少切换后的数据丢失窗口。3.4 故障转移全过程朴素但严谨选好新主库后领导哨兵开始执行切换整个过程分四步第一步向选定的从库发送SLAVEOF no one让它脱离复制关系成为新的主库。这一步是切主的关键执行后新主库开始接受写请求。第二步通过INFO轮询确认新主库已经切换成功拿到它的复制 runid 和偏移量。第三步向其他从库发送SLAVEOF 新主库IP 新主库端口让它们把复制目标从旧主库改成新主库。parallel-syncs参数在这一步生效控制并发同步的从库数量。第四步把旧主库标记为不可用在配置里记录新主库地址。如果旧主库后来恢复了哨兵会向它发送SLAVEOF命令让它自动降级为新主库的从库而不是重新当主库。整个过程完成后哨兵会通过频道发布switch-master事件。这个事件是客户端感知主库变更的关键信号。订阅哨兵频道的客户端收到事件后会重新调用sentinel get-master-addr-by-name获取新主库地址再重建连接。我在实际观察里发现整个切换流程中风险最高的不是“选主”环节而是“第三步大批量同步从库”的瞬间。如果从库数量很多全量复制对带宽和 CPU 冲击会很大这也是parallel-syncs要设成 1 的原因。4. 高可用不等于零丢失常见坑与排查实录4.1 脑裂、丢数据与分布式锁失效哨兵高可用方案最大的痛点是它无法保证数据零丢失而且在特定网络分区场景下会引发脑裂。想象一个场景旧主库和客户端在同一个网络区域哨兵在另一个网络区域。区域之间网络抖动哨兵和旧主库通信中断但客户端和旧主库通信正常。哨兵判定主库 odown执行切换选出一个新主库并对外提供服务。此时旧主库还在接受客户端写入这些写入又不会同步到新主库等网络恢复后旧主库被降级为从库它上面多出来的数据会被新主库覆盖直接丢失。这个场景就是典型的脑裂。旧主库在分区期间“以为”自己还是主库继续对外服务新主库已经上线两边数据分叉最后必然丢数据。缓解方案有两个参数都在 Redis 主库配置里设置min-replicas-to-write 1 min-replicas-max-lag 10含义是主库只有在至少 1 个从库连接正常、且延迟不超过 10 秒时才接受写请求。当网络分区发生后旧主库和所有从库都失联不再满足这个条件写请求就会被拒绝从而把脑裂期间的数据丢失窗口压缩到最小。这个配置并不完美分区导致旧主库拒绝写入客户端会立刻收到写失败影响业务可用性。但在数据一致性和可用性之间这已经是一个偏向安全的平衡。另一个更成熟的思路是升级到 Redis Cluster 或引入其他一致性协议但对大多数场景来说二选一参数已经是成本和收益的较优解。分布式锁也值得单独说。很多人用 Redis 的SETNX实现分布式锁并依赖哨兵高可用保证锁的可靠性。但主从切换瞬间如果锁数据还没有同步到新主库另一个客户端就能在新主库上拿到同一把锁锁的互斥性被破坏。原因还是异步复制。所以如果你的系统对分布式锁的强一致性有硬性要求哨兵架构是不合格的要用 Redlock 或者其他外部存储实现如果只是兜底防重复提交、对偶发并发放行有一定容忍度哨兵架构可以接受。4.2 持久化、密码、ACL 与日志配置和主从复制一样哨兵模式下持久化的配置直接决定了切换后的数据安全性。如果关闭了 RDB/AOF主库宕机后一切数据都靠内存里的从库副本如果从库又没有数据切换等于从零开始。这个坑比很多人想象中更致命因为开发环境复制延迟很低、数据量也很小问题不容易暴露生产环境一旦出现主库内存数据刚写入还没落盘就宕机这部分数据就是永久丢失。所以我建议主库必须开启 AOFappendfsync everysec是一个折中方案从库也开启 AOF防止全量重同步时依赖主库生成 RDB 的瞬时压力。顺便说一句你可以在从库上配置replica-read-only yes保护数据避免误写从库。密码方面Redis 如果开启了requirepass哨兵默认是无法通过认证的必须在哨兵配置里补上sentinel auth-pass mymaster YourStrongRedisPassword更细心的团队会用 Redis 6 之后的 ACL 功能为哨兵单独创建一个专用户user sentinel on SentinelPassword all ~* ping info role replicaof auth这个思路很值得采用哨兵只需要有限的命令权限没必要给它全量凭据。因为哨兵配置文件中是明文存放密码的如果运维误把哨兵配置文件提交到 Git 仓库泄露面会小很多。日志配置也容易被忽略。默认情况下哨兵把日志打到标准输出systemd 托管时可能进了 journald排查问题时要多翻一层。建议在配置里显式指定日志文件logfile /var/log/redis/sentinel.log并且做好日志轮转。故障切换时哨兵日志是整个过程的“黑匣子”从odown到switch-master每一步都有记录日志留好了事后复盘能省很多时间。4.3 常见问题速查表我把工作里遇到和身边人遇到过的问题整理成了一张表现象常见原因处理建议哨兵日志显示sdown但主库其实正常网络抖动、主库负载过高导致 PING 超时调大down-after-milliseconds观察不在参数上“一刀切”主库挂了但不触发切换quorum 配置过大哨兵节点分布不均三哨兵配 quorum2检查哨兵是否能互相连通切换后从库一直处于全量同步状态parallel-syncs太大新主库带宽打满设置parallel-syncs 1恢复后的旧主库持续尝试连接旧地址哨兵配置中 monitor 地址写死未动态更新确保哨兵配置文件有写权限哨兵会动态重写哨兵通过 docker 部署经常误判容器 IP 漂移、端口映射导致 PING 走错路径使用 host 网络或固定 announce-ip/port客户端拿到的还是旧主库地址客户端没监听switch-master事件改用哨兵地址连接监听事件后主动重查主库地址哨兵和主库之间无法认证主库配置requirepass哨兵未配auth-pass在配置中补上sentinel auth-pass这张表基本覆盖了哨兵上线初期最常遇到的几类问题。大多数情况不是哨兵本身有 bug而是参数、网络和客户端联动没有配套调整好。5. 把哨兵用稳我踩过坑之后的几点经验5.1 关键参数怎么定参数没有万能套餐但可以根据业务忍受度设一个合理的起点。down-after-milliseconds先设 3000030 秒跑一个月看监控里有没有误报。如果没有逐步调到 10000如果网络本身就不稳定保持 30000 也没问题。你要明确一点这个值越长误切换越少但故障恢复也越慢。quorum三哨兵就设 2五哨兵可以设 3。设得过高会导致“大家都觉得有问题但没有达成共识”主库真挂了也不切换。failover-timeout保持默认 180000 基本够用。如果切换经常超时失败优先排查的是从库同步压力而不是这个参数。parallel-syncs从库数量少于 5 个时设 1 就行如果从库很多且全量复制很快可以尝试提高到 2但不建议超过 3。参数调整后需要滚动重启哨兵或者至少用SENTINEL SET命令动态调整。SENTINEL SET mymaster down-after-milliseconds 10000可以热更新不需要重启进程。这个命令很适合线上调优场景。5.2 故障演练一定要做很多团队的哨兵部署完就认为高可用搞定了但从来没实际演练过。结果一次真实故障来临时发现从库优先级配错了、客户端根本没有订阅哨兵事件、哨兵节点之间网络隔离导致 quorum 凑不齐。这种“假高可用”比没有高可用更危险因为它制造了安全错觉。我建议把故障演练纳入季度例行。演练步骤很简单挑一个业务低峰期找到主库实例直接执行debug sleep 30或者kill -9模拟进程崩溃。观察哨兵日志记录从sdown、odown到switch-master的时间戳。用客户端连接哨兵查询新主库地址验证客户端是否自动完成重连。验证新主库数据完整性和从库的同步状态确认没有异常堆积。演练结束后把新主库再次手动切换回原来的老主库恢复初始拓扑。我自己第一次组织演练时遇到一个很有意思的问题杀掉了主库进程后哨兵确实完成了切换但业务那边还是持续报错。查了半天发现是客户端的连接池没有监听哨兵事件只会在启动时拉取一次主库地址。修复方式是在客户端配置里开启哨兵模式并设置监听switch-master事件的回调。这类问题只有演练才能暴露出来。5.3 从哨兵到治理后续怎么演进哨兵解决了单分片内的高可用但它不是终点。数据量涨上来之后你会面临两个新问题单分片内存写满、AOF 重写时磁盘 IO 抖动以及多分片之间无法做跨分片事务。这时候就应该考虑 Redis Cluster用多分片分担压力同时每个分片内仍然可结合哨兵思路保障可用性。在实际架构演进中我见过比较稳妥的过渡路径是先上哨兵做高可用再在应用层把不同业务的数据拆分到不同的 Redis 实例每个实例一组哨兵最后等业务拆分到边界清晰后再评估是否需要迁移到 Redis Cluster。直接跳过哨兵上 Cluster 的团队往往会在槽位迁移和数据倾斜上消耗大量精力。如果对可用性要求再高一个档次比如希望异地容灾哨兵本身无法解决跨机房问题。这时候需要做的是跨机房数据同步例如基于 RDB/AOF 的定期同步、或者引入多活方案但那是另一个大的话题了。哨兵作为第一层高可用护甲先把本地机房的自动切换做好才是后续所有复杂方案的前提。我在实际使用中的体会是哨兵最容易被低估的不是它的自动切换能力而是它把“故障决策”从人转移到了代码这个转变的价值只有在凌晨三点的故障里才能被真正感受到。配置参数、演练流程、客户端联动三件事都做到位你才敢说这套 Redis 真的高可用了。