Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中
一、Sentinel作用：
1)：Master状态检测
2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave
3)：Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
二、Sentinel工作方式：
1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令
2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds选项所指定的值，则这个实例会被Sentinel 标记为主观下线。
3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。
4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线
5)：在一般情况下，每个Sentinel会以每 10 秒一次的频率向它已知的所有Master，Slave发送INFO命令
6)：当Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次
7)：若没有足够数量的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。
架构：
station11:192.168.1.11 redis master 6379 sentinel 26379
station12:192.168.1.12 redis slave1 6379 sentinel 26479
station13:192.168.1.13 redis slave2 6379 sentinel 26579
环境：CentOS6.8 epel-6-ali.repo ansible
1、ansible安装3机redis
[root@station11 ~]# ansible all -m command -a "yum -y install gcc gcc-c++ tcl"
[root@station11 ~]# wget
[root@station11 ~]# ansible all -m copy -a 'src=/root/redis-3.2.6.tar.gz dest=/root/'
[root@station11 ~]# ansible all -m command -a 'tar -zxvf redis-3.2.6.tar.gz -C /usr/local'
[root@station11 ~]# ansible all -m file -a "src=/usr/local/redis-3.2.6 dest=/usr/local/redis state=link"
[root@station11 ~]# vim make.sh
#!/bin/bash
cd /usr/local/redis
make && make install
[root@station11 ~]# chmod +x make.sh
[root@station11 ~]# ansible all -m copy -a "src=/root/make.sh dest=/root/ mode=0755"
[root@station11 ~]# ansible all -m shell -a "/root/make.sh"
[root@station11 ~]# ansible all -m command -a "mkdir /etc/redis"
[root@station11 ~]# ansible all -m command -a "mkdir -pv /data/redis/6379"
[root@station11 ~]# ansible all -m copy -a "src=/usr/local/redis/redis.conf dest=/etc/redis/"
2.1、修改主库配置文件
[root@station11 ~]# vim /etc/redis/redis.conf
daemonize yes 以守护进程模式运行
bind 192.168.1.11 本机主库监听本机地址
logfile "/var/log/redis_6379.log" 指定日志文件
dir /data/redis/6379 指定rdb数据库存放目录
masterauth RedHat 启动主库验证
requirepass redhat 启动用户进入密码验证
[root@station11 ~]# redis-server /etc/redis/redis.conf&
[root@station11 ~]# ss -nutlp | grep redis
tcp LISTEN 0 128 192.168.1.11:6379 *:* users:(("redis-server",6447,4))
2.2、为slave1提供redis配置文件
[root@station12 ~]# vim /etc/redis/redis.conf
bind 192.168.1.12 #绑定slave1的地址
logfile "/var/log/redis_6379.log"
dir /data/redis/6379
slaveof 192.168.1.11 6379 #此选项是主从配置的关键，指向master的ip和redis端口
slave-priority 95 #slave1服务器的优先级
[root@station12 ~]# nohup redis-server /etc/redis/redis.conf& 后台执行
[1] 2572
[root@station11 ~]# tail -f /var/log/redis_6379.log 主库日志
6447:M 22 Jan 23:49:34.809 * Slave 192.168.1.12:6379 asks for synchronization
6447:M 22 Jan 23:49:34.809 * Full resync requested by slave 192.168.1.12:6379
[root@station12 ~]# tail -f /var/log/redis_6379.log 从库日志
7655:S 22 Jan 23:49:34.555 * Connecting to MASTER 192.168.1.11:6379
7655:S 22 Jan 23:49:34.555 * MASTER <-> SLAVE sync started
2.3、为slave2提供redis配置文件
[root@station12 ~]# scp /etc/redis/redis.conf 192.168.1.13:/etc/redis/
[root@station13 ~]# vim /etc/redis/redis.conf
bind 192.168.1.13
slaveof 192.168.1.11 6379
slave-priority 97
[root@station13 ~]# nohup redis-server /etc/redis/redis.conf&
[1] 5659
[root@station13 ~]# tail -f /var/log/redis_6379.log
5659:S 23 Jan 00:00:12.656 * Connecting to MASTER 192.168.1.11:6379
5659:S 23 Jan 00:00:12.656 * MASTER <-> SLAVE sync started
2.4、检查主从库复制正常？
[root@station11 ~]# redis-cli -h 192.168.1.11 -p 6379