Sentinel(哨兵) 模式

概述

参考：
官方文档
中文文档
博客园大佬
博客园大佬 2

Redis Sentinel(哨兵) 基于 Redis 的 Replication(复制) 模式，增加了一个名为 Sentinel 的管理程序，用来保存 Redis Replication 模式的架构信息，以及对外提供该信息。同时 sentinel 程序监控多台 Redis 状态，当 Redis 不可用时，Sentinel 将自动下线该 Redis。

注意：Sentinel(哨兵) 模式必须基于 Replication 模式，否则没有任何意义。

注意：一套 Sentinel 是可以监听多套 Replication 模式的 Redis 的组合，这样可以有效节省资源，其中每套 Replication 模式的 Redis 会使用一个 master-name 作为一个标识。

客户端操作 Redis 原理

client 访问 sentinel 集群，获取 redis 集群 master 的 ip
client 连接 redis 集群的 master 对数据进行读写操作。

Redis Sentinel 为 Redis 提供了高可用性。这意味着，可以使用 Sentinel 程序部署 Redis，这种部署可以在无需人工干预的情况下抵抗某些类型的故障。Sentinel 具有以下特性：

Monitoring(监控)# Sentinel 会不断检查指定的 master 和 replica 节点是否正常工作。
Notification(通知)# 当 Sentinel 监控的 Redis 出现问题时，可以通过 API 向人或程序发送通知。
Automatic failover(自动故障转移)# 如果 master 节点未按预期工作，则 Sentinel 将会启动 Failover(故障转移) 过程。在这个过程中，replica 节点将会升级为 master 节点，其他的 replica 节点将使用新的 master 信息。
- 在故障转移期间，所有 Redis 节点的配置文件、所有 Sentinel 节点的配置文件，都会被自动更新。正是由于这种机制，Sentinel 才可以正常完整自动故障转移流程。
Configuration provider(配置提供器) # Sentinel 作为客户端服务发现的权威来源：客户端连接到 Sentinels，以便询问负责特定服务的当前 Redis Master 节点的地址。如果发生故障转移，Sentinels 将报告新的地址。

Sentinel 配置

/etc/sentinel.conf # Sentinel 主程序的配置文件

基本配置示例

sentinel monitor mymaster 172.19.42.231 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

Sentinel 和 Replicas 的自动发现机制

参考：官方文档

虽然 Sentinel 集群中各个 Sentinel 都互相连接彼此来检查对方的可用性以及互相发送消息。但是不用为任何一个 Sentinel 手动配置其它的 Sentinel 的信息。因为 Sentinel 利用了 Redis 的 Pub/Sub(发布/订阅) 机制去自动发现，监控了相同的 master 和 replica 的其他 Sentinel 节点。

通过向名为__sentinel__:hello的频道中发送消息来实现自动发现 Sentinel 节点的功能。

同样，也不需要在 Sentinel 中配置某个 master 的所有 replica 的地址，Sentinel 会通过询问 master 来得到这些 replica 的地址的。

所以，Sentinel 具有两个发现机制

Sentinel 发现监控相同目标的其他 Sentinel 节点
Sentinel 发现监控目标的 Replica 节点

自动发现流程

每隔 2 秒钟，每个 Sentinel 向每个 master 和 replica 中的__sentinel__:hello 频道，发布一条消息，消息内容为发布消息的 Sentinel 的 IP、PORT、runid。
每个 Sentinel 也订阅了每个 master 和 replica 中的 __sentinel__:hello 频道，以便发现未知的 Sentinel ，当检测到了新的 Sentinel ，则将其加入到自身维护的 master 监控列表中。
每个 Sentinel 发送的消息中也包含了其当前维护的最新的 master 配置。如果某个 Sentinel 发现自己的配置版本低于接收到的配置版本，则会用新的配置更新自己的 master 配置。
在添加一个新的 sentinel 前，sentinel 总是检查是否已经有 sentinel 与新的 sentinel 的进程号或者是地址是一样的。如果是那样，这个 sentinel 将会被删除，而把新的 sentinel 添加上去。

自动发现后配置文件变化效果

当我们想要启动 Sentienl 时，仅仅需要配置一些基本信息，以及要监控的目标 IP 与 PORT，即可使用该文件启动了。以该文件启动 Sentinel 后，Sentinel 将会根据自动发现功能，补全这些配置，效果如下：

