Redis 哨兵模式

一、基本概念

哨兵模式 是 Redis 提供的一种高可用性解决方案，主要用于在主从复制架构中实现自动故障转移

1. 主从复制（Replication）
   一个主节点（Master）负责写操作。
   多个从节点（Slave/Replica）复制主节点的数据，用于读操作或备份。
   如果主节点宕机，需要手动切换主节点，运维成本高。
2. 哨兵（Sentinel）
   Sentinel 是 Redis 的独立进程，用于监控 Redis 主从实例的健康状态。
   自动完成故障检测、主从切换、通知客户端等任务。
   通常部署 奇数个哨兵节点（如 3 个），以避免脑裂（Split-Brain）问题。

二、工作原理简述

• 哨兵之间通过 gossip 协议互相发现并通信。
• 哨兵定期向主/从节点发送 PING 命令判断其是否存活。
• 当多数哨兵认为主节点"主观下线"（sdown）后，达成共识将其标记为"客观下线"（odown）。
• 发起故障转移：
  选择一个合适的从节点（优先级、复制偏移量、运行 ID 等）提升为主节点。
  通知其他从节点复制新的主节点。
  更新哨兵的配置，并通知客户端。

三、配置示例（sentinel.conf）

# 监控名为 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

启动哨兵：

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 台服务器，成本翻倍；运维复杂度略高。（仅在对可用性要求极高的场景使用）

六、架构图