一、为什么需要哨兵模式
在业务早期，很多团队会采用 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、端口、法定人数（quorum）
sentinel 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 yourpassword
5.1 quorum 参数怎么设
quorum 是判断客观下线需要多少个哨兵同意。比如你有 3 个哨兵，设置 quorum=2，意味着至少 2 个哨兵都认为主节点挂了，才会真正开始故障转移。
推荐设置：哨兵总数的一半加一。比如 3 个哨兵设 2，5 个哨兵设 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.master=mymaster
spring.redis.sentinel.nodes=192.168.1.1:26379,192.168.1.2:26379,192.168.1.3:26379
spring.redis.password=yourpassword
7.3 脑裂问题
哨兵模式存在一个著名的"脑裂"问题：假设主节点所在的网络和哨兵网络断开了，但主节点本身还活着。这时哨兵们会认为主节点挂了，选举一个新的主节点。但旧的主节点其实还在接收写请求——这就出现了两个主节点，也就是脑裂。
等网络恢复后，旧主节点会被降级为从节点，这段时间写入旧主的数据会全部丢失。
解决方案：配置 min-replicas-to-write 和 min-replicas-max-lag，让主节点至少要有 N 个从节点正常同步时才能接受写请求。这样网络分区时，旧主发现没有从节点同步，就自动拒绝写了。
7.4 不要用哨兵做分片
哨兵模式本质上还是单主架构，所有写压力都在一个主节点上。如果你的数据量超过了单机内存，或者写并发很高，哨兵模式解决不了这个问题，应该直接上 Redis Cluster。
八、总结
Redis 哨兵模式是中小规模生产环境中最常用的高可用方案，它的核心价值在于自动故障转移，解决了主从模式下主节点宕机需要人工介入的痛点。
最后总结一下选型建议：
- 数据量小、并发不高：用哨兵模式，运维成本低，够用
- 数据量大、需要水平扩展：直接上 Redis Cluster，不要用哨兵
- 开发测试环境：主从模式就够了，不用哨兵
理解哨兵的关键不在于记住配置参数，而在于理解主观下线 → 客观下线 → Leader 选举 → 新主选举 → 故障转移这整条链路。掌握了这个流程，再去看源码和排查问题就会清晰很多。
函数详解与图像加载优化)
