一、哨兵的主要功能
哨兵是redis集群架构中非常重要的一个组件，主要功能如下：
（1）集群监控：负责监控redis master和slave进程是否正常工作。
（2）消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
（3）故障转移：如果master node挂掉了，会自动转移到slave node上。
（4）配置中心：如果故障转移发生了，通知client客户端新的master地址。
二、哨兵的核心知识
（1）哨兵至少需要3个实例来保证自己的健壮性。
（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性。
（3）哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。
（4）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行。
下面我们说说第一点，为什么至少需要3个实例来保证自己的健壮性。假设哨兵集群仅仅部署了2个实例，然后quorum=1（至少有1个哨兵认为master宕机），majority=2（用于表示集群中有几个哨兵是运行的，通常是集群数的一半+1）。
现在当Master进行挂掉后，sentinal-1和sentinal-2只要有1个哨兵认为master宕机就可以进行切换，同时sentinal-1和sentinal-2两个哨兵都是正常运行的，就可以允许执行故障转移，此时会选举出一个哨兵来执行故障转移。
但是如果节点1宕机了，那么只有哨兵sentinal-2正常运行，即使只要它认为master宕机了，但是由于没有达到majority的条件，所以不会进行故障转移。如果是3个节点，那会是怎样的呢？
quorum=2，majority=2 。此时即使节点1宕机了，那么三个哨兵还剩下2个，sentinal-2和sentinal-3可以一致认为master宕机，然后选举出一个来执行故障转移。同时3个哨兵还剩下的2个哨兵运行着，等于majority，就可以允许执行故障转移。
三、哨兵主备切换数据丢失问题
3.1、两种数据丢失的情况
（1）异步复制导致的数据丢失
因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了。
（2）脑裂导致的数据丢失
脑裂，也就是说某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master。这个时候，集群里就会有两个master，也就是所谓的脑裂。
此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了。因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据。
3.2、解决异步复制和脑裂导致的数据丢失
两个相关的配置项如下，即要求至少有1个slave，数据复制和同步的延迟不能超过10秒。如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了。
min-slaves-to-write 1
min-slaves-max-lag 10（1）减少异步复制的数据丢失
有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内。
（2）减少脑裂的数据丢失
如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。