一、基本概念
哨兵模式 是 Redis 提供的一种高可用性解决方案，主要用于在主从复制架构中实现自动故障转移
- 主从复制（Replication）
一个主节点（Master）负责写操作。
多个从节点（Slave/Replica）复制主节点的数据，用于读操作或备份。
如果主节点宕机，需要手动切换主节点，运维成本高。 - 哨兵（Sentinel）
Sentinel 是 Redis 的独立进程，用于监控 Redis 主从实例的健康状态。
自动完成故障检测、主从切换、通知客户端等任务。
通常部署 奇数个哨兵节点（如 3 个），以避免脑裂（Split-Brain）问题。
二、工作原理简述
- 哨兵之间通过 gossip 协议互相发现并通信。
- 哨兵定期向主/从节点发送 PING 命令判断其是否存活。
- 当多数哨兵认为主节点"主观下线"（sdown）后，达成共识将其标记为"客观下线"（odown）。
- 发起故障转移：
选择一个合适的从节点（优先级、复制偏移量、运行 ID 等）提升为主节点。
通知其他从节点复制新的主节点。
更新哨兵的配置，并通知客户端。
三、配置示例（sentinel.conf）
c
# 监控名为 mymaster 的主节点，IP 为 127.0.0.1，端口 6379
# 至少需要 2 个哨兵同意才认为主节点下线
sentinel monitor mymaster 127.0.0.1 6379 2
# 主节点无响应多少毫秒后标记为主观下线（默认 30 秒）
sentinel down-after-milliseconds mymaster 5000
# 故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 60000
# 最多同时有几个从节点对新主节点进行同步（避免网络拥塞）
sentinel parallel-syncs mymaster 1启动哨兵：
c
redis-sentinel /path/to/sentinel.conf四、哨兵
🧩 哨兵的本质
哨兵 = 一个轻量级的 Redis 进程，只负责：
- 监控（Monitoring）
- 通知（Notification）
- 自动故障转移 （Failover）[即：Master故障后，投票选举一个Slave作为新的Master]
- 配置提供 （Configuration provider）
它 不存储业务数据 ，也不处理客户端的 GET/SET 请求。
它有自己的配置文件（如 sentinel.conf），监听一个端口（默认 26379）。
五、哨兵的数量与部署
Redis Sentinel 系统中哨兵（Sentinel）的数量选择主要取决于你对系统高可用性的要求以及网络拓扑结构。
-
最少3个哨兵： 这是推荐的最小配置
1主2从，1主2从，1主3从，1主4从，1主5从 3 个哨兵仍然是最经典、最合理的选择。
-
奇数个哨兵： 为了防止脑裂问题
对于大多数应用来说，3到5个哨兵是一个比较合理的选择，它们既能提供足够的容错能力，又不会过度增加系统的复杂性和资源消耗。
✅ 哨兵的部署：
- 推荐方案：哨兵与 Redis 节点混合部署（最常见） （假设1主2从：每台服务器 1 个哨兵 + 1 个 Redis ）
优点： 只需要3台服务器，节省成本，即使1台服务器宕机，仍剩下 2 哨兵 + 2 Redis，可继续故障转移
这是绝大多数中小企业的标准做法。
缺点： 单台服务器负载略高（但哨兵非常轻量，通常可忽略） - 方案二：哨兵独立部署 （哨兵不与 Redis 在同一台服务器）
优点： 故障域完全隔离：Redis 宕机不影响哨兵，哨兵宕机也不影响数据服务；
更高可靠性，适合金融、电信等关键业务。
缺点： 需要 6 台服务器，成本翻倍；运维复杂度略高。（仅在对可用性要求极高的场景使用）
六、架构图
