目录
前言：
手动干预主节点挂的情况
哨兵节点操作流程
哨兵重新选取主节点流程
主观下线
客观下线
哨兵节点选leader
挑选从节点作为主节点
前言：
redis在主从模式下，主节点服务就显的尤为重要。为了保证redis集群的高可用，提出的哨兵模式。哨兵集群只负责监控主节点，如果主节点挂了，哨兵节点就可以在从节点中选取一个作为主节点，保证了redis集群服务的可靠性。
哨兵机制是通过独立的进程体现的（redis-sentinel），和redis-server不是一个进程。redis-sentinel不负责存数据，只是对其他的resid-server起到监控的效果。通常哨兵节点也会搞一个集合，也是提供redis集群的高可用（防止哨兵节点挂了的情况）。
手动干预主节点挂的情况
1）把选中的从节点，通过slaveof no one 自立山头。
2）把其他的从节点，修改slaveof的主节点 ip和port连接上新的主节点。
3）告知客户端（修改客户端配置），让客户端能够连接新的主节点，用来完成数据的修改操作。
4）当之前挂的主节点修复完成后，就可以作为从节点，挂到这组机器中。
哨兵节点操作流程
监控：哨兵集群会和数据节点集合建立tcp长连接，定期发送心跳包检测redis数据节点是否正常运行。
如果主节点挂了，一个哨兵发现了还不足以判定该主节点确实挂了，需要多个哨兵都认同此判定。主要是为了防止误判（网络波动等）。
客观认为主节点确实挂了，这些哨兵节点会选举一个leader。由这个leader负责从现有从节点中选出一个作为新主节点。
挑选出新节点后，哨兵节点会控制该节点，执行slaveof no one让该节点作为master。并且控制其他从节点修改slaveof到新主节点上。
哨兵节点会自动通知客户端程序，告诉新主节点ip和port。后续客户端写操作就会针对新主节点进行了。
哨兵的核心功能：
1）监控：判定主节点是否挂了。
2）自动故障转移：修改主从关系。
3）通知：通知客户端主节点发生改变。
哨兵重新选取主节点流程
主观下线
哨兵节点通过心跳包，判定redis主节点服务器是否正常工作。如果心跳包没有如约而至，则说明redis服务器挂了。
注意：
此时不能排除因为网络波动，因此只能单方面判断redis服务挂了。
客观下线
多个哨兵都认为主节点挂了（认为哨兵节点挂了的数量达到法定票数）。哨兵们就认为主节点是客观下线。
法定票数：哨兵节点配置文件中进行配置。
哨兵节点选leader
要让多个哨兵节点选出一个leader，这个leader负责选一个从节点作为主节点。
当哨兵1首先发现主节点客观下线后，首先给自己先投一票，然后通知哨兵2和3（拉票），哨兵2和3发现主节点客观下线后（反应慢半拍），立即会给一号哨兵投赞成票。
哨兵2和3当它们没有投出自己手里票的时候，收到拉票请求，就会投出去。（如果有多个拉票请求，就会投给最先到达的）
如果总的票数超过哨兵总数的一半，选举就完成了。（把哨兵节点设置为奇数个，就是为了方便投票）
注意：
上述投票过程，就是看谁首先发现主节点客观下线（网络延时小），然后自己给自己投完后，进行拉票，其他哨兵收到拉票请求后也会投赞成票。
挑选从节点作为主节点
此时leader选举完成，leader就会挑选一个从节点作为主节点。
1）优先级
每个redis数据节点，都会在配置文件中，有一个优先级设置（slave-priority），优先级高的就会胜出（默认优先级都是相等的）
2）offset
offset最大就会胜出。offset是从节点从主节点这边同步数据的进度，数值越大，说明从节点数据越接近主节点。
3）run id
此时优先级和offset都一样，其实随便挑选一个就可以。每个redis启动的时候，都会随机生成一串数字，挑最小的run id作为主节点。
注意：
1）指定好新的主节点之后，leader就会控制这个节点，执行slave no one 成为 master。
2）在控制其他从节点，执行slave of，让其他从节点以新的 master 作为主节点
3）通知客户端，新主节点 ip 和 port，这个时候主节点就更换完成。
4）后续如果发现原主节点上线运行正常后（心跳包），那么将会作为从节点挂到这组机器上。
小结：
redis哨兵模式只是提供了redis集群的高可用，不能解决极端情况下写丢失问题，并且也不能增加存储容量（需要redis集群解决）。
