redis(21):集群之哨兵

偏执的太偏执、 2022-10-30 09:24 193阅读 0赞

> 在一个典型的一主多从的Redis系统中，从数据库在整个系统中起到了数据冗余备份和读写分离的作用。当主数据库遇到异常中断服务 后，开发者可以通过手动的方式选择一个从数据库来升格为主数据库，以使得系统能够继续 提供服务。然而整个过程相对麻烦且需要人工介入，难以实现自动化。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。 注意 Redis 2.6 版也提供了哨兵工具，但此时的哨兵是1.0版，存在非常多的问题，在任 何情况下都不应该使用这个版本的哨兵。所以本文中介绍的哨兵都是Redis 2.8提供的哨兵 2，后文不再赘述。

--------------------

### 1、什么是哨兵 ###

顾名思义，哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

1.  监控主数据库和从数据库是否正常运行。
2.  主数据库出现故障时自动将从数据库转换为主数据库。 哨兵是一个独立的进程，使用哨兵的一个典型架构如图所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]  
虚线表示主从复制关系，实线表示哨兵的监控 路径

在一个一主多从的Redis系统中，可以使用多个哨兵进行监控任务以保证系统足够稳健， 如图所示。注意，此时`不仅哨兵会同时监控主数据库和从数据库，哨兵之间也会互相监 控`。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]

--------------------

### 2、实现原理 ###

一个哨兵进程启动时会读取配置文件的内容，通过如下的配置找出需要监控的主数据 库：

sentinel monitor master-name ip redis-port quorum

*  其中 master-name 是一个由大小写字母、数字和“.-\_”组成的主数据库的名字，因为考虑 到故障恢复后当前监控的系统的主数据库的地址和端口会产生变化，所以哨兵提供了命令可 以通过主数据库的名字获取当前系统的主数据库的地址和端口号。
 *  ip表示当前系统中主数据库的地址，而redis-port则表示端口号。
 *  quorum用来表示执行故障恢复操作前至少需要几个哨兵节点同意，后文会详细介绍。

> 一个哨兵节点可以同时监控多个Redis主从系统，只需要提供多个sentinel monitor配置即 可，例如：

sentinel monitor mymaster 127.0.0.1 6379 2 
    sentinel monitor othermaster 192.168.1.3 6380 4

> 同时多个哨兵节点也可以同时监控同一个 Redis 主从系统，从而形成网状结构。具体实 践时如何协调哨兵与主从系统的数量关系会在8.2.4节介绍。  
> 配置文件中还可以定义其他监控相关的参数，每个配置选项都包含主数据库的名字使得 监控不同主数据库时可以使用不同的配置参数。例如：

sentinel down-after-milliseconds mymaster 60000 
     sentinel down-after-milliseconds othermaster 10000

上面的两行配置分别配置了mymaster和othermaster的down-after-milliseconds选项分别 为60000和10000。

--------------------

> 哨兵启动后，会与要监控的主数据库建立`两条连接`，这两个连接的建立方式与普通的 Redis客户端无异。其中一条连接用来订阅该主数据的\_\_sentinel\_\_:hello频道以获取其他同样 监控该数据库的哨兵节点的信息，另外哨兵也需要定期向主数据库发送 INFO 等命令来获取  
> 主数据库本身的信息，因为前面介绍过当客户端的连接进入订阅模式时就不能再执行其他 命令了，所以这时哨兵会使用另外一条连接来发送这些命令。

和主数据库的连接建立完成后，哨兵会定时执行下面3个操作。

1.  每10秒哨兵会向主数据库和从数据库发送INFO命令。
2.  每 2 秒哨兵会向主数据库和从数据库的\_\_sentinel\_\_:hello 频道发送自己的信息。
3.  每1秒哨兵会向主数据库、从数据库和其他哨兵节点发送PING命令。

这3个操作贯穿哨兵进程的整个生命周期中，非常重要，可以说了解了这3个操作的意义 就能够了解哨兵工作原理的一半内容了。下面分别详细介绍。  
首先，发送INFO命令使得哨兵可以获得当前数据库的相关信息（包括运行ID、复制信 息等）从而实现新节点的自动发现。前面说配置哨兵监控 Redis 主从系统时只需要指定主数 据库的信息即可，因为哨兵正是借助 INFO 命令来获取所有复制该主数据库的从数据库信息 的。启动后，哨兵向主数据库发送 INFO 命令，通过解析返回结果来得知从数据库列表，而 后对每个从数据库同样建立两个连接，两个连接的作用和前文介绍的与主数据库建立的两个 连接完全一致。在此之后，哨兵会每 10 秒定时向已知的所有主从数据库发送INFO命令来获 取信息更新并进行相应操作，比如对新增的从数据库建立连接并加入监控列表，对主从数据 库的角色变化（由故障恢复操作引起）进行信息更新等。

