哨兵架构组件
一句话回答
Redis 哨兵架构由三个核心组件组成：主节点（提供读写服务）、从节点（提供读服务+热备）、哨兵节点（监控+选主+通知），三者协作构成高可用系统。
架构全景图
┌──────────────────┐
│ Sentinel 1 │ ← 哨兵节点（监控+决策）
└──────────────────┘
│
┌────────────────────────┼────────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ Sentinel 2 │ │ Sentinel 3 │ │ Client SDK │
│ (监控+选举) │ │ (监控+投票) │ │ (连接发现) │
└──────────────────┘ └──────────────────┘ └──────────────────┘
│ │ │
└────────────────────────┼────────────────────┘
│
▼
┌──────────────────┐
│ Master Node │ ← 主节点（读写）
└────────┬─────────┘
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Slave 1 │ │ Slave 2 │ │ Slave 3 │ ← 从节点（只读+备份）
└──────────┘ └──────────┘ └──────────┘
组件详解
1. 主节点（Master）
核心职责：
- 处理所有写操作（Client 写入）
- 处理所有读操作（也可以）
- 向从节点异步传播写命令
- 故障时由哨兵完成故障转移
高可用要求：
- 必须开启持久化（RDB 或 AOF），否则重启可能导致 replid 变化→全量复制
- 建议关闭
protected-mode或配置密码
# master 关键配置
requirepass yourpassword # 密码认证
masterauth yourpassword # 从节点连主节点认证（哨兵模式下必须）
appendonly yes # 持久化
2. 从节点（Slave / Replica）
核心职责：
- 接收主节点的复制数据（RDB + 增量命令）
- 提供只读服务（
replica-read-only yes） - 故障转移时被选为新主节点
在哨兵中的作用：
# 从节点配置
port 6380
replicaof 192.168.1.1 6379
replica-read-only yes
replica-priority 100 # 越小越优先升级为主（可选范围 0-100）
masterauth yourpassword # 认证主节点
replica-priority 的作用：
| 优先级值 | 说明 |
|---|---|
| 0 | 永远不升级为主 |
| 1-100 | 越小优先级越高，哨兵优先选为新的主节点 |
3. 哨兵节点（Sentinel）
核心职责（三合一）：
| 职责 | 说明 |
|---|---|
| 监控 | 每 1 秒向主/从节点 PING |
| 决策 | 通过 Raft 协议选举 leader，执行故障转移 |
| 通知 | 对外提供 API 让客户端获取当前主节点地址 |
配置示例：
# sentinel.conf 三个节点通用配置
port 26379
sentinel monitor mymaster 192.168.1.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster yourpassword
# 客户端发现脚本（可选）
sentinel notification-script mymaster /path/to/notify.sh
sentinel client-reconfig-script mymaster /path/to/reconfig.sh
哨兵的三个子组件：
Sentinel 进程
├── 监控模块（Monitor）
│ └── 每 1 秒 PING 所有已知节点
│
├── 决策模块（Raft + 选主算法）
│ └── 选举 leader → 执行故障转移
│
├── API 模块
│ └── 提供 SENTINEL get-master-addr-by-name 等命令
组件间通信
哨兵 ↔ Redis 节点
Sentinel ──每 1 秒 PING → Master/Slave
Sentinel ← PONG ──────── Master/Slave
Sentinel ──INFO ─────────→ Master（每 10 秒）
← 主节点信息、从节点信息 ──
Sentinel ──INFO ─────────→ Slave（每 10 秒）
哨兵 ↔ 哨兵
Sentinel A ──── pub/sub (__sentinel__:hello) ────→ Sentinel B
交换信息：
- 主节点当前状态
- 各哨兵对主节点的判断
- leader 选举投票
客户端 ↔ 哨兵
# 客户端获取当前主节点地址
redis> SENTINEL get-master-addr-by-name mymaster
1) "192.168.1.1"
2) "6379"
# 获取从节点列表
redis> SENTINEL slaves mymaster
1) 1) "name"
2) "192.168.1.2:6380"
...
# 哨兵通知客户端故障转移事件
# 客户端订阅 +switch-master 频道
redis> SUBSCRIBE +switch-master
典型部署方案
最小高可用部署（3 哨兵 + 1 主 + 2 从）
机器 A: Master :6379 + Sentinel :26379
机器 B: Slave :6379 + Sentinel :26379
机器 C: Slave :6379 + Sentinel :26379
quorum = 2（可容忍 1 台机器挂）
跨机房部署
机房 1: Master + Sentinel + Slave
机房 2: Slave + Sentinel
机房 3: Slave + Sentinel
quorum = 2
# 故障转移时优先在同机房的从节点中选主
面试考点
Q1：哨兵节点本身挂了怎么办？
哨兵集群至少 3 个节点，单节点挂掉不影响整体功能，只要剩余哨兵数 ≥ quorum。如果挂了超过半数，哨兵进入只读模式，停止故障转移能力（但现有主从正常服务）。
Q2：哨兵 + 主从和 Redis Cluster 有什么区别？
| 维度 | 哨兵 + 主从 | Redis Cluster |
|---|---|---|
| 数据分片 | ❌ 单点写 | ✅ 自动分片 |
| 写能力 | 单机写瓶颈 | 多节点写 |
| 自动故障转移 | ✅ | ✅ |
| 客户端复杂度 | 低 | 中 |
| 使用场景 | 中小规模 | 大规模（> 单机容量） |
Q3：哨兵为什么要用 Raft 而不是 gossip？
故障转移需要强一致性的 leader 选举，不能有分歧。Raft 保证了在至多半数节点挂掉时仍能选举唯一 leader，而 gossip 是最终一致性协议，不适合这种场景。
总结：哨兵架构由主节点、从节点、哨兵节点三部分构成，哨兵又是分布式应用的最小原型——监控+选举+通知。理解这三者的分工协作是理解 Redis 高可用的基础。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
暂无评论内容