Redis哨兵sentinel机制的简单配置及说明

       在上面一篇文章中简单介绍了Redis的主从复制，因为有了主从复制的机制Redis就可以保证高可用，不用担心因为单机故障的原因导致整个环境的性能压力，但是如果master主节点挂掉了怎么办呢？白天还好，如果是半夜两三点我们还必须从暖和的被窝赶到公司重启服务，特别是冬天的时候别提有多酸爽了，当然你可以说我们可以让master节点自动重启啊，当然也可以，但是这里有另外一个问题啊，master节点自动重启的时候会清空掉所有的缓存信息，从节点进行复制的时候也会被清空掉所有的缓存信息，如果缓存有几十上百万的信息，甚至更多的话，信息一旦被清空这个可不是我们愿意看到的情况，那么我们有没有什么别的方法来当当前master节点挂掉后自动重新生成一个新的master节点来替换原来的master节点呢？这里Redis为我们提供了哨兵的机制，该机制为我们提供了监控、通知、故障转移、配置提供的功能：

       1)监控：主要用于监控主节点和从节点的状态是否正常。

       2)通知：Redis集群中实例有错误发生时通过API通知相关用户。

       3)故障转移：Redis集群主节点发生故障时选举新的从节点为主节点。

       4)配置提供：产生故障转移是获取新的主节点信息给客户端使用。

        我们接着看下sentinel机制是怎么进行运行的，当前Redis版本为5.0.5：

       1.首先我们必须启动一个Redis主从集群，建议是3个redis及以上，同时是奇数个。

       2.在集群中配置哨兵的配置文件sentinel.conf的相关内容，哨兵的个数建议是3个及以上，同时是奇数个。

       3.通过./src/redis-server sentinel.conf --sentinel分别启动集群中的哨兵。

       4.哨兵监控Redis主从集群，当一个哨兵发现主节点不能发生正常使用，它就会通过sentinel is-master-down-by-addr命令询问其他哨兵也去检查是不是主节点真的不能使用了。

       5.有几个哨兵都发现主节点不能正常使用了，那么哨兵就会通过一定的方式选举出一个哨兵来进行故障转移，也即主从切换。

       6.当新的主节点选举出来后，其他的从节点都会重新注册到新的主节点上面。

       通过上面的流程我们就大致完成了哨兵进制的监控过程，接着看下sentinel.conf的主要配置

# 配置文件：sentinel.conf，在sentinel运行期间是会被动态修改的
# sentinel如果重启时，根据这个配置来恢复其之前所监控的redis集群的状态
# 绑定IP
bind 0.0.0.0
# 后台运行
daemonize yes
# 默认yes，没指定密码或者指定IP的情况下，外网无法访问
protected-mode no
# 哨兵的端口，客户端通过这个端口来发现redis
port 26380
# 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信
# sentinel announce-ip
# 临时文件夹
dir /tmp
# 日志
logfile "/usr/local/redis/logs/sentinel-26380.log"
# sentinel监控的master的名字叫做mymaster,初始地址为 172.168.1.3 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡
sentinel monitor mymaster 172.168.1.3 6380 2
# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 1000
# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel failover-timeout mymaster 180000
# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 1

       针对上面的port端口号的配置一般情况下是主从集群对应的port+20000，因此有时候哨兵的端口号也称为2万，在运行过程中该配置文件是动态变化的，它会记录其他哨兵和主从节点的信息，如下所示

#主从节点ip+端口号
sentinel known-replica mymaster 172.168.1.5 6389
sentinel known-replica mymaster 172.168.1.6 6389
#哨兵节点ip+port+runid
sentinel known-sentinel mymaster 172.168.1.5 26389 58124729013ae8489475947f2d891867cb42fd7b
sentinel known-sentinel mymaster 172.168.1.6 26389 bfc005d1bab8c9a055361cd972637207a6870617

     通过上面的存储信息我们就可以了解到它保存了其他主从节点和哨兵节点的信息，它可以通过master节点的info replication方式获取到其他从节点信息，当然这里会动态修改sentinel monitor mymaster 172.168.1.3 6380 2的监控ip，这个ip就是master节点的地址。

        当哨兵发现主节点不可用的时候它是如何进行确认主节点的不可用以及哨兵集群在选举主节点的时候又是怎么判断的呢？

        当一个哨兵节点自己发现主节点不可用时这个时候又称为主观下线(SDOWN：Subjectively Down)，这个时候该哨兵节点就会去通知其他哨兵节点让其也检查看是否主节点真的不可用了，这个时候一旦发现主节点不可用的哨兵节点总数达到

sentinel monitor <master-group-name> <ip> <port> <quorum>

