Redis Sentinel

一、架构定位与第一性原理

1.1 Sentinel 的本质定义

Redis Sentinel 是一个：

去中心化的主节点裁决系统（Distributed Master Arbitration System），在 异步复制 + 弱一致性 的前提下，为 Redis 主从架构提供 自动化故障发现、主节点切换与客户端重定向能力。

它并不复制数据，也不参与业务请求处理，而是专注于一个核心问题：

当“谁是主节点”出现不确定性时，由谁、以什么规则、在什么条件下做出裁决。

1.2 Sentinel 解决的问题与不解决的问题

维度Sentinel 做的事Sentinel 不做的事
可用性自动主从切换不保证服务零中断
一致性裁决主节点身份不保证数据不丢失
架构职责状态感知与协调不参与数据复制
客户端提供主节点发现不屏蔽业务异常

关键设计取舍：Sentinel 明确选择了 可用性优先（Availability First）。

二、整体架构与角色模型

2.1 系统角色分工（职责边界）

角色核心职责设计哲学
Redis Master提供写服务单点、性能优先
Redis Slave数据复制、读扩展异步、弱一致
Sentinel主节点裁决与通知去中心化、多数决
Client连接与重试感知变化、自适应

Sentinel 只负责“判断与通知”，而不是“修复所有问题”。

三、Sentinel 的能力模型（结构化认知）

3.1 能力树总览

Redis Sentinel 能力模型├── 状态感知│   ├── 心跳检测（Ping）│   ├── 主观下线（sdown）│   └── 客观下线（odown）├── 共识裁决│   ├── Gossip 信息扩散│   ├── 法定人数（Quorum）│   └── 领导者选举├── 故障转移│   ├── 新主节点选择策略│   ├── 主从拓扑重组│   └── 客户端变更通知├── 系统协作│   ├── 与 Redis Replication 协作│   └── 与 Client 的契约└── 运维治理    ├── 部署与隔离策略    ├── 多集群管理    └── 运维控制接口

四、状态感知：从局部怀疑到系统事实

4.1 三类定时机制的抽象意义

Sentinel 的定时任务不是“实现细节”，而是 状态收敛机制：

机制抽象目的
INFO 拉取构建全局拓扑视图
Gossip 消息消除单点认知偏差
Ping 心跳最小成本的生存探测

4.2 sdown 与 odown 的哲学差异

分布式系统的核心原则：单点怀疑 ≠ 系统事实

五、共识裁决：Sentinel 如何“达成一致”

5.1 Sentinel 与共识算法的关系

Sentinel 借鉴共识思想，但不是完整共识系统。

维度SentinelRaft
目标主节点裁决日志一致性
一致性粒度节点状态数据操作
强度弱一致强一致
是否复制数据否是

Sentinel 的共识是 “是否切换 + 切到谁”，而不是“数据是否一致”。

5.2 为什么需要 Leader Sentinel

Leader 的角色：

共识的执行者，而不是权力中心。

六、故障转移：一次受控的系统重组

6.1 新主节点选择的设计原则

选择顺序背后的抽象逻辑：

  1. **可达性优先**（活着比完整更重要）
  2. **数据新鲜度优先**（复制偏移量）
  3. **稳定性优先**（优先级、运行时间）

这不是“规则堆叠”，而是 风险最小化策略。

6.2 故障转移的系统级因果链

节点异常  ↓主观下线（sdown）  ↓客观下线（odown）  ↓领导者选举  ↓新主节点裁决  ↓拓扑重组  ↓客户端感知变化

七、数据丢失：设计必然性，而非缺陷

7.1 数据丢失的根因模型

异步复制  ↓主从状态不一致  ↓网络分区  ↓错误主节点继续写入  ↓主备切换  ↓写入回滚（数据丢失）

7.2 Sentinel 的设计立场

Sentinel 不是为“零数据丢失”而生，而是为“快速恢复服务”而生。

八、部署与治理：架构稳定性的外延

8.1 Sentinel 数量与分布原则

8.2 一套 vs 多套 Sentinel

方案优点风险
单 Sentinel 集群成本低故障影响面大
多 Sentinel 集群隔离性强运维复杂

九、客户端协作模型（被忽视的关键角色）

客户端必须承担的责任：

没有“傻客户端”的高可用系统。

十、选型与演进视角

10.1 Sentinel 适合的场景

场景是否适合
缓存 / 会话✅
读多写少✅
简单高可用✅
强一致金融系统❌

10.2 与其他方案的哲学差异

关联内容（自动生成）