# 手动写的 Sentinel 运行时配置文件
[root@master-1 config]# cat sentinel.conf
sentinel monitor mymaster 172.19.42.231 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

[root@master-1 config]# docker restart redis-sentinel
redis-sentinel

# Sentinel 启动后，配置文件变成如下样子
# 这就是根据自动发现机制，发现了其他的 sentinel 节点以及其他 replica 节点
[root@master-1 config]# cat sentinel.conf
sentinel myid c3463c1f451f766b13947ea315f4f38e7c7296f0
sentinel deny-scripts-reconfig yes
sentinel monitor mymaster 172.19.42.231 6379 2
sentinel down-after-milliseconds mymaster 60000
# Generated by CONFIG REWRITE
port 26379
dir "/data"
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel known-replica mymaster 172.19.42.232 6379
sentinel known-replica mymaster 172.19.42.233 6379
sentinel known-sentinel mymaster 172.19.42.233 26379 bda131accb328d1254cf95b8a918d85d262c72c2
sentinel known-sentinel mymaster 172.19.42.232 26379 0d4e5dffff14df5fb54b1a00b7d286f0f22eb74e
sentinel current-epoch 0

Sentinel 工作流程

名词解释

SDOWN(主观下线) 与ODOWN(客观下线) # 参考：https://www.cnblogs.com/kevingrace/p/9004460.html

Configuration Epochs(配置时代) # 类似 Raft 算法中的 term(任期) 概念。参考：官方文档

Monitoring(监控)

每个 Sentinel 以每秒钟一次的频率向它所知的 Master，Slave 以及其他 Sentinel 实例发送一个 PING 命令。
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 own-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel 标记为主观下线。
如果一个 Master 被标记为主观下线，则正在监视这个 Master 的所有 Sentinel 要以每秒一次的频率确认 Master 的确进入了主观下线状态。
当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认 Master 的确进入了主观下线状态，则 Master 会被标记为客观下线。
在一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 INFO 命令。
当 Master 被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
若没有足够数量的 Sentinel 同意 Master 已经下线，Master 的客观下线状态就会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复，Master 的主观下线状态就会被移除。三个定时任务

Sentinel 在内部有 3 个定时任务

每 10 秒 sentinel 会对 master 和 slave 执行 info 命令，这个任务达到两个目的：
- 发现 slave 节点
- 确认主从关系
每 2 秒 sentinel 通过 master 节点的 channel 交换信息（pub/sub）。master 节点上有一个发布订阅的频道(sentinel:hello)。sentinel 节点通过 __sentinel__:hello 频道进行信息交换(对节点的"看法"和自身的信息)，达成共识。
每 1 秒 sentinel 对其他 sentinel 和 redis 节点执行 ping 操作(相互监控)。这个其实是一个心跳检测，是失败判定的依据。

Failover(故障转移)

一个 sentinel 发现 master 离线，争取 sentinel 集群大多数节点认可，认可成功则确认该 master 离线，开始故障转移。

选出一个 slave 服务器，将其升级为 master

向被选中的从服务器发送 REPLICAOF NO ONE 命令，让它变为主服务器。

通过发布与订阅功能，将更新后的配置推送给其他 Sentinel。

向已下线主服务器的从服务器发送 REPLICAOF host port 命令，让它们去复制新的主服务器。

所有 Sentinel 发送 sentinel flushconfig 命令刷新配置文件。所有 Redis master 和 replica 节点发送 config rewrite 命令刷新配置文件

Configuration propagation(配置传播)。参考：官方文档

当所有从服务器都已经开始复制新的主服务器时，领头 Sentinel 终止这次故障迁移操作。

哨兵模式的优缺点

优点：

哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有
哨兵模式下，master 挂掉可以自动进行切换，系统可用性更高

缺点：

同样也继承了主从模式难以在线扩容的缺点，Redis 的容量受限于单机配置
需要额外的资源来启动 sentinel 进程，实现相对复杂一点，同时 slave 节点作为备份节点不提供服务

反馈

此页是否对你有帮助？

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

最后修改 March 29, 2024: load balancing, haproxy, hash, update, bypass (33eeace4)