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

作者: admin 分类: Redis 发布时间: 2020-03-14 10:40  阅读: 425 views

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进程)。优点如下:
1. 当多个哨兵就给定的主机不再可用这一事实达成共识时(投票法),将执行故障检测。这降低了误报的可能性。
2. 即使不是所有的sentinel进程都在工作,它仍能正常工作,从而使系统能够应对故障。

三、sentinel 的使用

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

运行

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

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

  1. redis-sentinel /path/to/sentinel.conf
  2. redis-server /path/to/sentinel.conf –sentinel

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

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

sentinel的部署相关说明

  1. 一个健壮的部署至少需要3个sentinel实例。
  2. 应该将三个sentinel实例放置到以独立方式发生故障的计算机或者虚拟机中。
  3. sentinel+redis分布式系统不保证在故障期间保留已确认的写入,因为redis使用异步复制。
  4. 流行的客户端库具有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 进行通讯:

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

八、redis故障转移的流程

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

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

九、Sentinel状态持久化

Sentinel 的状态会被持久化在 Sentinel 配置文件里面。

每当 Sentinel 接收到一个新的配置, 或者当领头 Sentinel 为主服务器创建一个新的配置时, 这个配置会与配置纪元一起被保存到磁盘里面。

这意味着停止和重启 Sentinel 进程都是安全的。

参考链接


   原创文章,转载请标明本文链接: redis sentinel的介绍,主要功能描述,如何启动运行,及多种部署方式等笔记整理

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

更多阅读