{"name":"哨兵","id":"中间件-数据库-redis-哨兵","content":"# Redis Sentinel\n\n## 一、架构定位与第一性原理\n\n### 1.1 Sentinel 的本质定义\n\n**Redis Sentinel 是一个：**\n\n> **去中心化的主节点裁决系统（Distributed Master Arbitration System）**，\n> 在 **异步复制 + 弱一致性** 的前提下，\n> 为 Redis 主从架构提供 **自动化故障发现、主节点切换与客户端重定向能力**。\n\n它并不复制数据，也不参与业务请求处理，而是专注于一个核心问题：\n\n> **当“谁是主节点”出现不确定性时，由谁、以什么规则、在什么条件下做出裁决。**\n\n---\n\n### 1.2 Sentinel 解决的问题与不解决的问题\n\n| 维度   | Sentinel 做的事 | Sentinel 不做的事 |\n| ---- | ------------ | ------------- |\n| 可用性  | 自动主从切换       | 不保证服务零中断      |\n| 一致性  | 裁决主节点身份      | 不保证数据不丢失      |\n| 架构职责 | 状态感知与协调      | 不参与数据复制       |\n| 客户端  | 提供主节点发现      | 不屏蔽业务异常       |\n\n> **关键设计取舍**：Sentinel 明确选择了 **可用性优先（Availability First）**。\n\n---\n\n## 二、整体架构与角色模型\n\n### 2.1 系统角色分工（职责边界）\n\n| 角色           | 核心职责     | 设计哲学     |\n| ------------ | -------- | -------- |\n| Redis Master | 提供写服务    | 单点、性能优先  |\n| Redis Slave  | 数据复制、读扩展 | 异步、弱一致   |\n| Sentinel     | 主节点裁决与通知 | 去中心化、多数决 |\n| Client       | 连接与重试    | 感知变化、自适应 |\n\n> Sentinel **只负责“判断与通知”**，而不是“修复所有问题”。\n\n---\n\n## 三、Sentinel 的能力模型（结构化认知）\n\n### 3.1 能力树总览\n\n```\nRedis Sentinel 能力模型\n├── 状态感知\n│   ├── 心跳检测（Ping）\n│   ├── 主观下线（sdown）\n│   └── 客观下线（odown）\n├── 共识裁决\n│   ├── Gossip 信息扩散\n│   ├── 法定人数（Quorum）\n│   └── 领导者选举\n├── 故障转移\n│   ├── 新主节点选择策略\n│   ├── 主从拓扑重组\n│   └── 客户端变更通知\n├── 系统协作\n│   ├── 与 Redis Replication 协作\n│   └── 与 Client 的契约\n└── 运维治理\n    ├── 部署与隔离策略\n    ├── 多集群管理\n    └── 运维控制接口\n```\n\n---\n\n## 四、状态感知：从局部怀疑到系统事实\n\n### 4.1 三类定时机制的抽象意义\n\nSentinel 的定时任务不是“实现细节”，而是 **状态收敛机制**：\n\n| 机制        | 抽象目的      |\n| --------- | --------- |\n| INFO 拉取   | 构建全局拓扑视图  |\n| Gossip 消息 | 消除单点认知偏差  |\n| Ping 心跳   | 最小成本的生存探测 |\n\n---\n\n### 4.2 sdown 与 odown 的哲学差异\n\n* **sdown（主观下线）**：\n\n  * 个体视角的怀疑\n  * 不足以触发系统级动作\n\n* **odown（客观下线）**：\n\n  * 群体共识的事实\n  * 触发架构变更的唯一入口\n\n> **分布式系统的核心原则：单点怀疑 ≠ 系统事实**\n\n---\n\n## 五、共识裁决：Sentinel 如何“达成一致”\n\n### 5.1 Sentinel 与共识算法的关系\n\nSentinel **借鉴共识思想，但不是完整共识系统**。\n\n| 维度     | Sentinel | Raft  |\n| ------ | -------- | ----- |\n| 目标     | 主节点裁决    | 日志一致性 |\n| 一致性粒度  | 节点状态     | 数据操作  |\n| 强度     | 弱一致      | 强一致   |\n| 是否复制数据 | 否        | 是     |\n\n> Sentinel 的共识是 **“是否切换 + 切到谁”**，而不是“数据是否一致”。\n\n---\n\n### 5.2 为什么需要 Leader Sentinel\n\n* 减少并发切换\n* 保证拓扑调整的原子性\n* 将“共识判断”与“执行动作”解耦\n\nLeader 的角色：\n\n> **共识的执行者，而不是权力中心**。\n\n---\n\n## 六、故障转移：一次受控的系统重组\n\n### 6.1 新主节点选择的设计原则\n\n选择顺序背后的抽象逻辑：\n\n1. **可达性优先**（活着比完整更重要）\n2. **数据新鲜度优先**（复制偏移量）\n3. **稳定性优先**（优先级、运行时间）\n\n这不是“规则堆叠”，而是 **风险最小化策略**。\n\n---\n\n### 6.2 故障转移的系统级因果链\n\n```\n节点异常\n  ↓\n主观下线（sdown）\n  ↓\n客观下线（odown）\n  ↓\n领导者选举\n  ↓\n新主节点裁决\n  ↓\n拓扑重组\n  ↓\n客户端感知变化\n```\n\n---\n\n## 七、数据丢失：设计必然性，而非缺陷\n\n### 7.1 数据丢失的根因模型\n\n```\n异步复制\n  ↓\n主从状态不一致\n  ↓\n网络分区\n  ↓\n错误主节点继续写入\n  ↓\n主备切换\n  ↓\n写入回滚（数据丢失）\n```\n\n### 7.2 Sentinel 的设计立场\n\n* 选择 **AP（可用性 + 分区容忍）**\n* 放弃 **强一致写安全**\n\n> Sentinel 不是为“零数据丢失”而生，而是为“快速恢复服务”而生。\n\n---\n\n## 八、部署与治理：架构稳定性的外延\n\n### 8.1 Sentinel 数量与分布原则\n\n* 至少 3 个（奇数）\n* 跨物理机 / 可用区\n* 避免与 Redis 节点强耦合\n\n### 8.2 一套 vs 多套 Sentinel\n\n| 方案            | 优点   | 风险     |\n| ------------- | ---- | ------ |\n| 单 Sentinel 集群 | 成本低  | 故障影响面大 |\n| 多 Sentinel 集群 | 隔离性强 | 运维复杂   |\n\n---\n\n## 九、客户端协作模型（被忽视的关键角色）\n\n客户端必须承担的责任：\n\n* 主节点变化感知\n* 重试与幂等控制\n* 写失败容忍\n\n> **没有“傻客户端”的高可用系统**。\n\n---\n\n## 十、选型与演进视角\n\n### 10.1 Sentinel 适合的场景\n\n| 场景      | 是否适合 |\n| ------- | ---- |\n| 缓存 / 会话 | ✅    |\n| 读多写少    | ✅    |\n| 简单高可用   | ✅    |\n| 强一致金融系统 | ❌    |\n\n### 10.2 与其他方案的哲学差异\n\n* Sentinel：快速恢复、低复杂度\n* Redis Cluster：分片 + 自动迁移\n* etcd / Zookeeper：强一致协调\n\n## 关联内容（自动生成）\n\n- [/中间件/数据库/redis/复制.md](/中间件/数据库/redis/复制.md) Redis复制机制是哨兵模式的基础，哨兵主要监控的就是Redis的主从复制架构，了解复制机制有助于理解哨兵如何判断主从状态\n- [/中间件/数据库/redis/集群.md](/中间件/数据库/redis/集群.md) Redis集群提供了另一种高可用方案，与哨兵模式在架构设计和故障处理上有异同，可对比参考\n- [/中间件/数据库/redis/Redis.md](/中间件/数据库/redis/Redis.md) 作为Redis整体介绍文档，提供了Redis的基础概念和架构背景，有助于理解哨兵在整个Redis生态中的定位\n- [/软件工程/架构/系统设计/分布式/分布式共识算法.md](/软件工程/架构/系统设计/分布式/分布式共识算法.md) 哨兵系统涉及分布式一致性问题和领导者选举，相关共识算法为理解哨兵的决策机制提供理论基础\n- [/软件工程/架构/系统设计/可用性.md](/软件工程/架构/系统设计/可用性.md) 哨兵系统的核心目标是保障Redis的高可用性，该文档提供了可用性的通用设计原则和实践\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 从分布式系统整体视角理解哨兵模式在分布式架构中的作用和设计原理\n- [/中间件/数据库/文档数据库.md](/中间件/数据库/文档数据库.md) 其他数据库的高可用实现方式，如MongoDB的副本集，可与Redis哨兵进行对比分析\n- [/软件工程/架构/系统设计/网关.md](/软件工程/架构/系统设计/网关.md) 网关的高可用设计与哨兵有相似之处，都是为了保障系统组件的可用性\n- [/运维/K8s.md](/运维/K8s.md) Kubernetes的高可用架构设计，提供了另一种分布式系统高可用的实现思路\n- [/软件工程/架构/系统设计/流量控制.md](/软件工程/架构/系统设计/流量控制.md) Sentinel作为流量控制组件与Redis哨兵在概念上有相似之处，但应用场景不同\n","metadata":"tags: ['数据库', '分布式系统', '架构设计']","hasMoreCommit":false,"totalCommits":5,"commitList":[{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-12-25T17:24:13+08:00","author":"MY","message":"docs(redis): 重构Redis哨兵文档结构并完善技术细节","hash":"ff7baece67c8f5fdbee59ebe4b38d42722dcfb3e"},{"date":"2023-12-11T19:59:23+08:00","author":"MY","message":"✏Redis","hash":"2f7e29a08817db6f3ce12f5fc78d44c23e8b1412"},{"date":"2023-11-16T18:57:34+08:00","author":"MY","message":"✏Redis","hash":"7955ae3a5874322931281a113be629782a29c57a"},{"date":"2020-11-05T16:53:44+08:00","author":"MY","message":"📦重构 Redis","hash":"436d256214f45aea37f8659d4758b82fe1709560"}],"createTime":"2020-11-05T16:53:44+08:00"}