一、为什么需要哨兵模式在业务早期很多团队会采用 Redis 主从复制架构一个主节点Master负责写操作多个从节点Replica负责读操作通过读写分离提升性能。但这种架构有一个致命问题主节点宕机后整个集群就失去了写能力需要人工介入切换主从。在高并发、高可用要求的生产环境中人工切换不仅响应慢还容易出错。Redis 哨兵模式Sentinel正是为了解决这个问题而生——它在主从架构之上增加了一个独立的监控层实现了自动故障检测、自动主从切换、自动配置更新。一句话总结哨兵模式 主从复制 自动故障转移 监控告警。它不是用来解决容量问题的而是用来解决高可用问题的。二、哨兵模式核心架构一个完整的哨兵模式集群由三部分组成主节点、从节点、哨兵节点。主节点Master负责所有写操作和查询操作一个集群只有一个主节点。从节点Replica通过复制同步主节点数据负责读操作同时作为主节点的备份。哨兵节点Sentinel独立运行的进程不存储业务数据专门负责监控主从节点状态。图哨兵模式整体架构图上图展示了典型的一主二从三哨兵架构。哨兵节点通常部署在不同的服务器上避免和 Redis 节点部署在同一台机器上——否则机器挂了哨兵也跟着挂了就失去了监控意义。三、哨兵的五大核心功能3.1 监控Monitoring哨兵会持续地向主节点和从节点发送 PING 命令检查它们是否正常运行。如果一个节点在指定时间内没有回复 PING或者回复了错误消息哨兵就会认为这个节点主观下线Subjectively Down简称 SDOWN。3.2 通知Notification当被监控的节点出现异常时哨兵可以通过 API 向管理员或者其他应用程序发送告警通知。这是生产环境中必不可少的能力——你需要在第一时间知道 Redis 集群出问题了。3.3 自动故障转移Automatic Failover这是哨兵最核心的功能。当主节点真正宕机时哨兵会自动从从节点中选举出一个新的主节点让其他从节点改为复制新的主节点整个过程不需要人工干预。3.4 配置中心Configuration Provider客户端连接 Redis 时会先连接哨兵询问当前的主节点地址。故障转移完成后哨兵会告诉客户端新的主节点地址客户端据此更新连接。这意味着应用不需要硬编码主节点 IP。3.5 只读模式ReadOnly Mode哨兵可以配置从节点是否接受读请求。在主节点故障期间某些从节点可能被标记为不可用哨兵会指导客户端只连接健康的从节点。四、故障转移完整流程很多人知道哨兵能自动切换但具体怎么切、选谁当新主背后是一套完整的选举机制。我们一步步拆解图哨兵故障转移完整流程图4.1 主观下线 vs 客观下线这是理解哨兵机制的两个关键概念概念触发条件含义主观下线SDOWN单个哨兵认为主节点不可用可能是误判比如网络抖动还不能确定主节点真的挂了客观下线ODOWN超过 quorum 数量的哨兵都认为主节点下线经过多节点确认主节点确实宕机了可以开始故障转移注意客观下线只针对主节点。从节点和哨兵节点的下线不需要其他哨兵确认单个哨兵判断就够了。4.2 新主节点的选举规则当 Leader 哨兵要选一个从节点升级为新主时不是随便选一个而是按照优先级排序第一步过滤掉不健康的从节点下线的、断线的第二步过滤掉数据太旧的从节点复制延迟太大的第三步选择 replica-priority 配置值最小的从节点优先级越高值越小第四步优先级相同选择复制偏移量最大的数据最新的第五步偏移量也相同选择 runid 最小的五、关键配置参数详解哨兵模式的核心配置都在 sentinel.conf 文件中以下是生产环境必须理解的几个关键参数# 监控的主节点名称、IP、端口、法定人数quorumsentinel monitor mymaster 127.0.0.1 6379 2# 主观下线超时时间毫秒超过这个时间没响应就认为主观下线sentinel down-after-milliseconds mymaster 5000# 故障转移超时时间毫秒sentinel failover-timeout mymaster 15000# 故障转移时同时同步新主的从节点数量# 值越小越安全逐个同步但恢复时间越长sentinel parallel-syncs mymaster 1# 主节点密码如果设置了密码sentinel auth-pass mymaster yourpassword5.1 quorum 参数怎么设quorum 是判断客观下线需要多少个哨兵同意。比如你有 3 个哨兵设置 quorum2意味着至少 2 个哨兵都认为主节点挂了才会真正开始故障转移。推荐设置哨兵总数的一半加一。比如 3 个哨兵设 25 个哨兵设 3。这样既不会因为单个哨兵误判就触发切换也不会因为少数几个哨兵挂了就无法选举。最佳实践哨兵节点数量建议是奇数3、5、7这样在选举 Leader 哨兵时不会出现平局。3 个哨兵是最低配置能容忍 1 个哨兵故障。六、三种 Redis 高可用方案对比很多同学会纠结我到底该用主从、哨兵还是集群这里做一个清晰对比对比维度纯主从模式哨兵模式Cluster 集群高可用无主挂了人工切换有自动故障转移有自动故障转移数据容量单机内存上限单机内存上限可水平扩展多分片写性能单主写瓶颈在单节点单主写瓶颈在单节点多主写性能可扩展运维复杂度简单中等复杂适用场景开发测试环境中小规模数据量不大大规模数据量大、并发高七、生产环境踩坑指南7.1 哨兵节点不要和 Redis 节点混部很多人为了省机器把哨兵和 Redis 部署在同一台服务器上。这是非常错误的做法——服务器挂了Redis 和哨兵一起挂谁来监控哨兵至少要部署 3 台不同的机器甚至不同机房。7.2 客户端要正确配置哨兵模式使用 Spring Data Redis 或者 Redisson 时必须配置哨兵模式的连接方式不能直接连接主节点 IP。否则故障转移后客户端还连着旧的主节点地址服务就不可用了。spring.redis.sentinel.mastermymasterspring.redis.sentinel.nodes192.168.1.1:26379,192.168.1.2:26379,192.168.1.3:26379spring.redis.passwordyourpassword7.3 脑裂问题哨兵模式存在一个著名的脑裂问题假设主节点所在的网络和哨兵网络断开了但主节点本身还活着。这时哨兵们会认为主节点挂了选举一个新的主节点。但旧的主节点其实还在接收写请求——这就出现了两个主节点也就是脑裂。等网络恢复后旧主节点会被降级为从节点这段时间写入旧主的数据会全部丢失。解决方案配置 min-replicas-to-write 和 min-replicas-max-lag让主节点至少要有 N 个从节点正常同步时才能接受写请求。这样网络分区时旧主发现没有从节点同步就自动拒绝写了。7.4 不要用哨兵做分片哨兵模式本质上还是单主架构所有写压力都在一个主节点上。如果你的数据量超过了单机内存或者写并发很高哨兵模式解决不了这个问题应该直接上 Redis Cluster。八、总结Redis 哨兵模式是中小规模生产环境中最常用的高可用方案它的核心价值在于自动故障转移解决了主从模式下主节点宕机需要人工介入的痛点。最后总结一下选型建议数据量小、并发不高用哨兵模式运维成本低够用数据量大、需要水平扩展直接上 Redis Cluster不要用哨兵开发测试环境主从模式就够了不用哨兵理解哨兵的关键不在于记住配置参数而在于理解主观下线 → 客观下线 → Leader 选举 → 新主选举 → 故障转移这整条链路。掌握了这个流程再去看源码和排查问题就会清晰很多。