Redis哨兵详细理论实操教程

背景

  书接上回主从复制，如果master主节点宕机以后，其他的从节点不会自动被推举为主节点，所以这时就用到了我们本篇文章要讲述的内容，Redis哨兵。吹哨人巡查监控后台master主机是否故障，如果故障了根据$投票数$自动将某一个从节点转换为新主节点，继续对外服务，其作用：俗称无人值守运维。

1. 哨兵的作用

  1、监控redis运行状态，包括master和slave；
  2.当master down机，能自动将slave切换成新的master；
  主从监控：监控主从redis库运行是否正常；
  消息通知：哨兵可以将故障转移的结果发送给客户端；
  故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master；
  配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址；

2.如何使用

2.1 配置参数说明

  Redis Sentinel架构，前提说明；
  3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人；
  1主2从：用于数据读取；
  其中Redis sentinel（Redis 哨兵集群）整体架构 是这样的。如图所示：

2.2 操作步骤

  1./myredis目录下新建或者拷贝sentinel.conf文件按，名字绝对不能错；
  2.先看看/opt目录下默认的sentinel.conf文件的内容；
  3.重要参数项说明：
  1）bind：服务监听地址，用于客户端连接，默认本机地址；
  2）daemonize：是否以后台daemon方式运行；
  3）protected-model：安全保护模式；
  4）port：端口；
  5）logfile：日志文件路径；
  6）pidfile：pid文件路径；
  7）dir：工作目录；
  8）sentinel monitor ，其中quorum为法定投票数；
  设置要监控的master服务器；quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。
  网络是不可靠的有时候一个sentinel会因为网络堵塞而误以为master redis已经死掉，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死掉了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为改master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
  4.sentinel auth -pass
  master设置了密码，连接master服务的密码;
  5.其他

2.3 sentinel通用配置及主从配置

  到对应的redis服务器目录下新增三个配置文件，本文目录是myredis这三个文件:sentinel26379.conf、sentinel26380.conf、sentinel26381.conf。
  都写好了，可以直接复制，配置信息如下

bind 0.0.0.0
daemonize yes
protected-mode no
port 26379
logfile "/myredis/sentinel26379.log"
pidfile /var/run/redis-sentinel26379.pid
dir /myredis
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel authpass mymaster 111111

2.4 先启动一主二从3个redis实例，测试正常的主从复制

  先启动主从复制，后启动哨兵集群。
1.架构说明

  1) 169（地址根据实际IP地址而定，要ipconfig查看本机IP地址是啥）机器上新建redis6379.conf配置文件，由于要配合本次案例，要设计masterauth项访问密码为111111，不然后续可能报错master_link_status:down;

  2) 172机器上新建redis6380.conf配置文件，设置好replicaof ;
  3) 173机器上新建redis6380.conf配置文件，设置好replicaof ;

2. 启动redis
     3台不同的虚拟机实例，启动三台真是机器实例并连接。

redis-server redis6379.conf
redis-server redis6380.conf
redis-server redis6381.conf
redis-cli -a 123456 -p 6379
redis-cli -a 123456 -p 6380
redis-cli -a 123456 -p 6381

3.启动哨兵
在官网中，启动哨兵的两种方式，：

redis-sentinel /path/to/sentinel.conf
redis-server /path/to/sentinel.conf--sentinel

  随便选其中一种启动，注意：**要在对应的目录下执行。

redis-server sentinel26379.conf --sentinel
redis-server sentinel26380.conf --sentinel
redis-server sentinel26381.conf --sentinel

启动后查看进程，ps -ef grep redis。

3. 主节点异常情况

一般情况下查找问就先看日志，日志的路径就是我们刚刚配置的路径/myredis/sentinel26379.log。

3.1.原有的master挂了

  手动关闭6379服务器，模拟master挂了。先在主机中写入数据

思考问题
  两台从机数据是否同步主机的数据；

答案是：可以的，不过经过网络的重新排列需要一定的时间
  是否会从剩下的2台机器上选出新的master；
答案是：会投票选出新的master主机
  之前down机的master机器重启回来，谁将会是新老大？会不会双master冲突；
答案是：谁是master，限本次案例本案例中6381被选举为新的master，上位成功重启6379之后，它会从原来的master降级为slave，而6380还是slave，只不过是换了一个新老大6381(从跟随6379变成跟随6381)。

  sentinel日志描述主节点master挂了以后，如何推选出新的祝节点。

  6379重新回来以后就不在是主节点了，变成了从节点，启动6379以后，使用命令，info replication，可知master_port:6381,master_host也不是原来的主机地址了。

3.2 对比配置文件

  sentinel266379.conf文件展示。

  原主节点master的redis6379.conf文件，先看最后一行，配置了原从节点6381作为主节点，再加上相关的配置。

  新master的redis6381.conf文件，原先6379作为主节点的相关配置被删除了，即。

小总结

  文件的内容，在运行期间会被sentinel动态进行更改；Master-slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换；生产上都是不同机房不同服务器，很少出现3个哨兵全部挂掉的情况可以同时金童多个master，一行一个。

4.哨兵运行流程和选举原理

  当一个主从配置中master失效后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据，一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。

4.1 运行流程，故障切换

  1.三个哨兵监控一主二从，正常运行中；
  2.SDown主观下线(Subjectively Down)
1）SDOWN（主观不可用）是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
2）sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度。
  3.ODown客观下线(Objectively Down)
  1）ODOWN需要一定数量的sentinel，$多个哨兵达成一致意见$才能认为一个master客观上已经宕机。
  2）quorum这个参数是进行客观下线的一个依据，法定人数/法定票数。
意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
   4.选举出领导者哨兵(哨兵中选出兵王)
   1）当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个$领导者哨兵节点（兵王）$并由该领导者也即被选举出的兵王进行failover（故障转移）。哨兵日志文件解读分析；
   2）哨兵领导者，兵王如何选出来的？-> Raft算法。
  监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法;Raft算法的基本思路是先到先得:即在一轮选举中，哨兵A向B发送成为领导者的申请、如果B没有同意过其他哨兵，则会同意A成为领导者。
  5.由兵王开始推动故障切换流程并选出新的master。
   新主登基
  1）某个从节点slave选为master主节点。
  2）选出新master的规则，剩余Slave节点健康前提下，会按下图规则进行选举。
  a.redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)。
  b.复制偏移位置offset最大的从节点(也就是在master还没有宕机时，复制到数据比其他Slave要多)。
  c.最小Run ID的从节点，字典顺序，ASCII码。
  群臣俯首
  a.一朝天子一朝臣，换个码头再拜;
  b.执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点;
  c.sentinel leader会对选举出的新master执行slaveof on one操作，将其提升为master节点;
  d.sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave;
  旧主拜服
  a.原master节点重新连接以后，也降级为从节点
  b.老master重新上线后，会将它设置为新选出的master的从节点
  c.sentinel leader会让原来的master降级为slave并恢复正常工作

上述的failover操作均由sentinel自己独自完成，完全不需要人工干预

哨兵使用建议

  1.哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用。
  2.哨兵节点的数量应该是奇数。
  3.各个哨兵节点的配置应一致。
  4.如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射。
  5.哨兵集群+主从复制，并不能保证数据零丢失，$所以需要使用集群$。

总结

  本篇文章要结合上一篇主从复制架构看逻辑更加清晰，而且上篇文章有详细的配置过程，建议先学会主从复制以后再进行哨兵集群的学习。
  主从复制理论实操详细教程：redis主从复制的理论和实战详细教程