NoSQL之redis哨兵
一、哨兵的核心功能
-
监控（Monitoring）
-
持续检查主节点和从节点的运行状态（是否存活、延迟等）。
-
-
自动故障转移（Automatic Failover）
-
当主节点不可用时，自动选举一个从节点升级为主节点。
-
更新其他从节点和客户端的配置指向新主节点。
-
-
配置提供（Configuration Provider）
-
客户端通过哨兵获取当前的主节点地址（无需手动修改配置）。
-
-
通知（Notification）
-
通过 API 或脚本发送集群状态变化的告警（如邮件、短信）。
-
二、哨兵的工作原理
1. 监控机制
-
每个哨兵每秒向所有节点（主/从/其他哨兵）发送
PING命令。 -
若节点在
down-after-milliseconds时间内未响应，哨兵将其标记为主观下线（Subjectively Down）。 -
当多个哨兵（需达到
quorum数量）都认为主节点主观下线，则主节点被标记为客观下线（Objectively Down）。
2. 选举领导者哨兵
-
主节点客观下线后，哨兵们通过 Raft 算法 选举一个领导者哨兵（Leader Sentinel）来执行故障转移。
3. 故障转移流程
-
领导者哨兵选择一个合适的从节点（如数据最新、优先级高）。
-
向该从节点发送
SLAVEOF NO ONE命令，使其成为新主节点。 -
向其他从节点发送
SLAVEOF <new-master-ip> <new-master-port>，指向新主节点。 -
将旧主节点更新为从节点（若恢复则自动切换角色）。
三、部署建议
-
最少部署 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秒
四、客户端如何配合哨兵？
客户端需通过哨兵获取主节点地址，而不是直连主节点。流程如下：
-
连接任意哨兵节点，发送命令：
SENTINEL get-master-addr-by-name <master-name>
-
获取当前主节点 IP 和端口后建立连接。
-
订阅哨兵的
+switch-master事件，及时感知主节点切换。
五、哨兵的优势与限制
| 优势 | 限制 |
|---|---|
| 自动故障转移，服务高可用 | 不解决数据分片（需配合 Redis Cluster） |
| 配置集中管理，客户端透明 | 故障转移期间可能有少量数据丢失 |
| 支持多哨兵部署，避免单点故障 | 网络分区时可能出现脑裂（需合理配置） |
六、常见命令
# 查看主节点信息 SENTINEL masters# 查看从节点信息 SENTINEL slaves <master-name># 手动触发故障转移（测试用） SENTINEL failover <master-name>
七、注意事项
-
避免脑裂（Split-Brain）：确保
quorum值 > 哨兵总数/2（如 3 个哨兵设quorum=2）。 -
合理设置超时：
down-after-milliseconds根据网络延迟调整（通常 5-30 秒）。 -
版本一致性：所有节点使用相同 Redis 版本（避免兼容问题）。