为什么Redis哨兵集群至少三节点？
前言
接上篇，由于Redis主从无法达到高可用性，所以Redis通过哨兵的方式在Redis主从基础上实现高可用Redis集群
Redis哨兵
哨兵是redis集群架构中非常重要的组件，哨兵主要用来解决主从复制故障时需要人为干预的问题
Redis哨兵主要功能
集群监控：负责监控Redis master和slave是否正常工作消息通知：redis实例故障，哨兵负责发送消息作为告警通知管理员故障转移：master节点故障，自动重新选举master，实现集群自愈配置中心：故障发生后，通知client客户端及其他slave新的master地址
原理
Redis哨兵使用的算法核心是Raft算法，主要用途就是用于分布式系统，系统容错，以及leader选举，整个过程如下：
每个Sentinel会自动发现其他Sentinel和从服务器，通过每秒一次的频率向它所知的主服务器、从服务器以及其他Sentinel实例发送一个PING命令如果一个实例距离最后一次有效回复PING命令的时间超过down-after-millisenconds选项指定的值，那么这个实例会被Sentinel标记为主观下线，有效回复不一定是PONG，可以是-LOADING或者-MASTERDOWN如果一个主实例被标记为主管下线，那么正在监视这个主服务器的所有Sentinel要以每秒一次的频率去确认主实例确实进入了主管下线状态如果一个主实例被标记为主观下线，并且超过quorum数量的Sentinel在指定的时间范围内认同这一判断，那么这个主实例就被标记为客观下线在一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有主实例和从实例发送INFO命令，当一个主实例被Sentinel标记为客观下线时，Sentinel向下线主实例的所有从服务器发送INFO命令频率会从10秒改为每秒一次当没有足够quorum数量的Sentinel同意主实例已经下线，主实例的客观下线状态就会被移除，当主服务器重新向Sentinel的PING命令返回有效回复时，主实例的主观状态会被移除
后面通过实例日志可以看到更详细的步骤
哨兵搭建实践
主从搭建请参考上一篇，直接看哨兵配置，哨兵配置文件为sentinel.conf，配置参数详解如下：
# 哨兵sentinel实例运行的端口，默认26379
port 26379
# 哨兵sentinel的工作目录
dir ./
# 是否开启保护模式，默认开启。
protected-mode:no
# 是否设置为后台启动。
daemonize:yes
# 哨兵sentinel的日志文件
logfile:./sentinel.log
# 哨兵sentinel监控的redis主节点的
## ip：主机ip地址
## port：哨兵端口号
## master-name：可以自己命名的主节点名字（只能由字母A-z、数字0-9 、这三个字符".-_"组成。）
## quorum：当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor
## 这里IP不要用127.0.0.1
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass，所有连接Redis实例的客户端都要提供密码。这里提示下，Redis，master实例也需要配置masteruth，否则master实例下线重新上线后，会无法加入到集群中
# sentinel auth-pass
sentinel auth-pass mymaster 123456
# 指定主节点应答哨兵sentinel的最大时间间隔，超过这个时间，哨兵主观上认为主节点下线，默认30秒
# sentinel down-after-milliseconds
sentinel down-after-milliseconds mymaster 30000
# 指定了在发生failover主备切换时，最多可以有多少个slave同时对新的master进行同步。这个数字越小，完成failover所需的时间就越长；反之，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1，来保证每次只有一个slave，处于不能处理命令请求的状态。
# sentinel parallel-syncs
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间failover-timeout，默认三分钟，可以用在以下这些方面：
## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
## 2. 当一个slave从一个错误的master那里同步数据时开始，直到slave被纠正为从正确的master那里同步数据时结束。
## 3. 当想要取消一个正在进行的failover时所需要的时间。
## 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来同步数据了
# sentinel failover-timeout
sentinel failover-timeout mymaster 180000
# 当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本。一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
# 对于脚本的运行结果有以下规则：
## 1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10。
## 2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# sentinel notification-script
sentinel notification-script mymaster /var/redis/notify.sh
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
配置好Sentinel配置之后，启动顺序是先启动Redis主，然后启动Redis从，主从启动完后，启动Sentinel
启动完成后，登录进入Redis主实例，查看replication信息
127.0.0.1:6379
