哨兵模式结构
哨兵模式是如何实现高可用的？
我们知道主从结构必须要人工介入才能实现故障转移，服务端主动将slave节点提升为master，而客户端也需要修改连接的ip端口，才能重新连接上新的master。虽然主从结构提供了复制功能，做到数据的备份，但没办法自主故障转移，不能高可用。哨兵模式就是redis官方提供的一种高可用方式。
哨兵是独立于主从集群上的监控管理系统，主要功能是监测redis集群节点状态，故障转移，监控告警等。哨兵连接了master节点和slave节点，并与他们保持心跳链接，当master节点挂了之后，哨兵集群会投票决定节点是不是真的挂了，然后选举出一个主哨兵来执行故障转移，将其中一个slave拉起为master，剩下的节点作为slave节点，复制该节点的数据。而客户端也会订阅哨兵信息，感知到master节点的变化，从而重新连接到redis的新master节点。在不用人工干预的情况下，实现了故障转移。而哨兵自身在生产环境中都是会搭建为3个以上的集群，哨兵之间也会有一些协议，互相监控，保证自身的高可用。
具体步骤如下：
- 哨兵创建的时候，会配置master节点ip和端口，通过向master节点发送info指令，获取redis集群的slave节点信息。
- 向master节点和每一个slave节点发送ping命令，来监测各节点的状态。
- 同时向master节点的sentinel:hello这个主题发布自己的ip端口等信息，所有的哨兵都会订阅这个主题，这样哨兵之间就能感知到加入和离开的哨兵，并向这些哨兵发送ping命令检测状态。
- 当某一个哨兵发现master回复ping命令超过了设置的阈值，这时候会标记为主观下线的状态，然后发送一个命令给其他哨兵，询问节点状态，如果认为挂了的哨兵数量超过设置阈值，就会标记为客观下线。
- 哨兵之间通过投票选举出一个操作的哨兵。
- 这个操作的哨兵会执行故障转移。根据配置的优先级和复制进度等，从剩下的从节点中选出一个最优的slave节点，修改配置slave of no one，自己成为master节点。修改其他slave节点配置，以这个新的master节点为主，复制他们的数据。
- 客户端通过哨兵连接redis集群的时候，是从哨兵获取master节点的地址端口，再连接，并不是通过哨兵代理。一般都会订阅哨兵的信息，感知到master节点变化，就会重新连接到新的节点。
