NoSQL之redis哨兵

一、哨兵的核心功能

1. 监控（Monitoring）

   • 持续检查主节点和从节点的运行状态（是否存活、延迟等）。

2. 自动故障转移（Automatic Failover）

   • 当主节点不可用时，自动选举一个从节点升级为主节点。

   • 更新其他从节点和客户端的配置指向新主节点。

3. 配置提供（Configuration Provider）

   • 客户端通过哨兵获取当前的主节点地址（无需手动修改配置）。

4. 通知（Notification）

   • 通过 API 或脚本发送集群状态变化的告警（如邮件、短信）。

---

二、哨兵的工作原理

1. 监控机制

• 每个哨兵每秒向所有节点（主/从/其他哨兵）发送 PING 命令。

• 若节点在 down-after-milliseconds 时间内未响应，哨兵将其标记为主观下线（Subjectively Down）。

• 当多个哨兵 （需达到 quorum 数量）都认为主节点主观下线，则主节点被标记为客观下线（Objectively Down）。

2. 选举领导者哨兵

• 主节点客观下线后，哨兵们通过 Raft 算法 选举一个领导者哨兵（Leader Sentinel）来执行故障转移。

3. 故障转移流程

1. 领导者哨兵选择一个合适的从节点（如数据最新、优先级高）。

2. 向该从节点发送 SLAVEOF NO ONE 命令，使其成为新主节点。

3. 向其他从节点发送 SLAVEOF <new-master-ip> <new-master-port>，指向新主节点。

4. 将旧主节点更新为从节点（若恢复则自动切换角色）。

---

三、部署建议

1. 最少部署 3 个哨兵节点（避免脑裂，需奇数台）。

2. 哨兵分散在不同物理服务器（防单点故障）。

3. 配置参数示例：

   sentinel monitor mymaster 192.168.1.10 6379 2  # 监控主节点，2表示quorum
   sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判为主观下线
   sentinel failover-timeout mymaster 60000       # 故障转移超时60秒

---

四、客户端如何配合哨兵？

客户端需通过哨兵获取主节点地址，而不是直连主节点。流程如下：

1. 连接任意哨兵节点，发送命令：

   SENTINEL get-master-addr-by-name <master-name>

2. 获取当前主节点 IP 和端口后建立连接。

3. 订阅哨兵的 +switch-master 事件，及时感知主节点切换。

---

五、哨兵的优势与限制

优势	限制
自动故障转移，服务高可用	不解决数据分片（需配合 Redis Cluster）
配置集中管理，客户端透明	故障转移期间可能有少量数据丢失
支持多哨兵部署，避免单点故障	网络分区时可能出现脑裂（需合理配置）

---

六、常见命令

# 查看主节点信息
SENTINEL masters

# 查看从节点信息
SENTINEL slaves <master-name>

# 手动触发故障转移（测试用）
SENTINEL failover <master-name>

---

七、注意事项

1. 避免脑裂（Split-Brain） ：确保 quorum 值 > 哨兵总数/2（如 3 个哨兵设 quorum=2）。

2. 合理设置超时 ：down-after-milliseconds 根据网络延迟调整（通常 5-30 秒）。

3. 版本一致性：所有节点使用相同 Redis 版本（避免兼容问题）。