📚 课程目录第4章 Sentinel部署架构设计

4. Sentinel部署架构设计

Sentinel 的高可用能力并不来自单个进程，而是来自“多个 Sentinel 对同一组主从实例达成共识”的机制。因此，部署架构设计的核心问题不是“装几个 Sentinel”，而是：在可接受的故障判定速度、误判概率、网络分区风险和运维成本之间，选择一种与业务机房分布相匹配的仲裁拓扑。本节围绕单 Sentinel、多 Sentinel、跨机房部署、仲裁人数、网络分区容忍与生产选型展开。

一、单 Sentinel：能自动切换，但不具备高可用

单 Sentinel 架构是最简单的形态：一个 Sentinel 进程监控一个 master 及其 slaves，当 master 被判定为客观下线后，由这个 Sentinel 自己完成 leader 选举（实际上只有它一个候选者）并执行故障转移。它的优点是部署简单、无需协商、切换决策快；缺点是 Sentinel 自身成为单点——进程崩溃、所在主机宕机或网络中断，整个自动故障转移能力就消失。

更关键的是，单 Sentinel 无法形成“客观下线”的多数派判断。Redis Sentinel 规定：主观下线（SDOWN）是单个 Sentinel 的判断，客观下线（ODOWN）需要达到配置的 quorum 数量。单 Sentinel 场景下 quorum 只能设为 1，任何一次网络抖动或慢查询都可能被误判为 master 下线，从而触发不必要的切换。因此，单 Sentinel 只适合开发测试、演示环境或对可用性要求极低的内部系统，不应作为生产架构。

二、多 Sentinel：奇数节点与 quorum 的配合

生产环境通常部署 3 个或 5 个 Sentinel 节点。选择奇数的原因是：在多数派投票中，奇数节点能以更少的机器获得明确的多数，避免平票。例如 3 个 Sentinel 的多数派是 2，5 个的多数派是 3。若部署 2 个 Sentinel，当两者网络互相隔离时，任何一方都无法获得多数派，系统进入无法决策状态，反而比单 Sentinel 更复杂。

多 Sentinel 中有两个容易混淆的参数：quorum 和 majority。quorum 是判定 master 客观下线所需的 Sentinel 数量，配置在 sentinel monitor 指令中；majority 是执行故障转移前选举 leader 所需的票数，其值为 Sentinel 总数的一半加一。举例：3 个 Sentinel、quorum=2 时，需要至少 2 个 Sentinel 认为 master 下线才标记 ODOWN；随后 leader 选举需要 2 票（3/2+1=2）。若 quorum 设为 1，虽然能更快标记 ODOWN，但 leader 选举仍需多数派，因此不会因为 quorum 过低而让单个 Sentinel 独断切换。

# sentinel.conf 关键片段（3 节点示例）
sentinel monitor mymaster 10.0.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

其中 down-after-milliseconds 决定主观下线的判定时间，parallel-syncs 控制故障转移后同时向新 master 发起同步的 slave 数量，设为 1 可避免所有 slave 同时全量同步导致新 master 负载骤增。

三、跨机房部署与网络分区容忍

跨机房部署的难点在于：Sentinel 的故障判定依赖网络可达性，而机房之间的链路延迟和中断概率远高于机架内。若把 Sentinel 均匀分布在两个机房，例如机房 A 两个、机房 B 一个，当 A、B 之间链路中断时，A 中的两个 Sentinel 可以形成多数派并触发切换，但 B 中的 Sentinel 会认为 A 侧全部不可达。此时如果 master 在 A 机房，A 侧切换出一个新 master，而 B 侧仍保留旧 master 的认知，就可能出现双 master 写入，造成数据分叉。

因此跨机房部署必须明确“主机房”概念：把多数 Sentinel 和 master 放在同一主机房，备机房只放少量 Sentinel 或只放 slave。这样即使跨机房链路中断，主机房内部仍能形成多数派并完成切换；备机房在链路恢复后通过 Sentinel 的配置传播重新同步。若业务要求机房级容灾，更稳妥的做法是采用 Redis Cluster 或由外部协调服务（如 etcd、Consul）管理主从切换，而不是单纯依赖跨机房 Sentinel。

四、仲裁人数与网络分区容忍的取舍

仲裁人数直接决定系统对网络分区的容忍方式。以 3 个 Sentinel 为例，若它们分布在 3 个不同机架或可用区，任意一个节点失联，剩余 2 个仍能形成多数派，系统可继续工作；若 2 个节点同时失联，剩余 1 个无法形成多数派，系统停止自动切换，但也不会产生双 master。这是一种“宁可停止切换，也不错误切换”的保守策略，适合数据一致性优先的场景。

若把 quorum 调低到 1，虽然单个 Sentinel 就能标记 ODOWN，但 leader 选举仍需多数派，因此并不会真正提升分区容忍度，反而可能让某个孤立 Sentinel 反复发起无效选举，增加日志噪声和网络开销。因此生产实践中，quorum 通常设为 Sentinel 总数的一半加一，与 majority 保持一致，使判定和选举的门槛统一。

五、生产环境选型建议

综合来看，生产环境选型可遵循以下判断：

单机房、3 节点：最常见。3 个 Sentinel 部署在 3 台独立物理机或虚拟机上，quorum=2，majority=2。可容忍 1 个 Sentinel 故障。
单机房、5 节点：适用于对误判更敏感的核心业务。quorum=3，majority=3，可容忍 2 个 Sentinel 故障，但运维成本更高。
同城双机房：主机房放 2 个 Sentinel + master，备机房放 1 个 Sentinel + slave。quorum=2，majority=2。跨机房链路中断时，主机房仍可切换；备机房 Sentinel 不参与决策。
异地多活或强容灾：不建议仅靠 Sentinel 跨地域部署，应结合 Redis Cluster、外部协调服务或业务层双写策略。

注意：Sentinel 节点应部署在独立于 Redis 数据节点的机器上。若 Sentinel 与 master 同机，主机宕机时两者同时失效，Sentinel 无法参与仲裁，故障转移能力随之丧失。

最后需要强调：Sentinel 架构设计不是一次性的，而应随业务规模、机房布局和 SLA 要求持续调整。每次调整 quorum、节点数量或机房分布后，都应通过模拟 master 宕机、网络隔离和 Sentinel 进程退出等方式验证切换行为是否符合预期，确认 ODOWN 标记时间、leader 选举结果和新 master 的 slave 同步状态，才能认为该架构真正可用。