linux哨兵命令哨兵的命令

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

Sentinel（哨兵）

Redis主从复制模式下，一旦主节点（主服务器）由于故障不能提供服务，需要人工将节点晋升为主节点，同时还要通知应用方更新主节点的地址，然而应用方无法及时感知到主节点的变化，必然会造成一定的写数据丢失和读数据错误，所以这是在大多数情况是无法接受的。所以Redis提供了一种高可用的解决方法——哨兵。

Sentinel是Redis的高可用解决方案：由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态下时，自动将下线主服务器属下的某个从服务器升级为主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。如果下线的主服务器重新连接上线的话，它会被Sentinel系统降级为新主服务器的从服务器。而这些过程完全是自动的，不需要人工介。

下面介绍Sentinel系统的具体工作过程。

Sentinel只是一个运行在特殊模式下的Redis服务器，其本身就是独立的Redis节点，只不过它不存储数据，只支持部分命令。

Sentinel会读入用户指定的配置文件，为每个要被监视的主服务器创建相应的实例结构保存在Sentinel状态（服务器初始化的一个sentinel结构，用于保存服务器中所有和Sentinel功能有关的状态）的masters属性中。并创建连向主服务器的网络连接，Sentinel将成为主服务器的客户端，并从命令回复中获取相关信息。

对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向主服务器的异步网络连接：

1) 一个是命令连接，这个连接专门用于向主服务器的网络连接，并接受命令。

2) 另一个是订阅连接，这个连接专门用于订阅主服务器的_sentinel_:hello频道。

Sentinel默认每10秒一次的频率，通过命令连接向被监视的主服务器发送 INFO 命令，并通过 INFO 命令的回复来获取主服务器以下的信息：

(1) 服务器本身的信息，包括运行ID以及服务器的角色（role）；

(2) 主服务属下的所有从服务器信息，包括从服务器的IP地址，端口号。根据这些IP和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。

Sentinel根据这些获取的信息对主服务的实例结构进行更新。

对于上图，Sentinel将分别为3个从服务器创建各自的实例结构，并将这些实例结构保存主服务器实例结构的slaves属性里。

当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构外，Sentinel还会为创建连接到从服务器的命令连接和订阅连接。

在创建命令连接之后， Sentinel在默认情况下，会以每10秒一次的频率通过命令连接向从服务器发送 INFO 命令，并获取从服务器的回复信息，包括从服务器运行ID、从服务器的角色，主服务器的IP和端口、从服务的优先级等。根据这些信息对从服务器实例结构进行更新。

在默认情况下，Sentinel会以每2秒一次的频率，通过命令连接向所有被监听的主服务器和从服务器的_sentinel_ hello频道发送一条消息。消息的信息包括Sentinel本身的信息和对主服务器判断的信息。

当Sentinel与一个主服务器或者从服务器建立起订阅连接之后， Sentinel就会通过订阅连接，向服务器发送以下命令：SUBSCRIBE _sentinel_:hello 。

Sentinel对_sentinel_:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。

这也就是说，对于每个与Sentinel连接的服务器， Sentinel既通过命令连接向服务器的 sentinel_:hello频道发送信息，又通过订阅连接从服务器的 sentinel :hello 频道接收信息。

对于监视同一个服务器的多个Sentinel 来说，一个Sentinel发送的信息会被其他 Sentinel接收到，这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知，也会被用于更新其他Sentinel对被监视服务器的认知。

举个例子，假设现在有sentinel1、sentinel 2、sentinel 3三个Sentinel在监视同一个服务器，那么当sentinel1向服务器的_sentinel_:hello频道发送一条信息时，所有订阅了_sentinel_:hello频道的Sentinel（包括sentinel1自己在内）都会收到这条信息。

当一个Sentinel从_sentinel_:hello频道收到一条信息时，Sentinel会对这条信息进行分析，提取出信息中的Sentinel IP地址、端口号、Sentinel运行ID等参数，并作以下检查：

**如果信息中记录的Sentinel运行ID和接收信息中Sentinel的运行ID 相同，说明这条信息是Sentinel自己发送的，Sentinel将丢弃这条信息，不做进一步处理。

**如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID不相同，那么说明这条信息是监视同一个服务器的其他Sentinel发来的，接收信息的Sentinel 将根据信息中的各个参数，对相应主服务器的实例结构进行更新。

这里的更新包括：主服务sentinels属性的更新和创建连向其他Sentinel命令连接