中的quorum数量，那么就真的认为主节点已经不可用了，SDOWN就会提升为ODOWN(Objectively Down)即客观下线，这个时候就可以开始故障转移，主从切换了。那么哨兵节点通过一定的机制选取出一个哨兵节点进行故障转移，我们在选取从节点为主节点的时候从以下几个方面进行依次考量，如果不满足的话才进行下一个方面的比较：

        1.从节点与主节点失去联系的时长，它的计算方式为

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

down-after-milliseconds 是我们在sentinel.conf配置的主节点不回复信息的时间间隔， milliseconds_since_master_is_in_SDOWN_state是当前哨兵开始出现主节点不可用的时长，一旦超过这个计算结果值，那么这个从节点就不再参与竞选主节点。

        2.在从节点的redis.conf文件中配置的replica-priority值的大小，值越小优先级越高，但是当配置为0的时候，它表示为该从节点不参与主节点的竞选，因此需要注意。

       3.从节点与主节点同步的信息偏移量offset，offset越大，优先级越高。

       4.如果上面的比较都没有成功，则最后比较runid，该runid可以通过在sentinel客户端通过命令sentinel slaves mymaster来查找到，值越小，优先级越高。

        在进行选举新的master节点的时候是必须先选一个sentinel节点出来进行master节点的选举的，那么sentinel节点之间又是如何进行通信及选举的呢？我们可以通过主节点的一个客户端使用命令行输入monitor命令，可以看到会有如下的pub/sub消息

1572419882.592609 [0 172.168.1.3:42926] "PUBLISH" "__sentinel__:hello" "172.168.1.6,26389,58124729013ae8489475947f2d891867cb42fd7b,4,mymaster,172.168.1.3,6389,4"
1572419882.592876 [0 172.168.1.3:6389] "PUBLISH" "__sentinel__:hello" "172.168.1.6,26389,58124729013ae8489475947f2d891867cb42fd7b,4,mymaster,172.168.1.3,6389,4"
1572419882.597405 [0 172.168.1.5:41131] "PING"
1572419882.711160 [0 172.168.1.5:36628] "PUBLISH" "__sentinel__:hello" "172.168.1.3,26389,866012a853481fdc6dcc6b947a0891ef99e9e37a,4,mymaster,172.168.1.3,6389,4"
1572419882.711376 [0 172.168.1.3:6389] "PUBLISH" "__sentinel__:hello" "172.168.1.3,26389,866012a853481fdc6dcc6b947a0891ef99e9e37a,4,mymaster,172.168.1.3,6389,4"
1572419882.875542 [0 172.168.1.6:42926] "PING"
1572419883.360563 [0 172.168.1.5:41131] "PUBLISH" "__sentinel__:hello" "172.168.1.5,26389,bfc005d1bab8c9a055361cd972637207a6870617,4,mymaster,172.168.1.3,6389,4"
1572419883.360745 [0 172.168.1.3:6389] "PUBLISH" "__sentinel__:hello" "172.168.1.5,26389,bfc005d1bab8c9a055361cd972637207a6870617,4,mymaster,172.168.1.3,6389,4"

       这个pub/sub就是sentinel订阅的消息，通过这个订阅消息我们可以让哨兵发现其他哨兵，也可以通过它进行哨兵间的通信操作，当一个哨兵发现其他哨兵时，也可以通过直连的方式进行哨兵间通信。我们在看看是如何选举sentinel来进行master节点的选取的，sentinel的选举是基于raft算法来进行的，它大概的步骤如下：

       1.拉票阶段：每个sentinel节点都希望成为领导者，它们都各自向其他的sentinel节点发送表示想要成为领导者的需求。

        2.sentinel节点收到拉票命令后，如果他没有收到或者同意过其他的sentinel节点的拉票请求，那么就为发送拉票的sentinel节点投上一票，即同意这个sentinel节点成为领导者，每个sentinel节点只有一票，。

        3.如果sentinel节点发现自己的票数已经超过大多数的票数(n/2+1)，那么它就成为领导者，然后去执行故障转移。

        4.投票结束后，如果超过在sentinel.conf文件中配置的failover-time时间，还没有进行故障转移操作，那么就重新进行拉票选举。

        我们还需要注意的是当主节点挂掉重启或者被孤立时，sentinel在选举出新的master节点前，原来的程序还在不停的往这个old主节点发送数据，这个时候就会导致数据的不一致，我们可以通过在redis.conf文件中配置以下的命令来避免这种数据的不一致

min-slaves-to-write 1
min-slaves-max-lag 10

        min-slaves-to-write表示必须写到最小1个从节点主节点才能正常接收数据，min-slaves-max-lag表示最小的从节点延迟消息的返回时间，单位是秒，当然这个命令必须配置在主节点的redis.conf文件中才有效。

      redis的sentinel哨兵机制的介绍文档https://redis.io/topics/sentinel