redis高可用-哨兵模式原理篇

上一篇，我们介绍了哨兵模式搭建
如果你跟着文档一步步的进行了安装，我相信你可能会有一些疑问。

1、主节点被kill，下线。哨兵是怎么知道的呢?有没有可能误判

哨兵和主节点之前有定时的通信，哨兵每隔1秒就会给主节点发送一个ping消息，同时主节点要给哨兵回复一个pong消息
下面我们使用tcpdump命令抓包看一下这个ping、pong消息。

#监听eth0网卡的tcp通信,将监听结果输出到sentinel.cap文件
tcpdump -i eth0 -w /tmp/sentinel.cap

然后我们将文件下载到本地(可以使用sz命令，如：sz /tmp/sentinel.cap)
之后，需要下载cap文件分析工具wireshark，wireshark下载
下载之后，打开我们下载到本地的sentinel.cap文件

可以看到，36891端口给6081端口(主机端口)发了很多消息，我们找一条看看都发了点啥
选中消息，右键—>Follow—>TCP Stream

报文里有很多这个消息片段，这个是redis的RESP协议内容
红色部分是请求，蓝色部分是响应
*1：该请求是一个数组，数组中有1个元素
$4：数组的内容长度是4字节
PING：请求内容是PING
+PONG：+代表这是一个响应消息，PONG是响应内容
所以以上tcp消息的意思就是：哨兵给主节点发送了一个PING，主节点给哨兵回复了一个PONG
如果在down-after-milliseconds时间内，主节点没有回复PONG消息，哨兵就会认为主节点已经下线
如果哨兵和主节点之间有网络延迟或者其他原因，是有可能导致误判的。
实际上，当一个哨兵发现主节点通信超时后，它自己会先标记主观下线，然后会给其他哨兵发送is-master-down-by-addr命令，让其他哨兵检查自己和主节点之间的连接情况。如果超过quorum个哨兵反馈主节点连接失败，此时会将主节点置为客观下线，意思是：主节点下线已经是一个客观事实。通过这种方式，就可以避免哨兵误判的情况

2、主节点被kill，哨兵如何选择一个新主节点?

这个过程可以理解为"筛选+打分"
筛选：筛选从节点的网络状态。依据是：和主节点的断连时间超过down-after-milliseconds * 10，意思是：和主节点断连超过10次，说明这个从节点的网络状况不好，不适合作为主节点。
打分：
1)、是否给从节点设置了优先级，如果设置了优先级，此时会优先将这台从机选为新的主节点。可以通过slave-priority参数来设置优先级，越小的数值代表优先级越高。
2)、从机的复制状态，哪一台更接近主机。复制状态的意思是:每一台从机在和主机进行数据同步时，都会有一个slave_repl_offset，master也会有一个master_repl_offset。最接近master_repl_offset的从机得分最高，会直接被选为新的主节点
3)、如果优先级和复制状态都相同，此时会比较实例的id号，每台实例都会有一个id号，哪台从机的id号最小，就会被选为新的主机。

3、选择好了新主节点，3个哨兵，如何确定由哪个哨兵完成主从切换呢?

确定由哪个哨兵完成主从切换，这其中涉及到了Raft算法，选举出的leader进行主从切换。当一台哨兵节点发现主节点宕机后，会立刻通知其他哨兵节点该消息，同时请求成为leader进行主从切换。其他哨兵收到该消息后，会对该请求进行投票。
如果一个哨兵想成为leader，至少需要满足两个条件。
1)、拿到半数以上的赞成票
2)、赞成票的票数需要大于等于配置文件中的quorum值。
我们这个例子，哨兵数量是3，所以一个哨兵想成为leader，拿到2票赞成就可以了。
投票过程如下：
s1发现主节点下线，执行is-master-down-by-addr命令，询问其他哨兵节点对于主节点的连接状态判断，并请求成为领导者。此时s2和s3可能并没有发现主节点失连，他们就会给s1投票，同意s1成为领导者。当s2和s3判断主节点主观下线后，此时他们再想成为领导者已经不行了，因为已经把票投给了s1，每个哨兵只有一票
实际的选举过程会很简单，基本上哪个哨兵先观察到主观下线，那它就是领导者

4、主从切换完成，客户端如何感知新的主节点？

客户端可以订阅+switch-master频道来监听主节点的变化，如果主节点宕机，哨兵领导者选出了新的主节点，会向这个频道发送消息告知客户端新的主节点地址。我们测试一下。
登录一台哨兵节点。订阅+switch-master频道

127.0.0.1:26001> subscribe +switch-master

然后kill掉主节点，此时会收到消息。如下：
主节点已经从6082改为6081，此时客户端就感知到了主节点的变化

5、哨兵配置文件中，没有配置其他哨兵的ip、端口，哨兵之间是怎么相互发现并组成集群的呢?

