Redis 哨兵机制

Redis哨兵(Sentinel)机制详解

一、哨兵核心功能

1. 监控(Monitoring)：持续检查主从节点运行状态
2. 通知(Notification)：通过API通知系统管理员节点故障
3. 自动故障转移(Automatic failover)：主节点故障时自动提升从节点为新主
4. 配置提供(Configuration provider)：为客户端提供最新的主节点地址

二、哨兵架构组成

1. 哨兵节点集群：通常由3个或以上哨兵节点组成
2. Redis主从集群：被监控的主节点和从节点
3. 客户端：通过哨兵获取主节点信息

三、工作流程解析

1. 监控阶段

• 每1秒向所有节点发送PING命令
• 通过回复判断节点状态：
  • +PONG：正常
  • -LOADING：正在加载
  • -MASTERDOWN：主节点下线

2. 主观下线(SDown)判定

• 单个哨兵节点检测到主节点无响应
• 超过down-after-milliseconds配置时间(默认30秒)
• 标记主节点为"主观下线"

3. 客观下线(ODown)判定

• 多个哨兵节点(通常需过半)确认主节点不可用
• 满足quorum参数配置的数量要求
• 标记主节点为"客观下线"

4. 故障转移流程

1. 选举Leader哨兵：

   • 使用Raft算法选举负责故障转移的哨兵
   • 需要获得多数哨兵节点的投票

2. 选择新主节点：

   • 排除不健康的从节点
   • 选择复制偏移量最大的从节点
   • 考虑节点优先级(配置参数)

3. 提升新主：

   • 向选中的从节点发送SLAVEOF NO ONE
   • 等待新主节点确认角色变更

4. 切换从节点：

   • 向其他从节点发送SLAVEOF指向新主
   • 更新配置并持久化

四、关键配置参数

# 哨兵基本配置
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000# 重要参数说明
- quorum：确认客观下线所需哨兵数
- down-after-milliseconds：判定下线时间阈值
- parallel-syncs：故障转移时同时同步的从节点数
- failover-timeout：故障转移超时时间

五、哨兵集群通信

1. 使用Redis协议：哨兵节点间通过Redis协议通信
2. 发布/订阅模式：通过__sentinel__频道交换信息
3. 自动发现机制：新哨兵加入时自动识别其他哨兵

六、客户端接入方式

1. 直接连接：客户端连接哨兵获取主节点信息
2. 故障感知：客户端订阅哨兵通知频道
3. 自动切换：客户端实现主节点切换逻辑

七、生产环境最佳实践

1. 部署建议：

   • 至少部署3个哨兵节点
   • 跨机架/可用区部署
   • 独立部署(不与Redis实例同机)

2. 性能优化：

   • 调整down-after-milliseconds平衡敏感度
   • 合理设置parallel-syncs避免网络拥塞
   • 监控哨兵节点的CPU和网络使用

3. 常见问题处理：

   • 脑裂问题：配置min-slaves-to-write
   • 网络分区：合理设置超时时间
   • 配置不一致：确保所有哨兵配置相同

哨兵机制为Redis提供了高可用保障，但需要注意其并非强一致性方案，在极端网络情况下可能出现脑裂问题，需要配合适当的客户端处理策略。