Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。 而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master。
sentinel主要功能如下：
- 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
- 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
- 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
Sentinel的工作方式
每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。 主观下线和客观下线 主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover. SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。 ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。
redis主从复制存在的问题
Redis主从复制可将主节点数据同步给从节点，从节点此时有两个作用： 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
扩展主节点的读能力，分担主节点读压力。
但是问题是： 一旦主节点宕机，从节点上位，那么需要人为修改所有应用方的主节点地址（改为新的master地址），还需要命令所有从节点复制新的主节点
那么这个问题，redis-sentinel就可以解决了
哨兵时如何解决主从复制的问题的
哨兵配置实战
因为哨兵用来解决redis主从复制的问题的, 所以首先应该有一个redis主从的结构, 我使用了三个redis实例来模拟一主两从的环境
创建三个redis的配置文件, 分别用于启动三个redis实例, 端口依次为6379, 6380, 6381
主库
port 6379
daemonize yes
logfile "/opt/redis-4.0.10/conf/shaobing/log/6379.log"
dbfilename "dump-6379.rdb"
dir "/opt/redis-4.0.10/conf/shaobing/data"
从库1
port 6380
daemonize yes
logfile "/opt/redis-4.0.10/conf/shaobing/log/6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/redis-4.0.10/conf/shaobing/data"
slaveof 127.0.0.1 6379 # 绑定主库
从库2
port 6381
daemonize yes
logfile "/opt/redis-4.0.10/conf/shaobing/log/6381.log"
dbfilename "dump-6381.rdb"
dir "/opt/redis-4.0.10/conf/shaobing/data" # 指定主库
启动主, 从库
[root@web01 01:49 /opt/redis-4.0.10/conf/shaobing]# redis-server ./redis-6379.conf
[root@web01 01:50 /opt/redis-4.0.10/conf/shaobing]# redis-server ./redis-6380.conf
[root@web01 01:50 /opt/redis-4.0.10/conf/shaobing]# redis-server ./redis-6381.conf
查看进程
[root@web01 01:50 /opt/redis-4.0.10/conf/shaobing]# ps -ef | grep redis
root 1502 1 0 01:50 ? 00:00:00 redis-server *:6379
root 1507 1 0 01:50 ? 00:00:00 redis-server *:6380
root 1513 1 0 01:50 ? 00:00:00 redis-server *:6381
root 1518 1413 0 01:50 pts/0 00:00:00 grep --color=auto redis
查看主库和从库的身份角色, 以及连接状态
配置哨兵
我配置了三个哨兵, 如下
哨兵的配置解释:
// Sentinel节点的端口
port 26379
dir /var/redis/data/
logfile "26379.log" // 当前Sentinel节点监控 192.168.119.10:6379 这个主节点
// 2代表判断主节点失败至少需要2个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6379 2 //每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒30s且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 30000 //当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，
原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1 //故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000
redis-sentinel-26380.conf和redis-sentinel-26381.conf的配置仅仅差异是port(端口)的不同。然后启动三个sentinel哨兵
查哨兵的运行情况
从下图可以看出三个哨兵的状态都是OK, master是127.0.0.1:6379, 还有两个slave, 三个哨兵
测试哨兵能否完成主从的切换
现在我把主库6379 kill掉, 然后在查看当前的主库是谁, 根据我的配置是在30内检测主库没有响应, 就会选举一个新的主库