3.1 为什么至少部署三个 Sentinel#

Sentinel 是分布式系统。多个 Sentinel 共同判断故障，可以降低单点故障和误判风险。

两个 Sentinel 并不是稳健部署：

• 若一台机器同时运行 master 和 Sentinel，机器故障后只剩一个 Sentinel。
• 执行故障转移需要 Sentinel 多数派授权。
• 两个 Sentinel 的多数派是两个，剩余一个 Sentinel 无法授权切换。

三个 Sentinel 的多数派是两个，只要仍有两个 Sentinel 互相通信，就有机会完成故障转移。

3.2 Sentinel 应放在不同故障域#

把三个 Sentinel 全部运行在同一台主机，只适合本地实验，不能消除单点故障。

生产建议：

• 分散在不同物理机、虚拟机或可用区。
• 不共用同一个电源、宿主机和网络故障点。
• Sentinel 的网络视角尽量接近业务客户端。
• Sentinel 与 Redis 数据节点之间、Sentinel 彼此之间都要能双向通信。

4.1 发现 replica#

Sentinel 定期向 master 获取复制信息，从 master 报告的拓扑中发现 replica，并继续监控这些 replica。

因此必须保证：

• replica 已正确执行 replicaof。
• master 能报告 replica 的可访问地址。
• Sentinel 能访问 replica 对外通告的 IP 和端口。

4.2 发现其他 Sentinel#

监控同一 master 的 Sentinel 会通过 Redis 实例的 Pub/Sub 频道交换 hello 消息：

1
__sentinel__:hello

hello 消息包含 Sentinel 的地址、端口、运行 ID 和已知 master 配置版本等信息。

这使 Sentinel 能够：

• 自动发现监控同一 master 的其他 Sentinel。
• 交换主节点配置和版本信息。
• 在故障时询问其他 Sentinel 对 master 状态的判断。

4.3 自动改写配置#

Sentinel 会把发现的拓扑、运行 ID、配置纪元和故障转移结果写回 sentinel.conf。

因此：

• 启动 Sentinel 必须提供配置文件。
• Sentinel 对配置文件所在路径必须具有写权限。
• 不应把 sentinel.conf 挂载为只读文件。
• 配置管理系统不应持续用旧模板覆盖 Sentinel 自动写入的运行状态。
• 可以用 SENTINEL FLUSHCONFIG 强制写回当前状态。

5.1 主观下线 SDOWN#

SDOWN 是 Subjectively Down，表示：

某一个 Sentinel 根据自己的观察，认为目标实例不可达。

配置：

1
sentinel down-after-milliseconds mymaster 5000

如果某 Sentinel 在完整的 down-after-milliseconds 时间内没有收到可接受的 PING 响应，就会把目标标记为 SDOWN。

可接受的 PING 响应包括：

• +PONG
• -LOADING
• -MASTERDOWN

SDOWN 是单个 Sentinel 的本地判断，可能由以下问题引发：

• Redis 进程真的宕机。
• Sentinel 到 Redis 的网络中断。
• Redis 阻塞或负载过高，无法及时响应。
• DNS、NAT、防火墙或路由配置错误。

单个 Sentinel 的 SDOWN 不足以触发自动故障转移。

5.2 客观下线 ODOWN#

ODOWN 是 Objectively Down，表示：

至少达到配置的 quorum 数量的 Sentinel 都认为 master 已经下线。

Sentinel 之间会使用内部询问命令交换对 master 的判断。当达到 quorum 后，master 从 SDOWN 进入 ODOWN。

需要注意：

• ODOWN 只针对 master。
• replica 和其他 Sentinel 只会被标记为 SDOWN，不会进入 ODOWN。
• replica 处于 SDOWN 时不会被选为新 master。

5.3 状态变化流程#

1
Redis 正常
2
   │
3
   │ 某 Sentinel 在 down-after-milliseconds 内
4
   │ 没有收到有效响应
5
   ↓
6
该 Sentinel 判定 SDOWN
7
   │
8
   │ 询问其他 Sentinel
9
   │ 达到 quorum 个 Sentinel 同意
