redis sentinel的介绍，主要功能描述，如何启动运行，及多种部署方式等笔记整理

本文链接：https://blog.csdn.net/chenhailonghp/article/details/104856202

本文深入解析Redis Sentinel机制，涵盖其在高可用性环境下的关键作用，包括监控、通知、自动故障转移及配置信息提供。Sentinel作为分布式系统，通过多个实例协同确保系统健壮性，实现故障检测与自动恢复。文章还探讨了Sentinel的运行、部署及配置细节，以及其与客户端、从服务器的交互方式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Redis Sentinel

sentinel为redis提供高可用性(master-slave模式下，如果是多节点模式用集群)。使用故障转移请至少部署3个哨兵。每个sentinel是个独立运行的进程。

redis sentinel

sentinel水平扩容时，数据迁移是个问题（要保证redis可用且写入不丢失），所以cluster是更好的选择。

当sentinel感知到master的变化会通知客户端更换节点，其实内部是用的一个发布订阅模式（客户端订阅sentinel的某一个频道，当master发生变化，sentinel向这个频道publish一条消息，客户端就可以获取再对新的master进行一个连接）

以下内容主要有

主要功能说明、使用
sentinel的运行说明
sentinel部署说明
sentinel认为的redis的下线状态
自动发现sentinel和从服务器
与sentinel通信
redis故障转移的流程
Sentinel状态持久化

一、主要功能

监控：sentinel会不断检查主实例和副本实例是否正常工作。
通知：当某个redis服务器出现问题时，sentinel可以通过API通知管理员或者其他程序。
自动故障转移：如果主服务器未按期工作，则sentinel可以启动故障转移过程（过程中将副本升级为主服务器，并将原主服务器的副本|从服务器重新配置复制新的主服务器。当客户端试图链接失效的主服务器时，集群也会向客户端返回新主服务器的地址。实现替换）
提供配置信息：Sentinel充当客户端服务器发现授权来源。客户端链接到sentinel，询问负责给定服务的redis主服务器的地址，如果发生故障转移，sentinel将报告新地址。

二、sentinel性质

Redis sentinel是一个分布式系统，本身设计为在有多个sentinel进程协同合作的配置中运行(一个架构中运行多个sentinel进程)。优点如下：

当多个哨兵就给定的主机不再可用这一事实达成共识时(投票法)，将执行故障检测。这降低了误报的可能性。
即使不是所有的sentinel进程都在工作，它仍能正常工作，从而使系统能够应对故障。

三、sentinel 的使用

sentinel的当前版本为 sentinel2。自redis2.8起已发布稳定版本的redis sentinel

运行

可以使用两种命令行运行sentinel，效果一样

目录/redis-4.0.6/src中执行以下命令

redis-sentinel /path/to/sentinel.conf
redis-server /path/to/sentinel.conf --sentinel

运行sentinel时必须使用配置文件，因为系统会在文件中保存当前状态，以便在重启时重新加载该状态。如果文件或路径无效、不可写。sentinel拒绝启动

sentinels默认情况下会监听tcp端口26379的连接，所以服务器的端口26379必须打开才能从其他sentinel实例的ip地址接收连接。否则sentinel无法执行故障转移

sentinel的部署相关说明

一个健壮的部署至少需要3个sentinel实例。
应该将三个sentinel实例放置到以独立方式发生故障的计算机或者虚拟机中。
sentinel+redis分布式系统不保证在故障期间保留已确认的写入，因为redis使用异步复制。
流行的客户端库具有sentinel支持，但并不是全部都支持。

配置sentinel

在路径目录/redis-4.0.6/sentinel.conf中可以配置相关sentinel信息

最小化配置如下，监控两组实例如下

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

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

sentinel monitor 使用说明

## 配置监听的主服务器，这里sentinel monitor代表监控，master-name代表服务器的名称，可以自定义，ip代表监控的主服务器，6379代表端口，quorum = 2（认定数量）代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor <master-name> <ip> <redis-port> <quorum>

## 但是要注意，无论设置多少个quorum，一个sentinel都要获得系统中多数sentinel的支持，才能发起自动故障转移.

例如 有5个sentinel进程，设置quorum=2则会发生以下的情况。

1. 如果两个sentinel达成一致，主机不可访问，则尝试启动故障或转移。
2. 如果总共至少三个sentinel可以访问，则故障转移将被授权并实际开始。

sentinel down-after-milliseconds 是指sentinel开始认为实例已经关闭无法连接所需要的时间。以毫秒为单位

sentinel parallel-syncs 指定了在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器同步，数字越小，完成故障转移的时间越长。

sentinel failover-timeout 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟

四、sentinel部署说明

这里搬迁官网的ASCII图形来进行说明

 说明

## 表示可以通话
+-------------+               +-------------+
| Sentinel S1 |---------------| Sentinel S2 |
+-------------+               +-------------+

## 表示无法连接
+-------------+                +-------------+
| Sentinel S1 |------ // ------| Sentinel S2 |
+-------------+                +-------------+

# 主服务称为  M1,M2,M3
# 副本/从称为 R1,R2,R3
# 哨兵称为    S1,S2,S3
# 客户端称为  C1,C2,C3
# 当实例由于Sentinel动作而更改角色时，我们将其放在方括号中，因此[M1]表示由于Sentinel干预而成为主实例的实例

1. 设置 2个sentinel

以下这个是失败的设置，因为sentinels始终需要与大多数人进行交谈才能启动故障转移。

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+

Configuration: quorum = 1

