前言
前面已经介绍过持久化的两种机制，以及主从复制的原理，部署。这里所谓的高可用，讲的是99.99（或者99.9%或者99%）的时间内，系统是可用的。下面我们就看下哨兵模式的相关概念。
基本介绍
功能：
哨兵是redis集群架构中非常重要的组件，主要有以下几个功能：
1.负责监控mater和slave的进程是否正常工作；如果某个实例有故障，那么哨兵会把报警消息发送给redis系统管理员。
2.如果master发送了故障，会自动转移到slave上。会通知client客户端新的master地址。
核心逻辑：
1.哨兵本身也是分布式的，哨兵是集群部署，会协同工作：比如故障发生时，需要大部分的哨兵都同意才可以做切换；
2.哨兵至少需要3个redis实例，来保证监控的健壮性；哨兵以及主从的部署架构，不能保证数据的丢失，但能保证redis集群的高可用性。
数据丢失的场景：
场景一：主备切换的过程中，可能会导致数据的丢失，因为有些数据还没复制到slave，master就死机了，这些数据就会丢失。
场景二：某个master的网段有问题（其实master还是活着，继续提高服务）， 其他slave机器不能连接，这时候可能会开始新的选举，将其他的slave切换成master；这时候就会出现两个master，会导致数据的不一致（因为有些client可能还没有切换到新的，继续往老的写数据）。
解决方案：配置参数如下（意义：至少有一个slave，数据复制和同步的延迟不能超过10秒）；
min-slaves-to-write 1
min-slaves-max-lag 10
也就是说所有的slave，数据同步以及符合的延迟都超过10秒钟，master就不会对外提供服务。如果不能给指定数据的slave发送数据，并且slave超过10秒没有给自己ack，master也不会对外提供写服务。
sdown和odown转换机制
sdown：主观宕机，就一个哨兵如果自己觉得一个master宕机了，超过了is-master-down-after-milliseconds指定的毫秒数之后，那么就是主观宕机
odown：客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，在指定时间内，收到了quorum指定数量的其他哨兵也认为master是sdown了，那么就是客观宕机
选举算法：
哨兵集群总的哨兵实例会跟其他哨兵交换对master的监控配置信息，相互同步监控配置。
如果一个master被认为odown了，而且majority哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，首先要选举一个slave来。
quorum和majority解析：
如果哨兵需要执行主备切换，需要quorum个数量的哨兵认为odown，然后这个哨兵还要得到majority个哨兵的授权，才可以进行切换。
如果quorum
部署步骤
配置
哨兵集群至少需要3个实例，我们分别在三台redis服务器上配置sentinel的配置文件。
创建配置文件，将文件重命名为6000.conf;将文件拷贝到/etc/sentinel/
mkdir /etc/sentinal
mkdir -p /var/sentinal/6000
port 6000
bind 192.168.0.10
dir /var/sentinal/6000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster redispwd
daemonize yes
logfile /var/log/sentinal/6000
mkdir -p /var/log/sentinal/6000
port 6000
bind 192.168.0.20
dir /var/sentinal/6000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster redispwd
daemonize yes
logfile /var/log/sentinal/6000
mkdir -p /var/log/sentinal/6000
port 6000
bind 192.168.0.30
dir /var/sentinal/6000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster redispwd
daemonize yes
logfile /var/log/sentinal/6000
mkdir -p /var/log/sentinal/6000启动哨兵进程
redis-sentinel /etc/sentinal/6000.conf
日志里会显示出来，每个哨兵都能去监控到对应的redis master，并能够自动发现对应的slave；哨兵之间，互相会自动进行发现，用的就是之前说的pub/sub，消息发布和订阅channel消息系统和机制
查看哨兵状态：
redis-cli -h 192.168.0.10 -p 6000
sentinel master mymaster
sentinel slaves mymaster
sentinel sentinels mymaster
不足之处
目前这种基于哨兵的主从复制，一主多从架构，能够保证高可用的同时，又能够支持slave节点的水平扩展，支持读多写少的场景。 但是单个master的瓶颈也是不言而喻的，单机支持的数据量有限，如何能够支持海量的高可用服务，redis cluser就可以针对海量数据+高并发+高可用的场景。