哨兵系统是Redis的一个高可用解决方案，它负责监控主节点是否故障，当主节点故障时自动从从节点中选新主，并通知其他从节点及客户端。哨兵通过定期发送ping命令来监控主节点，多个哨兵协同判断主节点是否客观下线。一旦确定主节点故障，会选择优先级最高、复制进度最前的从节点作为新主，并通知其他节点和客户端进行切换。
“无数的我们被世界碾压成一缩黑团，无数的我们试图与世界抗争到底”🌹
参考资料：图解redis
目录
话不多说，发车！
什么是哨兵机制？
我们都知道redis的架构是主从模式，即有一个主节点和多个从节点。试想这个问题，如果主节点发生故障宕机，那么也就无法再响应客户端的操作，尤其对于写操作，主节点故障宕机之后也就无法将数据同步给从节点。
这时，就需要人为地从众多从节点中选出一个作为主节点，然后让剩余从节点来指向这个主节点。这个过程的缺点就在一，选取主节点的过程需要人工操作。
但是引入了哨兵机制，就不需要人为介入了，哨兵机制的作用就是当主节点故障宕机之后，选取主节点并继续接收客户端的请求。
哨兵机制主要干了哪三件事？
- 监控：监控主节点是否发生故障
- 选主：从众多从节点中选出一个作为主节点
- 通知：通知其他的从节点，主节点已经更换
哨兵监控主节点的过程是怎样的？
哨兵每间隔一秒就会向主节点发送ping命令，如果能够收到响应，则说明主节点在正常工作；如果在规定时间内没有收到响应，那么哨兵就会认为主节点主观下线
这里的主观下线是说，只有发送ping命令的当前这一个哨兵判断主节点出故障了。虽然，主节点没有对ping命令作出回应，可能的原因还有网络阻塞等等，实际上主节点没有下线。为了避免这种误判的情况，就引入了一个哨兵集群，让多个哨兵一起判断主节点到底是否发生故障，如果多个哨兵都认为主节点故障，那么主节点此时会被判定为客观下线，所以客观下线是多个哨兵一起判定的结果
具体过程如下：
- 一个哨兵对主节点发送ping命令，主节点未回应，此时主节点被判断为主观下线
- 当前哨兵向哨兵集群中的其他哨兵发送命令，让它们来判断主节点是否下线
- 哨兵集群开始投票，如果认为主节点下线就投赞成票，否则投反对票
- 如果赞成票的数量大于等于配置中的quorum值，那么主节点被判定为客观下线，进行切换主节点的操作
判断主节点故障之后，谁来执行切换主节点的操作？
哪个哨兵判断主节点主观下线，就由哪个哨兵来执行切主操作
比如哨兵A判断主节点主观下线，并且在其他哨兵投票之后，主节点被判断为客观下线，会向哨兵B和哨兵C发送命令，表示哨兵A想执行切主操作，由哨兵B和哨兵C来进行投票，哨兵A如果想得到执行主从切换的资格，必须要满足两个条件：
- 拿到半数以上的赞成票
- 赞成票的数量要大于等于配置中的quorum值
切换主节点的过程是怎样的？
切换主节点的过程主要分为四步：
- 从旧主节点的所有从节点中，选出新主节点
- 让旧主节点的从节点去复制新主节点的数据
- 将新主节点的IP地址和信息通过发布、订阅机制通知客户端
- 监控旧主节点，当其上线后将其修改为新主节点的从节点
第一步：选出新的主节点
这个过程涉及到三轮考察：优先级考察、复制进度考察、ID号考察
- 优先级考察：redis配置文件中有个slave-priority字段表示优先级，进行优先级考察时就根据这个字段，选择优先级最高的从节点来当选主节点
- 复制进度考察：如果有两个优先级相同的从节点，需要再判断复制进度（复制进度也就是从节点复制主节点最新数据的进度），在优先级相同的情况下，复制进度靠前的从节点会胜出
- ID号考察：如果两个节点优先级和复制进度都相同，就会进入到这一轮，ID号就是每个节点的编号，它是用来唯一的标识节点的
经过以上三轮考察，就可以选举出一个新的主节点了，选出新主节点之后，这个新主节点使用SLAVEOF no one命令，解除从节点的身份，就真正的成为主节点了
第二步：所有从节点指向新主节点
哨兵向所有从节点发送slave of命令，之后旧主节点的从节点就成为新主节点的从节点了
第三步：通知客户，主节点已经切换
通知过程主要是由redis的订阅/发布机制来实现的，客户端先订阅哨兵提供的频道，然后哨兵向频道发送新主节点的IP和端口的信息，客户端就可以拿到这些消息，然后利用这些信息和主节点进行通信
第四步：当旧主节点上线之后，将其变为新主节点的从节点
旧主节点同样使用slave of命令，就变为新主节点的从节点了
整理面经不易，觉得有帮助的小伙伴点个赞吧~感谢收看！
192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
