什么是Redis sentinel

上篇文章Redis高可用方案—主从（masterslave）架构中我们了解了Redis的主从复制模式的原理及其搭建方式，知道了它具有数据的多机备份和数据的读写分离的好处。但主从复制架构有一个缺陷，就是当master节点发生故障后，无法自动实现故障转移，需要人手动从slave节点中选择一个作为master节点继续提供服务。而本篇文章要介绍的Redis哨兵机制就解决了这一问题。

哨兵（sentinel）在Redis主从架构中是一个非常重要的组件，是在Redis2.8版本引入的。它的主要作用就是监控所有的Redis实例，并实现master节点的故障转移。哨兵是一个特殊的redis服务，它不负责数据的读写，只用来监控Redis实例。

Redis sentinel工作原理

在哨兵模式架构中，client端在首次访问Redis服务时，实际上访问的是哨兵（sentinel），sentinel会将自己监控的Redis实例的master节点信息返回给client端，client后续就会直接访问Redis的master节点，并不是每次都从哨兵处获取master节点的信息。

sentinel会实时监控所有的Redis实例是否可用，当监控到Redis的master节点发生故障后，会从剩余的slave节点中选举出一个作为新的master节点提供服务，并将新master节点的地址通知给client端，其他的slave节点会通过slaveof命令重新挂载到新的master节点下。当原来的master节点恢复后，也会作为slave节点挂在新的master节点下。如下图：

一般情况下，为了保证高可用，sentinel也会进行集群部署，防止单节点sentinel挂掉。当sentinel集群部署时，各sentinel除了监控redis实例外，还会彼此进行监控。如下图：

Redis sentinel是如何进行监控的

要实现Redis节点的监控，sentinel首先要得到所有的Redis节点的信息。sentinel通过在配置文件中配置 sentinel monitor 选项来指定要监控的redis master节点的地址，然后在启动sentinel时，会创建与redis master节点的连接并向master节点发送一个info命令，master节点在收到info命令后，会将自身节点的信息和自己下面所有的slave节点的信息返回给sentinel，sentinel收到反馈后，会与新的slave节点创建连接，接下来就会每隔10秒钟向所有的redis节点发送info命令来获取最新的redis主从结构信息。

有了redis实例的主从信息后，sentinel就会以每秒钟一次的频率向所有redis实例发送一个PING命令，而且如果sentinel是集群部署的话，每个sentinel还会以同样的频率向其他sentinel实例发送PING命令。当redis实例和sentinel实例收到PING命令后，会向sentinel返回一个有效的回复：+PONG 、-LOADING 或者 -MASTERDOWN，若返回其他的回复，或者在指定时间内（sentinel down-after-milliseconds 选项配置）没有回复，那么sentinel认为实例的回复无效。如果实例在 sentinel down-after-milliseconds 时间内未返回过一次有效的回复，那该实例就会被sentinel标记为主观下线（Subjectively Down，简称 SDOWN，指的是单个 sentinel 实例对服务节点做出的下线判断）。

当redis master节点被足够数量（sentinel monitor 选项配置，其中的quorum即为指定的sentinel数量，下面会详细介绍相关参数）的sentinel标记为主观下线后，那么master节点就会被标记为客观下线（Objectively Down，简称 ODOWN，指的是多个 sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断。【一个 sentinel 可以通过向另一个 sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线】）。客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例，sentinel 在将它们判断为下线前不需要进行协商， 所以slave服务器或者其他 sentinel 永远不会达到客观下线条件。

当redis master被标记为客观下线时，每个sentinel向其他slave节点发送info命令的频率由之前的10秒钟一次变为1秒钟一次。并且会通过raft算法在sentinel中选出一个leader，由leader节点完成redis的故障转移工作。

Redis sentinel选举redis-master的规则

如何从众多slave节点中选出一个作为master节点呢？redis官方文档中是这样描述sentinel选择新master的规则的：

Redis sentinel配置

在redis安装目录下，除了有redis本身的一个配置文件外，还有一个sentinel.conf，该文件就是sentinel的配置文件。在该文件中，主要有以下几个配置：

● port：sentinel的端口，默认为26379；

● daemonize：是否后台启动，yes表示以后台方式启动运行sentinel，默认为no；

● logfile：sentinel日志文件存放路径；

● sentinel monitor ：sentinel监控的master节点的名称、地址和端口号，最后一个quorums表示至少需要多少个sentinel判定master节点故障才进行故障转移。一般配置为sentinel数量/2+1。

● sentinel down-after-milliseconds ：sentinel向其他实例发送PING命令后到获得响应的超时时间，单位为毫秒；

● sentinel failover-timeout ：sentinel在对master进行故障转移时的超时时间，单位毫秒；

● sentinel parallel-syncs ：在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步，这个数字越小，完成故障转移所需的时间就越长；

● sentinel auth-pass ：如果master节点设置了密码，则需要在这里配置master节点的密码，否则sentinel无法连接master进行监控。

Redis sentinel启动

基于上篇文章Redis高可用方案—主从（masterslave）架构中我们搭建好的redis主从架构，要启动sentinel很简单，只需要在我们的三台服务器上分别执行命令：./bin/redis-sentinel sentinel.conf。如下图：

以上就是Redis Sentinel的主要工作内容和相关原理的介绍。

点关注不迷路，跟我一起学技术！