10
   ↓
11
Master 被判定 ODOWN
12
   │
13
   │ 获得多数派授权并选出故障转移领导者
14
   ↓
15
开始自动故障转移

6.1 quorum 的作用#

quorum 表示：

至少多少个 Sentinel 同意 master 不可达，才能将 master 标记为 ODOWN。

它用于故障检测，不是 replica 竞选新 master 的票数。

6.2 多数派的作用#

进入 ODOWN 后，还需要选出一个负责本次故障转移的 Sentinel 领导者。真正执行故障转移必须获得 Sentinel 多数派授权。

1
Sentinel 总数 N
2
多数派 = floor(N / 2) + 1

执行故障转移需要同时满足：

1. 达到 quorum，master 被判定为 ODOWN。
2. 某 Sentinel 获得执行故障转移所需的多数派授权；如果 quorum 高于多数派，还必须满足更高的 quorum。

6.3 五个 Sentinel、quorum 为 2 的例子#

1
Sentinel 总数：5
2
quorum：2
3
多数派：3

• 只要 2 个 Sentinel 认为 master 下线，就可触发 ODOWN。
• 但实际执行故障转移时，领导者仍至少需要 3 个 Sentinel 的授权。
• 如果只有 2 个 Sentinel 能相互通信，可能判定 ODOWN，但不能真正完成自动切换。

6.4 quorum 如何选择#

三个 Sentinel 常用：

1
sentinel monitor mymaster 192.168.150.101 7001 2

建议原则：

• 通常使用奇数个 Sentinel。
• 三个 Sentinel 常将 quorum 设为 2。
• quorum 越小，故障检测越敏感，也越容易受局部网络问题影响。
• quorum 越大，误切换概率较低，但自动切换所需的可达 Sentinel 更多。
• 上线前应运行 SENTINEL CKQUORUM 检查 quorum 和多数派条件。

8.1 断线时间筛选#

如果 replica 与 master 断开的时间超过以下范围，会被认为不可靠：

1
(down-after-milliseconds × 10)
2
+ 当前 master 已处于 SDOWN 的持续时间

讲义中常简写成 down-after-milliseconds × 10，完整判断还包含 master 已处于 SDOWN 的时间。

8.2 候选 replica 排序规则#

合格候选者按照以下顺序比较：

1. replica-priority：数值越小，优先级越高。
2. 复制 offset：越大说明接收的数据通常越新，优先级越高。
3. run ID：前两项相同则选择字典序更小的 run ID，用于得到确定性结果。

8.3 replica-priority#

Redis 节点配置：

1
replica-priority 100

特殊值：

1
replica-priority 0

表示该 replica 永远不被 Sentinel 提升为 master，但它仍会继续作为 replica 接收数据，并可在故障转移后改为复制新的 master。

常见使用场景：

• 专门承担备份任务、性能较差的 replica 设置为 0。
• 同机房副本优先级设为 10。
• 异地灾备副本优先级设为 100。

如果一个节点未来可能从 master 变为 replica，建议所有 Redis 实例都配置符合其故障域定位的 replica-priority。

10.1 最小配置示例#

1
port 26379
2
bind 0.0.0.0
3
protected-mode yes
4

5
dir "/var/lib/redis-sentinel"
6

7
sentinel monitor mymaster 192.168.150.101 7001 2
8
sentinel down-after-milliseconds mymaster 5000
9
sentinel failover-timeout mymaster 180000
10
sentinel parallel-syncs mymaster 1

10.2 配置项说明#

10.3 parallel-syncs#

1
sentinel parallel-syncs mymaster 1

设置为 1：

• 每次只让一个 replica 与新 master 重新同步。
• 减少多个 replica 同时加载全量数据造成的服务影响。
• 整体完成时间可能更长。

设置为较大值：

• 可以更快完成所有 replica 的重新配置。
• 可能同时触发多个复制同步，增加 CPU、内存、磁盘和网络压力。
• 如果 replica 在同步加载数据时暂时不可读，可用读副本数量会同时减少。

10.4 failover-timeout#

