哨兵的核心功能是主节点的自动故障转移
下图是一个典型的哨兵集群监控的逻辑图
Redis Sentinel包含了若干个Sentinel 节点，这样做也带来了两个好处：
1、 对于节点的故障判断是由多个sentinel节点共同完成，这样可以有效地防止误判
2、即使个别sentinel节点不可用，整个sentinel集群依然是可用的
哨兵实现了以下功能：
1、监控：每个sentinel节点会对数据节点（Redis master/slave节点）和其余sentinel节点进行监控
2、通知：sentinel节点会将故障转移的结果通知给应用方
3、故障转移：实现slave晋升为master，并维护后续正确的主从关系
4、配置中心：在Redis sentinel模式中，客户端在初始化的时候连接的是sentinel节点集合，从中获取主节点信息
其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置中心和通知功能，则需要在与客户端的交互中才能体现
1、原理
监控
sentinel节点需要监控master、slave以及其他sentinel节点的状态。这一过程是通过Redis的pub\sub系统实现的。Redis sentinel一共有三个定时监控任务，完成对各个节点发现和监控：
主观/客观下线
主观下线
每个sentinel节点，每隔1s会对数据节点发送ping命令做心跳检测，当这些节点超过down-after-milliseconds没有进行有效回复时，sentinel节点会对该节点做失败判定，这叫主观下线
客观下线
客观下线，是指当大多数sentinel节点都认为master节点宕机了，那这个判定就是客观的，叫客观下线。
那大多数是指什么呢？ 其实就是分布式协调中的quorum判定啦，大多数就是指半数。 如哨兵数量是5，那大多数就是5/2+1=3个，哨兵数量是10大多数就是10/2+1=6个。
注：sentinel节点的数量至少为3个，否则不满足quorum判定条件
哨兵选举
如果发生了客观下线，那哨兵节点会选举出一个leader来进行实际的故障转移工作。Redis使用了Raft算法来实现哨兵领导者选举，大致思路如下：
故障转移
选举出的leader sentinel节点将负责故障转移，也就是进行master/slave节点的主从切换。故障转移，首先要从slave节点中筛选出一个作为新的master，主要考虑以下slave信息
注：Leader sentinel 节点，会从新的master节点那里得到一个configuration epoch，本质是个version版本号，每次主从切换的version号都必须是唯一的。其他的哨兵都是根据version来更新自己的master配置