sentinal 哨兵机制 主要功能
1. 集群的监控 负责监控redis master slave 进程是否正常工作
2. 消息通知 sentinal发现某个节点的有故障会给管理员发送消息
3.故障转移 如果master node发生故障会自动将slave node 节点转化成master node
4.配置中心 如果故障转移发生了，通知client客户端新的master地址
sentinal 本身也是分布式的，作为一个集群相互协作
1.哨兵至少需要三个实例，来保证自己的健壮性。再判断master node是否岩机的时候需要大部分哨兵同意才可以
2.哨兵+主从的部署架构，是不会保证数据的零丢失的，只能保证redis集群的高可用
哨兵集群的自动发现机制
哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在
每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置
每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
在sentinal模式下数据丢失的情况
1.主备切换的过程可能会导致数据的丢失
master->slave 的数据复制时异步的，还有部分数据没有同步到slave的时候master突然岩机，就会导致部分未复制的数据丢失
2.脑裂问题导致的数据丢失
某个master所在的服务器脱离了正常的网络，导致sentinal以为这个master岩机了，推举除了新的master,这个时候集群中就存在2个master，这就是脑裂。
此时客户端还没来得及切换到新的master上 依然在旧的master上写数据，这部分数据也会丢失。当旧的master再连接到网络的时候sentinal把旧的master当作slave 挂在新的master上面，自己的数据会清空，冲i新复制新的master上面的数据。
数据丢失的解决方案
redis.conf文件中有这两个参数
min-slaves-to-write 1 最少的slave个数
min-slaves-max-lag 10 最大的延时时间
表示 最少1台slave的数据复制和同步不能延迟master 10s 如果超过10smaster不再接受写请求。
基于这个配置需要再客户端当写请求被拒绝以后，我们通过代码控制，将数据暂时缓存再消息队列。可以做一个延时的队列，等国一段时间之后再向redis写。
sdown和odown两种失败状态
sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机
odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机
sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机
slave->master选举算法
当一个master被认为时odown 而且majority哨兵都允许了主备切换，那么这个时候就要选举一个slave出出来
1.比较跟master断开的时长，断开的时间越短的得分越高
2.slave本省的优先级，优先级越高的得分越高
3.在上面的数据都一样的情况下会考虑复制的offset ,谁复制的数据更多，谁得分就高
4.run id
当选举出来一个slave后，会有一个哨兵主持这个次的主备切换工作，切换工作完成会给master生成一个新的version号，并将这个新的master的所有的信息发布到消息队列，其他的哨兵监听到消息后，会根据version来对比，比自己的版本新的数据他们都会更改本地的数据跟最新的版本保持一致。