failover-timeout 参与多种故障转移内部时间控制，包括：

• 一次故障转移尝试的时间边界。
• 失败后再次尝试故障转移的间隔。
• replica 改为复制新 master 时的重配置节奏。

不应把它误解为 master 多久没有响应后才判定故障；后者由 down-after-milliseconds 控制。

12.1 Redis 数据节点要求密码#

密码模式：

1
sentinel auth-pass mymaster redis-data-password

ACL 模式：

1
sentinel auth-user mymaster sentinel-monitor
2
sentinel auth-pass mymaster redis-data-password

这个凭证供 Sentinel 访问 mymaster 对应的 master 和 replica。该组 Redis 数据节点应使用兼容的认证配置。

replica 自己连接 master 时也需要配置：

1
masteruser replication-user
2
masterauth replication-password

12.2 保护 Sentinel 自身#

Sentinel 本身也暴露 Redis 协议端口，不能直接暴露到不可信网络。

密码模式：

1
requirepass "sentinel-password"

使用密码模式时，各 Sentinel 通常要使用相同密码，以便彼此认证。还要确认客户端库支持连接 Sentinel 时发送认证信息。

ACL 模式可以分别配置：

1
sentinel sentinel-user sentinel-admin
2
sentinel sentinel-pass sentinel-admin-password

这组凭证用于 Sentinel 之间的连接。业务客户端访问 Sentinel 时也应使用权限受限的专用用户。

12.3 安全建议#

• 使用 ACL 创建最小权限用户，避免业务客户端使用默认超级用户。
• Sentinel 端口只允许应用服务器、运维网络和其他 Sentinel 访问。
• Redis 数据端口只允许应用、Sentinel 和复制节点访问。
• 跨主机或跨可用区连接考虑启用 TLS。
• 密码不要直接硬编码在代码仓库和公开配置模板中。
• 定期轮换凭证，并验证所有 Sentinel、replica 和客户端均已同步更新。

13.1 Sentinel 地址通告#

1
sentinel announce-ip 192.168.150.101
2
sentinel announce-port 27001

每个 Sentinel 都应通告其他 Sentinel 和客户端实际可达的地址。

13.2 Redis replica 地址通告#

1
replica-announce-ip 192.168.150.102
2
replica-announce-port 7002

否则 master 报告给 Sentinel 的 replica 地址可能是容器内部地址。

13.3 使用主机名#

较新 Redis 版本可以配置 Sentinel 解析和通告主机名：

1
sentinel resolve-hostnames yes
2
sentinel announce-hostnames yes

注意：

• DNS 必须稳定且解析迅速。
• 应统一使用主机名或统一使用 IP，避免混用。
• 部分旧客户端可能只接受 IP 地址。
• TLS 证书校验依赖主机名时，通告主机名通常更合适。

14.1 常用服务发现命令#

1
SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

返回当前 master 的 IP 和端口。

1
SENTINEL REPLICAS mymaster

查看 Sentinel 已知的 replica。

1
SENTINEL SENTINELS mymaster

查看 Sentinel 已知的其他 Sentinel。

15.1 Lettuce 读策略#

现代 Spring Boot 可使用属性控制 Lettuce 读来源，具体可用值取决于当前版本：

1
spring:
2
  data:
3
    redis:
4
      lettuce:
5
        read-from: replica-preferred

也可以通过代码定制：

1
@Bean
2
LettuceClientConfigurationBuilderCustomizer redisReadFromCustomizer() {
3
    return builder -> builder.readFrom(ReadFrom.REPLICA_PREFERRED);
4
}

常见策略含义：

主从复制是异步的。即使写入 master 已返回成功，立即从 replica 读取也可能读取不到新值。

以下场景通常应从 master 读取：

• 写后立即读。
• 分布式锁状态判断。
• 库存、余额、订单状态等强时效数据。
• 依赖最新数据进行后续写入的逻辑。

16.1 为什么故障转移仍可能丢数据#

Redis 主从复制默认异步：

1
客户端 ──写入──→ 旧 Master
2
客户端 ←─OK──── 旧 Master
3
                    │
