Redis--哨兵实现原理

偏执的太偏执、 2021-08-28 18:05 289阅读 0赞

### 哨兵实现原理 ###

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

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主从系统，从而形成网状结构。

哨兵启动后，会与要监控的主数据库建立两条连接，这两个连接的建立方式与普通的Redis客户端无异。

*  其中一条连接用来订阅该主数据的`_sentinel_:hello`频道以获取其他同样监控该数据的哨兵节点信息；
 *  另外哨兵也需要定期向主数据裤发送INFO等命令来获取主数据库本身的信息（因为客户端的连接进入订阅模式时就不能再执行其他操作，所以使用另外一条连接）：  
    和主数据裤的连接建立完成后，哨兵会定时执行下面3个操作：
    
    1.  每10秒哨兵会向主数据库和从数据库发送INFO命令
    2.  每2秒哨兵会向主数据库和从数据库的`_sentinel_:hello`频道发送自己的信息
    3.  每1秒哨兵会想主数据库、从数据库和其他哨兵节点发送PING命令

这3个操作贯穿哨兵进行的整个生命周期中。

首先，发送INFO命令使得哨兵可以获得当前数据库的相关信息（`包括运行ID、复制信息等`）从而实现新节点的自动发现。哨兵正是借助INFO命令来获取所有复制该主数据库的从数据库信息的。

启动后，哨兵向主数据库发送INFO命令，通过解析返回结果来得知从数据库列表，`而后对每个从数据库同样建立两个连接，与主数据库一致`。此后，哨兵会每10秒定时向已知的所有主从数据库发送INFO命令来获取信息更新并进行响应操作，比如：

*  对新增的从数据库建立连接并假如监控列表
 *  对主从数据库的角色变化（由故障恢复操作引起）进行信息更新等

接下来哨兵向主从数据库的`_sentinel_:hello`频道发送信息来与同样监控该数据库的哨兵分享自己的信息。

发送的消息内容为：

*  哨兵的地址
 *  哨兵的端口
 *  哨兵的运行ID
 *  哨兵的配置版本
 *  主数据库名字
 *  主数据库的地址
 *  主数据库端口
 *  主数据库的配置版本

消息包括哨兵的基本信息，以及其监控的主数据库的信息。当其它哨兵收到消息后，会判断发消息的哨兵是不是新发现的哨兵。

*  如果是，则将其加入已发现的哨兵列表中并创建一个到其的连接（与数据库不同，哨兵之间只会创建一条连接用来发送PING命令，而不需要另外一条连接来订阅频道，因为哨兵只需要订阅数据库的频道即可实现自动发现其它哨兵）。
 *  如果不是，哨兵会判断信息中主数据库的配置版本，如果该版本比当前记录的主数据库版本高，则更新主数据的数据。

实现了自动发现从数据库和其它哨兵节点后，哨兵要做的就是定时监控这些数据库和节点有没有停止服务。这是通过每隔一定时间向这些节点发送PING命令实现的。

时间间隔与`down-after-milliseconds`选项有关：

*  值小于1秒：哨兵每隔`down-after-milliseconds`指定的时间发送一次PING命令
 *  值大于1秒：忽略，每隔1秒发送一次PING命令

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

当超过 down-after-milliseconds 指定的时间后，如果被PING的数据库或节点仍然未进行回复，则哨兵认为其`主观下线（subjectively down）`。

主观下线表示：从当前的哨兵进程来看，该节点已经下限。如果该节点是主数据库，则哨兵会进一步判断是否需要对其进行故障恢复：哨兵发送`SENTINEL is-master-down-by-addr`命令询问其它哨兵节点以了解他们是否也认为该主数据库主观下线，并选举零头的哨兵节点对主从系统发起故障恢复。这个指定数量即为前面的`quorum`参数。

sentinel monitor mymaster 127.0.0.1 6379 2

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

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

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

选出领头哨兵后，领头哨兵将会开始对主数据库进行故障恢复：

*  首先领头哨兵将从停止服务的主数据库的从数据库中挑选一个来充当新的主数据库，挑选的依据如下：
    
    1.  所有在线的从数据库中，选择优先级最高的从数据库。优先级可以通过`slave-priority`来设置。
    2.  如果有多个最高优先级的从数据库，则复制的命令偏移量越大（即复制越完整）越优先。
    3.  如果上述条件都一样，则选择运行ID较小的从数据库。
 *  选出一个从数据库后，领头哨兵将向从数据库发送`SLAVEOF NO ONE`命令使其升格为主数据库。而后领头哨兵向其它其它从数据库发送`SLAVEOF`命令来使其称为新主数据库的从数据库。
 *  最后一步则更新内部的记录，将已经停止服务的旧的主数据库更新为新的主数据库的从数据库，使得当其恢复服务时自动以从数据库的身份继续服务。

#### 哨兵的部署 ####

哨兵以独立进程的方式对一个主从系统进行监控，监控的效果好坏取决于哨兵的视角是否有代表性。如果一个主从系统中配置的哨兵较少，哨兵对整个系统的判断的可靠性就会降低。极端情况下，当只有一个哨兵时，哨兵本身就可能发生单点故障。整体来讲，相对稳定的哨兵部署方案是使得哨兵的视角尽可能地与每隔节点的视角一致，即：

1.  为每隔节点（无论时主数据库还是从数据库）部署一个哨兵；
2.  使每隔哨兵与其对应的节点的网络环境相同或相近；

这样的部署方案可以保证哨兵的视角拥有较高的代表性和可靠性。举一个例子：当网络分区后，如果哨兵认为某个分区是主要分区，即意味着从每隔节点观察，该分区均为主分区。

同时设置quorum的值为 `N / 2 + 1`，这样使得只有当大部分哨兵节点同意后才会进行故障恢复。

当系统中的节点较多时，考虑到每个哨兵都会和所有的节点建立连接，为每个节点分配一个哨兵会产生较多连接，尤其是当客户端分片时使用多个哨兵节点监控多个主数据库会因为Redis不支持连接复用而产生大量冗余连接；同时如果redis节点负载较高，会在一定程度上，影响其对哨兵的回复以及与其同机哨兵与其它节点的通信。所以配置哨兵还需要根据实际的生产环境情况进行选择。