是通过pubsub机制，哨兵都会订阅一个__sentinel__:hello的频道，当一个哨兵启动后，会将自己的ip和端口发送到这个频道，此时其他哨兵就会得知一个新的哨兵启动了，就可以得到这个哨兵的地址，并和其进行网络连接

6、哨兵配置文件中只配置了主节点的ip地址，哨兵是怎么知道从节点ip地址的呢?

通过给主机发送info命令，获取从机的ip地址，info命令中有一个replication模块，这个模块里记录了所有从机的地址

7、3个哨兵节点，最多允许宕几台？

最多允许宕1台，为什么呢?因为哨兵领导者选举时，想成为领导者的实例需要获得一半以上的赞成票，比如3台哨兵，就需要获得3/2 + 1 = 2，获得2票赞成才可以，宕掉一台，2/2 + 1 = 2，还可以获得2票赞成，如果只剩一台，就无法成为领导者了

------切换过程总结

选择新的主节点、切换主节点这些操作都是哨兵领导者来完成，所以我们根据哨兵领导者的日志，来串一下整个主从切换的流程

#对6081节点主观下线
27733:X 06 Apr 2023 16:20:37.028 # +sdown master mymaster xx.xx.xx.xx 6081
#对6081节点客观下线
27733:X 06 Apr 2023 16:20:37.086 # +odown master mymaster xx.xx.xx.xx 6081 #quorum 2/2
#更新纪元,这个纪元的作用是为了保证redis集群的一致性
27733:X 06 Apr 2023 16:20:37.086 # +new-epoch 32
#尝试对6081故障转移
27733:X 06 Apr 2023 16:20:37.086 # +try-failover master mymaster xx.xx.xx.xx 6081
#选举哨兵领导者
27733:X 06 Apr 2023 16:20:37.089 # +vote-for-leader e42e7bf1b00bd966376a225f95c583026abe3e12 32
27733:X 06 Apr 2023 16:20:37.098 # 67a03474bea5aa6b8e1324383aabfb404288009f voted for e42e7bf1b00bd966376a225f95c583026abe3e12 32
#选举主节点
27733:X 06 Apr 2023 16:20:37.160 # +elected-leader master mymaster xx.xx.xx.xx 6081
#在从节点中挑选新的主节点
27733:X 06 Apr 2023 16:20:37.160 # +failover-state-select-slave master mymaster xx.xx.xx.xx 6081
#将6082作为新的主节点
27733:X 06 Apr 2023 16:20:37.243 # +selected-slave slave xx.xx.xx.xx:6082 xx.xx.xx.xx 6082 @ mymaster xx.xx.xx.xx 6081
#向6082发送slaveof no one命令,命令其成为新的主节点
27733:X 06 Apr 2023 16:20:37.243 * +failover-state-send-slaveof-noone slave xx.xx.xx.xx:6082 xx.xx.xx.xx 6082 @ mymaster xx.xx.xx.xx 6081
#等待6082成为新的主节点
27733:X 06 Apr 2023 16:20:37.333 * +failover-state-wait-promotion slave xx.xx.xx.xx:6082 xx.xx.xx.xx 6082 @ mymaster xx.xx.xx.xx 6081
#6082成为新的主节点
27733:X 06 Apr 2023 16:20:38.069 # +promoted-slave slave xx.xx.xx.xx:6082 xx.xx.xx.xx 6082 @ mymaster xx.xx.xx.xx 6081
#重新配置主从关系
27733:X 06 Apr 2023 16:20:38.069 # +failover-state-reconf-slaves master mymaster xx.xx.xx.xx 6081
#命令6083节点复制新的主节点
27733:X 06 Apr 2023 16:20:38.129 * +slave-reconf-sent slave xx.xx.xx.xx:6083 xx.xx.xx.xx 6083 @ mymaster xx.xx.xx.xx 6081
#6083节点正在重新配置为6082的从节点,但是同步过程尚未完成
27733:X 06 Apr 2023 16:20:39.093 * +slave-reconf-inprog slave xx.xx.xx.xx:6083 xx.xx.xx.xx 6083 @ mymaster xx.xx.xx.xx 6081
#6083节点完成对6082的同步
27733:X 06 Apr 2023 16:20:39.093 * +slave-reconf-done slave xx.xx.xx.xx:6083 xx.xx.xx.xx 6083 @ mymaster xx.xx.xx.xx 6081
#故障转移顺利完成
27733:X 06 Apr 2023 16:20:39.143 # +failover-end master mymaster xx.xx.xx.xx 6081
#向+switch-master频道发布主节点的切换消息
27733:X 06 Apr 2023 16:20:39.143 # +switch-master mymaster xx.xx.xx.xx 6081 xx.xx.xx.xx 6082