redis哨兵模式通过至少3个哨兵节点自动完成主从切换，需统一配置monitor参数、quorum值、认证密码及超时等关键项，并由客户端通过哨兵动态发现主节点。

Redis 哨兵模式通过一组独立的哨兵进程自动监控主从节点，当主节点不可用时，由多个哨兵协商后选出新主并完成切换，整个过程无需人工干预。关键在于部署至少 3 个哨兵节点、正确配置监控参数，并确保客户端通过哨兵发现主节点。

哨兵节点部署要求

哨兵必须以集群方式运行，不能单点部署：

• 最少部署 3 个哨兵实例，推荐奇数个（如 3 或 5），避免投票平局导致无法达成客观下线共识
• 每个哨兵应运行在不同物理机或容器中，防止同机故障导致全部失效
• 哨兵是独立进程（redis-sentinel 或 redis-server --sentinel），不存储业务数据
• 所有哨兵配置中，对同一主节点的 monitor 名称、IP 和端口必须完全一致

核心配置项（sentinel.conf）

以下是最关键的几项配置，需在每个哨兵的 sentinel.conf 中设置：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 监控主节点：sentinel monitor mymaster 192.168.1.100 6379 2 其中 mymaster 是自定义集群名，2 是 quorum 值——表示至少 2 个哨兵同意才判定主节点客观下线（3 节点集群推荐设为 2）
• 认证密码（若主节点设置了 requirepass）：sentinel auth-pass mymaster your_password，密码必须与 redis.conf 中一致
• 主观下线阈值：sentinel down-after-milliseconds mymaster 30000 表示某哨兵连续 30 秒未收到主节点 PING 回复，即标记为 SDOWN
• 故障转移超时：sentinel failover-timeout mymaster 180000 整个选举、提升、重配置流程必须在此时间内完成，否则本次故障转移失败
• 并行同步数量：sentinel parallel-syncs mymaster 1 控制故障转移后，有多少个从节点可同时向新主同步数据，避免带宽打满

启动与验证步骤

配置完成后，按顺序执行：

• 确保主从复制已正常运行（主节点 role:master，两个从节点 role:slave 且 master_link_status:up）
• 分别启动三个哨兵：redis-sentinel /path/to/sentinel1.conf，每个使用不同端口（如 26379/26380/26381）和 PID 文件
• 检查哨兵日志，确认出现类似 +monitor、+sentinel 的初始化记录，表示已发现主节点及其他哨兵
• 手动模拟主节点宕机（redis-cli -p 6379 shutdown），观察日志中是否出现 +odown → +failover → +switch-master 流程
• 故障转移完成后，原主重启会自动变为从节点，同步新主数据

客户端接入方式

应用不能直连主节点 IP，而应连接哨兵集群获取实时主地址：

• Node.js（redis v4+）：createSentinel({ name: 'mymaster', sentinelRootNodes: [{host:'s1',port:26379},...] })
• Java（Jedis）：使用 JedisSentinelPool，传入哨兵列表和 master name
• Python（redis-py）：Sentinel(...).master_for('mymaster')
• 客户端会订阅哨兵的 Pub/Sub 通道，自动感知主节点变更，无需重启或重配