接下来哨兵向主从数据库的\_\_sentinel\_\_:hello 频道发送信息来与同样监控该数据库的哨 兵分享自己的信息。发送的消息内容为：`<哨兵的地址>, <哨兵的端口>, <哨兵的运行 ID>, <哨兵的配臵版本>, <主数据库的名字 >, <主数据库的地址>, <主数据库的端口>, <主数据库的配臵版本>`

可以看到消息包括的哨兵的基本信息，以及其监控的主数据库的信息。前文介绍过，哨 兵会订阅每个其监控的数据库的\_\_sentinel\_\_:hello频道，所以当其他哨兵收到消息后，会判断 发消息的哨兵是不是新发现的哨兵。如果是则将其加入已发现的哨兵列表中并创建一个到其 的连接（与数据库不同，哨兵与哨兵之间只会创建一条连接用来发送 PING命令，而不需要 创建另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实现自动发现其他哨 兵）。同时哨兵会判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库的版 本高，则更新主数据库的数据。配置版本的作用会在后面详细介绍。

实现了自动发现从数据库和其他哨兵节点后，哨兵要做的就是定时监控这些数据库和节 点有没有停止服务。这是通过每隔一定时间向这些节点发送PING命令实现的。时间间隔与 down-after-milliseconds选项有关，当down-after-milliseconds的值小于1秒时，哨兵会每隔 down-after-milliseconds指定的时间发送一次PING命令，当down-after-milliseconds的值大于1 秒时，哨兵会每隔1秒发送一次PING命令。例如：

//每隔 1 秒发送一次 PING命令 
    sentinel down-after-milliseconds mymaster 60000 
    //每隔 600 毫秒发送一次 PING命令 
    sentinel down-after-milliseconds othermaster 600

当超过down-after-milliseconds选项指定时间后，如果被PING的数据库或节点仍然未进 行回复，则哨兵认为其主观下线（subjectively down）。主观下线表示从当前的哨兵进程看 来，该节点已经下线。如果该节点是主数据库，则哨兵会进一步判断是否需要对其进行故障 恢复：哨兵发送 SENTINEL is-master-down-by-addr命令询问其他哨兵节点以了解他们是否 也认为该主数据库主观下线，如果达到指定数量时，哨兵会认为其客观下线（objectively down），并选举领头的哨兵节点对主从系统发起故障恢复。这个指定数量即为前文介绍的 quorum参数。例如，下面的配置：

sentinel monitor mymaster 127.0.0.1 6379 2

> 该配置表示只有当至少两个 Sentinel 节点（包括当前节点）认为该主数据库主观下线 时，当前哨兵节点才会认为该主数据库客观下线。进行接下来的选举领头哨兵步骤。

虽然当前哨兵节点发现了主数据库客观下线，需要故障恢复，但是故障恢复需要由`领头的哨兵`来完成，这样可以保证同一时间只有一个哨兵节点来执行故障恢复。选举`领头哨兵`的过程使用了`Raft算法`，具体过程如下。

1.  发现主数据库客观下线的哨兵节点（下面称作A）向每个哨兵节点发送命令，要求对方选自己成为领头哨兵。
2.  如果目标哨兵节点没有选过其他人，则会同意将A设置成领头哨兵。
3.  如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨 兵，则A成功成为领头哨兵。
4.  当有多个哨兵节点同时参选领头哨兵，则会出现没有任何节点当选的可能。此时 每个参选节点将等待一个随机时间重新发起参选请求，进行下一轮选举，直到选举成功。

> 具体过程可以参考Raft算法的过程http://raftconsensus.github.io/。因为要成为领头哨兵必 须有超过半数的哨兵节点支持，所以每次选举最多只会选出一个领头哨兵。

选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复。故障恢复的过程相对简单，具体如下。  
首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库。挑选的依据如下。

1.  所有在线的从数据库中，选择优先级最高的从数据库。优先级可以通过slave- priority选项来设置。
2.  如果有多个最高优先级的从数据库，则复制的命令偏移量越大（即 复制越完整）越优先。
3.  如果以上条件都一样，则选择运行ID较小的从数据库。

选出一个从数据库后，

1.  领头哨兵将向从数据库发送 `SLAVEOF NO ONE`命令使其升格为 主数据库。
2.  后领头哨兵向其他从数据库发送SLAVEOF命令来使其成为新主数据库的从数据库。
3.  最后一步则是更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70]: /images/20221024/bce822171f434dfc81b053c65aa5eb02.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1dBTlRBV0FZMzE0_size_16_color_FFFFFF_t_70 1]: /images/20221024/1c445e13acfa4d8ab1c8163f56e8c686.png