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 通道，自动感知主节点变更，无需重启或重配