(1) Sentinel为主服务器创建的实例结构中的sentinels属性保存了除Sentinel本身之外，所有同样监视这个主服务器的其他Sentinel的资料。当一个Sentinel接收到其他Sentinel发来的信息时（我们称呼发送信息的Sentinel为源Sentinel, 接收信息的Sentinel为目标Sentinel），根据信息中提取出主服务器参数，目标Sentinel会在自己的Sentinel状态的masters字典中查找相应的主服务器实例结构，然后根据提取出的Sentinel参数，检查主服务器实例结构的sentinels中，源Sentinel的实例结构是否存在：

因为一个Sentinel可以通过分析接收到的频道信息来获取其他Sentinel的存在，并通过发送频道信息让其他Sentinel知道自己的存在，所以用户在使用Sentinel时不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentinel可以自动发现对方。

(2) 创建连向其他Sentinel命令连接

当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新Sentinel在sentinels中创建相应的实例结构，还会创建一个连向新Sentinel的命令连接，而新Sentinel也同样会创建连向这个Sentinel的命令连接，最终监视同一主服务器的多个Sentinel将形成相互连接的网络。

在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令的连接实例（包括主服务器、从服务器、其他Sentinel在内），发送PING命令，并通过实例返回PING命令的回复判断实例是否在线，如果在规定的时间内，连续向Sentinel返回无效的回复（除了+PONG、-LOADING、-MASTERDOWN之外的回复），那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来标识这个实例已经进入了主观下线状态。

当Sentinel将一个主服务器判断为主观下线之后，为了确认这个主服务器是否真的下线了，它会向同样监视这一主服务器的其他Sentinel进行询问，看它们是否也认为主服务器已经进人了下线状态（可以是主观下线或者客观下线）。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后， Sentinel就会将从服务器判定为客观下线， Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开，标识主服务器已经进入了客观下线状态。

当一个主服务器被判断为客观下线时，监视这个下线的主服务器的各个Sentinel会进行协商，选举出以个领头Sentinel，并由领头Sentinel对下线主服务器执行故障转移操作。

选举领头Sentinel规则和方法：

下面两幅图表示当三个Sentinel发现主服务器已经进入客观下线状态后，为了选举出领头Sentinel，三个Sentinel将再次向其他Sentinel发送SENTINEL is-master-down-by-addr命令要求其他Sentinel将自己设置为局部领头Sentinel。根据先到先得规则，如果某个Sentinel发送的命令比其他的快，并最终胜出领头Sentinel的选举，然后这个领头Sentinel就可以开始对服务器执行故障转移操作了。

在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤：

(1) 选出新的主服务器

故障转移的第一步就是在已下线主服务器属下的所有从服务器中挑选出一个状态良好、数据完成整的从服务器，然后向这个从服务器发送slave no one 命令，将这个从服务器装换为主服务器。

下图展示在一次故障转移操作中，领头Sentinel向选中的从服务器server3发送 SLAVEOF no one 命令。

在发送 SLAVEOF no one命令之后，领头 Sentinel会以每秒一次的频率（平时是每10秒一次），向被升级的从服服务发送INFO命令，并观察命令回复中角色（role）信息，当被升级的从服务器的role由原来的slave变为master时，领头Sentinel就知道被选中的从服务器顺利升级为主服务器了。

(2) 修改从服务器的复制目标

当新的主服务器出现之后，领头Sentinel让已下线主服务器属下的所有从服务器去复制新的主服务器，这一动作可以通过向从服务器发送 SLAVE OF 命令来实现。

(3) 将旧的主服务器变为从服务器

故障转移操作最后要做的是，将巳下线的主服务器设置为新的主服务器的从服务器。

当serverl1重新上线时，Sentinel就会向它发送 SLAVEOF 命令，让它成为server3的从服务器。

Redis的Sentinel实现主要包含以下几个方面：三个定时任务、主观下线和客观下线检测、领头Sentinel的选举、故障转移。

(1) 定时任务

(2) 主观下线和客观下线检测

客观下线：当Sentinel将一个主服务器判断为主观下线后，为了确认这个主服务是否真的下线了，他会向同样监视这个主服务器的所有其他Sentinel进行询问，看它们是否也认为主服务器是否进入下线状态，如果有足够多数量的Sentinel认为主服务器进入下线状态时，Sentinel就会将主服务器判定为客观下线状态。

(3) 领头Sentinel的选举

在主服务器被判定为客观下线后，Sentinel之间会根据一定的规则选出一个领头Sentinel，故障转移的工作就是这个领头Sentinel来完成的。

(4) 故障转移

注：本文参考《Redis设计与实现》，如发现错误，请指正！