sentinel工作原理：
在主从节点和sentinel节点集合配置好之后，sentinel节点之间会相互发送消息，以检测其余sentinel节点是否正常工作，并且sentinel节点也会向主从节点发送消息，以检测监控的主从节点是否正常工作。这里如果主节点因为故障下线，那么某个sentinel节点发送检测消息给主节点时，如果在指定时间内收不到回复，那么该sentinel就会主观的判断该主节点已经下线，那么其会发送消息给其余的sentinel节点，询问其是否"认为"该主节点已下线，其余的sentinel收到消息后也会发送检测消息给主节点，如果其认为该主节点已经下线，那么其会回复向其询问的sentinel节点，告知其也认为主节点已经下线，当该sentinel节点最先收到超过指定数目（配置文件中配置的数目和当前sentinel节点集合数的一半，这里两个数目的较大值）的sentinel节点回复说当前主节点已下线，那么其就会对主节点进行故障转移工作，故障转移的基本思路是在从节点中选取某个从节点向其发送slaveof no one（假设选取的从节点为127.0.0.1:6380），使其称为独立的节点（也就是新的主节点），然后sentinel向其余的从节点发送slaveof 127.0.0.1 6380命令使它们重新成为新的主节点的从节点。重新分配之后sentinel节点集合还会继续监控已经下线的主节点（假设为127.0.0.1:6379），如果其重新上线，那么sentinel会向其发送slaveof命令，使其成为新的主机点的从节点，如此故障转移工作完成。
环境：centos6.5 + redis 3.2.10
master：10.20.44.13:6379
slave1：10.20.44.17:6379
slave2：10.20.44.18:6379
redis主从安装：
略
sentinel安装：
[root@master ~]# cp /usr/local/redis/sentinel.conf /etc/
[root@master ~]# cat /etc/sentinel.conf ####注意，以下配置是有顺序的，不能打乱顺序
daemonize yes
port 26379 #####哨兵自己的端口
dir /usr/local/redis/logs
sentinel monitor mymaster 10.20.44.13 6379 2 #配置主节点的ip和端口，2表示在sentinel集群中只要有两个节点检测到redis主节点出故障就进行切换，单sentinel节点无效(自己测试发现的)
sentinel down-after-milliseconds mymaster 30000 #如果30s内mymaster无响应，则认为mymaster宕机了
sentinel failover-timeout mymaster 10000 #如果10秒后,mysater仍没活过来，则启动failover
sentinel auth-pass mymaster 123456 #redis主节点密码 ，如果master没设置密码则不需要这一行
sentinel parallel-syncs mymaster 1 #在发生failover主备切换时，这个选项指定了最多可以有多少个slave同时对新的master进行同步，同步时不能处理请求
logfile "sentinel.log"
protected-mode no 注意：在redis3.2之后一定要在哨兵配置文件中加入这一项，不然会哨兵节点之间无法通信，日志中会出现其余节点sdown情况报错：
排查方法：
[root@master etc]# redis-cli -p 26379 -h 10.20.44.13 info #出现下面错误即表示哨兵节点间无法通信，要去掉保护模式。
验证sentinel：
[root@master etc]# redis-sentinel /etc/sentinel.conf
[root@master etc]# netstat -tnlp |grep 26379
[root@master etc]# redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1
127.0.0.1:26379> sentinel masters //确认master的信息
127.0.0.1:26379> sentinel slaves mymaster //确认slave信息
配置slave2,slave3服务：
[root@slave1 ]# scp /etc/sentinel.conf 10.20.44.17:/etc/sentinel.conf
[root@slave1 ]# scp /etc/sentinel.conf 10.20.44.18:/etc/sentinel.conf
启动slave2，slave3的哨兵服务:
[root@slave2 ]# redis-sentinel /etc/sentilen.conf
[root@slave3 ]# redis-sentinel /etc/sentilen.conf
验证自动切换：
[root@master etc]# redis-cli -p 6379 shutdown //将主库关机
[root@slave1 ]# redis-cli -p 6379 //登录slave1，查看输出结果中角色是否为master
127.0.0.1:6380> info replication 在这个系统中，初始状态下redis3是master, redis1和redis2是slave。之后redis3所在的主机网络不可用了，sentinel1和sentinel2启动了failover并把redis1选举为master，并且更新了自己的sentinel配置。
但是sentinel3依然持着的是旧配置，因为它与外界隔离了。如果此时客户端所连接的master被网络隔离，会发生什么呢？
客户端将依然可以向redis3写数据，但是当网络恢复后，redis3就会变成redis的一个slave，那么在网络隔离期间，客户端向redis3写的数据将会丢失。
你可以通过以下配置来配置redis3和redis1，使得数据不会丢失。修改redis.conf配置文件：
min-slaves-to-write 1
min-slaves-max-lag 10
通过上面的配置，当一个redis是master时，如果它不能向至少一个slave写数据(上面的min-slaves-to-write指定了slave的数量)，它将会拒绝接受客户端的写请求。
由于复制是异步的，master无法向slave写数据意味着slave要么断开连接了，要么不在指定时间内向master发送同步数据的请求了(上面的min-slaves-max-lag指定了这个时间)。Sentinel命令
127.0.0.1:26379> sentinel masters
127.0.0.1:26379> sentinel slaves mymaster
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
127.0.0.1:26379> SENTINEL reset mymaster
127.0.0.1:26379> SENTINEL failover mymaster
127.0.0.1:26379> SENTINEL flushconfig mymaster