如果M1故障，R1升为主服务，因为按照设置可以授权并开始故障转移。但是..
如果M1故障，S1也可能失效。S2则无法与S1通信授权，系统将不可用。

2. 设置三个sentinel

一般设置

3
       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

Configuration: quorum = 2

如果M1故障，S2、S3达成协议，授权故障转移，使客户端可以正常工作。由于Redis采用异步复制，存在部分写入数据丢失。

可能存在风险, 数据丢失

3
         +----+
         | M1 |
         | S1 | <- C1 (writes will be lost)
         +----+
            |
            /
            /
+------+    |    +----+
| [M2] |----+----| R3 |
| S2   |         | S3 |
+------+         +----+


这种情况下，分区隔离了旧M1,R2被提升为主服务[M2]。但是一部分客户端依然会向M1写数据。这部分数据会永远丢失。因为恢复分区后，M1会成为[M2]的副本，丢弃自己的数据集。

利用redis的配置可以缓解这个问题。如果主服务器检测到不再能够将其写入转移到指定数量的副本，将停止接收C的写入。

## 无法写入至少一个副本
min-replicas-to-write 1

## 无法在指定时间内发送异步确认
min-replicas-max-lag 10

3. 在客户端设置sentinel

例如只有两个redis服务器，一个mater，一个slave。由于不能设置2个sentinel，所以可以将sentinel放到客户端的位置。

3
        +----+         +----+
        | M1 |----+----| R1 |
        |    |    |    |    |
        +----+    |    +----+
                  |
     +------------+------------+
     |            |            |
     |            |            |
  +----+        +----+      +----+
  | C1 |        | C2 |      | C3 |
  | S1 |        | S2 |      | S3 |
  +----+        +----+      +----+

  Configuration: quorum = 2
      
      
如果运行M1和S1的设备发生故障，则故障转移将顺利进行。

如果客户端和Redis服务器之间的网络已断开连接，则Sentinel将无法设置，因为Redis主服务器和副本服务器均不可用。

4.少于三个客户端的sentinel

如果客户端少于3个，则无法使用上述3的结构。可以使用以下结构

4

    +----+         +----+
    | M1 |----+----| R1 |
    | S1 |    |    | S2 |
    +----+    |    +----+
              |
       +------+-----+
       |            |
       |            |
    +----+        +----+
    | C1 |        | C2 |
    | S3 |        | S4 |
    +----+        +----+

Configuration: quorum = 3

如果主M1不可用，则其他三个Sentinel将执行故障转移。

更多sentinel的介绍说明阅读官方手册

五、sentinel认为的redis的下线状态

SDOWN: 主观下线状态

说明：一个sentinel认为master无法链接

条件：sentinel去pingmaster,如果在配置中作为is-master-down-after-milliseconds 参数指定的秒数内未收到对PING请求的有效回复，则达到SDOWN条件。

ODOWN：客观下线状态

说明：大多数sentinel认为master无法连接

条件：一个sentinel收到其他sentinel(至少是quorum的数量)的确认失效信息，就是ODOWN状态。

六、自动发现sentinel和从服务器

一个 Sentinel 可以与其他多个 Sentinel 进行连接，各个 Sentinel 之间可以互相检查对方的可用性，并进行信息交换。

你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址，因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ，这一功能是通过向频道 sentinel:hello 发送信息来实现的。

与此类似，你也不必手动列出主服务器属下的所有从服务器，因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。

每个 Sentinel 会以每两秒一次的频率，通过发布与订阅功能，向被它监视的所有主服务器和从服务器的 sentinel:hello 频道发送一条信息，信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）。
每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 sentinel:hello 频道，查找之前未出现过的 sentinel （looking for unknown sentinels）。当一个 Sentinel 发现一个新的 Sentinel 时，它会将新的 Sentinel 添加到一个列表中，这个列表保存了 Sentinel 已知的，监视同一个主服务器的所有其他 Sentinel 。
Sentinel 发送的信息中还包括完整的主服务器当前配置（configuration）。如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧，那么这个 Sentinel 会立即升级到新配置上。
在将一个新 Sentinel 添加到监视主服务器的列表上面之前， Sentinel 会先检查列表中是否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址（包括 IP 地址和端口号）的 Sentinel ，如果是的话， Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel ，然后再添加新 Sentinel 。

七、与sentinel通信

在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。

Sentinel 接受 Redis 协议格式的命令请求，所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。

有两种方式可以和 Sentinel 进行通讯：

第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态，以及 Sentinel 所知道的关于其他 Sentinel 的信息，诸如此类。
另一种方法是使用发布与订阅功能，通过接收 Sentinel 发送的通知：当执行故障转移操作，或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相应的信息。

八、redis故障转移的流程

一次故障转移操作由以下步骤组成：

发现主服务器已经进入客观下线状态。
对我们的当前纪元(新主服务器的配置版本号)进行自增（详情请参考 Raft leader election ），并尝试在这个纪元中当选。
如果当选失败，那么在设定的故障迁移超时时间的两倍之后，重新尝试当选。如果当选成功，那么执行以下步骤。
选出一个从服务器，并将它升级为主服务器。
向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。
通过发布与订阅功能，将更新后的配置传播给所有其他 Sentinel ，其他 Sentinel 对它们自己的配置进行更新。
向已下线主服务器的从服务器发送 SLAVEOF 命令，让它们去复制新的主服务器。
当所有从服务器都已经开始复制新的主服务器时，领头 Sentinel 终止这次故障迁移操作。