文章目录
1.哨兵的引入
Redis的主从结构中，一旦主节点挂了，就需要人工切换主节点，否则就无法提供服务，期间其他客户端的请求就无法处理；因此，为了解决这个情况，Redis引入了哨兵机制；
- 所谓的主/从节点，本质都是一个redis-server进程；哨兵节点本质是一个redis-sentinel进程；
- 哨兵节点集合是若干哨兵节点的集合，将其看做是一个整体；之所以搞多个，是为了防止哨兵节点挂了；
- 哨兵机制，是通过独立的进程来体现的，和redis-server是不同的进程；
- redis-sential不负责存数据，只是对其他的redis-server起到监控效果；
2.人工恢复主节点
人工恢复流程：
- 先看主节点是否能抢救；
- 如果主节点的问题不好定位或者短时间难以解决，则挑一个从节点，成为新的主节点；
○ 将选中的从节点，通过slaveof no one变成普通节点；
○ 将其他从节点，修改slaveof的主节点ip和port，连上新的主节点；
○ 告知客户端(修改客户端配置)，让客户端重新连主节点，用来完成数据修改操作； - 如果之前挂的主节点好了，就作为一个新的从节点，挂到这组机器中；
只要涉及人工操作，过程就是很繁琐的，且无法做到第一时间且快速的处理问题；
3.哨兵机制恢复流程
- 通过如上机制，就可以发现主机是否挂了；如果从节点挂了，没关系；如果主节点挂了，就使用哨兵机制
- 当一个哨兵发现主节点挂了(心跳包异常)，还不够，还会和其他哨兵节点共同确认，以防止误判；
- 如果确定了主节点确实挂了，则哨兵节点中会选出一个leader，由leader负责从现有的从节点中，选一个新的主节点；
- 挑选出新的主节点后，哨兵节点会自动控制被选中的节点，执行 slaveof no one 并且控制其他从节点，修改slaveof到新的主节点上；
- 哨兵节点会自动通知客户端程序，现在的主节点是谁，并且后续客户端再进行写操作，就会针对新的主节点进行操作；
4.哨兵节点的功能
根据如上流程，我们可以得出哨兵节点的功能：
- 监控： 监控主/从节点的工作状态，并且及时发生他们是不是挂了；
- 自动故障转移：主节点挂了，其会从从节点中选一个，使其成为新的主节点，保证整个Redis仍然可以继续读和写，不要人工干预；
- 通知：当转移完成后，其会通知其他客户端
问题一：为什么引入多个哨兵节点？一个行不行？
- 如果只使用一个哨兵节点，但其本身挂了，后续redis主节点挂了，就没办法进行自动恢复了；
- 只使用一个哨兵节点的误判概率比较高，因为网络传输数据是会发生抖动或者延迟丢包的，如果出现该问题，就可能误判，因此引入其他哨兵节点共同判断；
- 分布式系统中，应该尽可能避免"单点"，多点最好是"奇数"个；
5.哨兵选举主节点流程
- 主观下线：哨兵节点通过心跳包，判断redis服务器是否正常工作，如果心跳包未正常收到，则认为服务器挂了；此时还无法排查是否为网络状态的影响，单方面认为redis挂了；
- 客观下线：多个哨兵都认为主节点挂了(认为挂了的哨兵节点达到一定票数，比如说总票的一半)，哨兵们就主观认为主节点挂了；
- 让多个哨兵节点选出一个leader节点，由leader负责从从节点中选取一个节点作为新的主节点；
- leader选举完毕，leader从从节点中选一个作为主节点：
a. 根据优先级 ：每个redis的数据节点在配置文件中都有一个优先级设置；slave-priority优先级高的节点，就胜出
b. 根据offest : offest反映了数据的同步进度，说进度快，谁就胜出
c. run id: 每个redis节点启动都会随机生成，谁大选谁
问题一：是否会出现发生严重的网络波动，哨兵节点联系不上redis服务器，导致误判呢？
- 可能，但这种情况下，大概率客户端也连不上主节点，此时主节点基本也没发工资了；