Redis哨兵

Sentinel(哨兵)只是Redis的一种运行模式,不提供读写服务,默认在26379端口上,依赖于Redis工作.当主从复制中的主节点出现故障时，Redis Sentinel (哨兵)能自动地、快速地完成主从切换，保证服务的高可用性.

定义

Redis Sentinel 是一个分布式系统，它专门用于监控 Redis 主从复制集群。它不是单个进程，而通常由一个 Sentinel 集群（推荐至少3个Sentinel实例）组成，共同协作。

Sentinel核心职责

监控 (Monitoring)： Sentinel 会持续不断地检查主节点和从节点是否正常工作（通过 PING、INFO 等命令）。
通知 (Notification)： 当被监控的 Redis 实例出现问题时，Sentinel 可以通过 API 或执行外部脚本通知系统管理员或其他应用程序。
自动故障转移 (Automatic Failover)：

这是 Sentinel 最核心的功能。如果主节点被确认无法工作（达到客观下线 ODown 状态），Sentinel 集群会选举出一个领头羊 Sentinel，由它来执行故障转移：
1. 从健康的从节点中挑选一个最合适的提升为新的主节点。
2. 配置其他从节点去复制这个新的主节点。
配置提供者 (Configuration Provider)： Sentinel 还充当了客户端服务发现的角色。客户端可以连接到 Sentinel 来获取当前指定主服务名称 (master-name) 对应的主节点地址。当发生故障转移后，客户端可以从 Sentinel 获取到新的主节点信息，从而无缝切换。

Sentinel如何工作

**主观下线(Subjectively Down, SDOWN):**如果master在指定时间内(down-after-milliseconds配置项指定,默认30s)未响应sentinel的PING命令,或返回无效回复,该sentinel会将其标记为主观下线.但这仅仅是单个sentinel的判断,还需要其他sentinel节点的投票
**客观下线(Objectively Down, ODOWN):**当一个sentinel将master标记为SDOWN后,它会向其他监控相同的master的sentinel发送is-master-down-by-addr命令,询问它们是否也认为master SDOWN.如果足够数量(quorum配置项指定,通常为过半)的sentinel实例也认为master SDOWN,则该sentinel实例会将master标记为客观下线
**故障转移(Failover):**只有当master被标记为ODOWN后,sentinel才会启动故障转移流程,选举新的master
Master恢复后的处理:
- **SDOWN阶段恢复:**如果master在被标记为SDOWN后,但在达到ODOWN之前恢复相应,sentinel会取消SDOWN标记,master恢复正常工作,不会触发故障转移
- **ODOWN阶段及之后恢复:**如果master在被标记为ODOWN后,也就是故障转移已经完成后恢复相应.sentinel会自动将其配置为新的master的从节点.无需手动操作.若原master因网络隔离或配置问题未自动加入集群,需手动执行REPLICAOF和SLAVEOF

每个Sentinel进程都需要一个配置文件,通常命名为sentinel.conf:

# Sentinel 监听的端口，默认为 26379
port 26379

# 指定 Sentinel 的工作目录 (可选)
# dir /tmp

# 监控一个名为 <master-name> 的主节点，其地址为 <ip>:<port>
# <quorum> 是判定主节点客观下线所需的 Sentinel 数量
# 例如：监控名为 mymaster 的主节点，地址 127.0.0.1:6379，至少需要2个Sentinel同意才算ODown
sentinel monitor mymaster 127.0.0.1 6379 2

# 主节点被 Sentinel 认定为 SDown 所需的失联时间 (毫秒)
sentinel down-after-milliseconds mymaster 30000

# 在故障转移期间，最多可以有多少个从节点同时对新的主节点进行同步。
# 值越小，完成故障转移所需时间越长；值越大，对新主节点的负载压力越大。
sentinel parallel-syncs mymaster 1

# 故障转移超时时间 (毫秒)。如果在这个时间内领头羊Sentinel未能完成故障转移，
# 其他Sentinel可以尝试重新发起选举和故障转移。
sentinel failover-timeout mymaster 180000

# 如果被监控的主节点设置了密码 (requirepass)
# sentinel auth-pass <master-name> <password>
# 例如: sentinel auth-pass mymaster MyRedisP@ssw0rd

# (Redis 6.0+ ACL) 如果主节点使用了ACL认证，需要用户名和密码
# sentinel auth-user <master-name> <username>

# (可选) 当发生特定事件时，可以配置 Sentinel 执行外部脚本
# sentinel notification-script <master-name> /path/to/notification-script.sh
# sentinel client-reconfig-script <master-name> /path/to/reconfig-script.sh

# (可选) Sentinel自身的日志文件
# logfile "/var/log/redis/sentinel.log"

Sentinel如何选择出新的master

slave必须处在在线状态才能参加新的master选举,筛选所有在线的slave后,会通过下面3个纬度进行最后的筛选(优先度依次降低):

slave优先级:可以通过修改replica-priority(redis.conf中配置,在Redis5.0前配置属性名称为slave-priority)配置的值来手动设置slave的优先级.slave-priority默认值为100,其值越小得分越高,越有机会成为master.如果一个slaveslave-priority的值为0,那么该slave没有参加master选举的资格.如果没有优先级最高的,会判断复制进度
**复制进度:**Sentinel总是希望选出数据最完整(与旧master数据最接近)的slave提升为新的master,数据越完整得分也就越高
**runid(运行ID):**通常经过前两轮会选出新的master,但是没有选出来的话,那么runid小的会成为新的master,每个redis节点启动时都有一个40字节随机字符串作为运行id

Sentinel避免脑裂

Redis 中的**“脑裂”（Split-Brain)**是指在 Redis 的主从复制（Replication）或哨兵（Sentinel）/集群（Cluster）等高可用架构中，由于网络分区或其他故障，导致系统中出现多个主节点（Master）同时对外提供服务的情况。这些“主节点”都认为自己是唯一合法的写入点，从而导致数据不一致甚至数据丢失。

Sentinel通过以下配置可以避免Redis脑裂:

min-replicas-to-write <number>（Redis 5.0 及以后版本，旧版本为 min-slaves-to-write）：这个参数要求主节点在处理写请求时，必须至少有指定数量的从节点处于连接状态。如果连接的从节点数量少于设定值，主节点将拒绝写操作。这可以在网络分区导致主节点与大部分从节点失联时，阻止旧主节点继续接受写请求，从而减少脑裂后旧主节点的数据量。
min-replicas-max-lag <seconds>（Redis 5.0 及以后版本，旧版本为 min-slaves-max-lag）：这个参数要求连接到主节点的从节点，其最后一次与主节点通信的延迟不能超过指定的秒数。如果所有从节点的延迟都超过这个值，主节点也会拒绝写操作。这有助于确保主节点不会在从节点数据严重滞后的情况下继续写入。

优势与局限性

优势： 实现了对单个主从复制架构的自动故障转移，大大提高了系统的可用性。
局限性：
- Sentinel 管理的仍然是一个逻辑上的单一数据集（所有数据都在一个主节点上及其副本）。
- 它不能解决数据量过大导致的单主节点内存瓶颈问题。
- 它也不能解决写并发过高导致的单主节点性能瓶颈问题。

当我们需要存储远超单机内存容量的数据，或者需要通过分散写压力来提升整体性能时，就需要 Redis 的终极解决方案——Redis Cluster。

Redis10_深入理解哨兵模式