4
                    │ 写命令尚未复制到 Replica
5
                    × 旧 Master 故障
6

7
Replica 被提升为新 Master，但缺少刚才的写入。

因此 Sentinel 可以缩短故障恢复时间，但不能保证已确认写入一定保留。

16.2 网络分区与旧 master#

网络分区时可能出现：

1. 旧 master 与多数 Sentinel、replica 失联。
2. 多数派一侧把 replica 提升为新 master。
3. 旧 master 所在分区仍可能被部分旧客户端访问并接受写入。
4. 网络恢复后，旧 master 被改为新 master 的 replica。
5. 旧 master 分区期间独有的写入会被新主线覆盖。

16.3 限制旧 master 的孤立写入#

在所有可能成为 master 的 Redis 节点配置：

1
min-replicas-to-write 1
2
min-replicas-max-lag 10

含义：

• master 至少要有 1 个延迟不超过要求的 replica。
• 如果在 10 秒内无法获得足够 replica 的进度确认，master 停止接受写入。

作用：

• 缩短网络分区中旧 master 继续产生孤立写入的时间窗口。
• 降低故障恢复后被覆盖的数据量。

代价：

• replica 故障或网络抖动时，master 可能拒绝写入。
• 系统可用性下降。
• 仍然不是严格同步复制，也不是绝对零丢失保证。

16.4 关键写入使用 WAIT#

1
SET order:1001 paid
2
WAIT 1 1000

表示最多等待 1000 毫秒，希望至少一个 replica 确认已接收到当前连接之前的写入。

应用必须检查 WAIT 的返回值。WAIT 可以提高写入到达 replica 的概率，但：

• 不能把 Redis 变为强一致系统。
• 不等于写入已按业务要求持久化到磁盘。
• 不能替代 AOF、RDB 和独立备份。
• 不能消除客户端重试造成的重复写风险。

17.1 危险组合#

以下组合风险极高：

1
Master 关闭 RDB
2
+ Master 关闭 AOF
3
+ 进程崩溃后自动重启

可能过程：

1. master 崩溃。
2. 进程管理器迅速把它自动重启。
3. 因无持久化文件，master 以空数据集启动。
4. Sentinel 可能尚未完成故障转移。
5. replica 继续把空 master 当作复制源。
6. 空数据集被同步给 replica，整个复制组的数据一起丢失。

因此：

• 不要把 Sentinel 当作持久化和备份。
• master 关闭持久化时，不应允许它在故障后未经控制地空数据自动重启。
• 所有可能成为 master 的节点都应具备符合业务 RPO 的恢复能力。
• 备份应放在复制组之外，防止误删命令和逻辑错误同步到所有副本。

18.1 查询状态#

1
PING
2
INFO sentinel
3
ROLE
4
SENTINEL MASTERS
5
SENTINEL MASTER mymaster
6
SENTINEL REPLICAS mymaster
7
SENTINEL SENTINELS mymaster
8
SENTINEL GET-MASTER-ADDR-BY-NAME mymaster
9
SENTINEL CKQUORUM mymaster

18.2 动态配置#

修改 master 专属配置：

1
SENTINEL SET mymaster down-after-milliseconds 10000
2
SENTINEL SET mymaster parallel-syncs 1

修改 Sentinel 全局配置：

1
SENTINEL CONFIG GET *
2
SENTINEL CONFIG SET resolve-hostnames yes

动态修改应在所有 Sentinel 上保持一致。只修改一个 Sentinel，不会自动把该项运行时配置传播给所有 Sentinel。

18.3 手动触发故障转移#

1
SENTINEL FAILOVER mymaster

该命令会强制 Sentinel 为指定 master 发起故障转移，不需要先把 master 判定为 ODOWN。

使用前必须确认：

• 存在健康且复制进度合适的 replica。
• 客户端具备重连能力。
• 监控和回滚方案已经准备。
• 不会与正在进行的自动故障转移冲突。

18.4 订阅事件#

1
PSUBSCRIBE *

常见 Sentinel 日志和 Pub/Sub 事件：