Redis（六）主从模式与哨兵机制

文章目录

一、主从模式

配置一主二从集群

开启三个linux，并安装redis
在这里插入图片描述
info replication查询当前库的信息

replicaof 192.168.31.238 6379

在这里插入图片描述 重启redis服务，重新查看信息
主机：
从机信息

测试主机写，从机读
主机可读可写，但是多用于写

在这里插入图片描述 从机可读不可写

当主机断电宕机后，默认情况下从机的角色不会发生变化 ，
集群中只是失去了写操作，
当主机恢复以后，又会连接上从机恢复原状。

主机失联
在这里插入图片描述
从机依然可以获取数据

两个从机的角色并没有发生改变

默认情况下，主机故障后，不会出现新的主机，有两种方式可以产生新的主机：

我们可以使用slaveof no one让自己变成主机！（暂时的）

另一个从机还是属于之前的主机

如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机！其他的节点就可以手动连接到最新的主节点（手动）！如果这个时候老大修复了，那么久重新连接！
哨兵机制

二、哨兵机制

哨兵是Redis的一种工作模式，以监控节点状态及执行故障转移为主要工作，
哨兵总是以固定的频率去发现节点、故障检测，然后在检测到主节点故障时以安全的方式执行故障转移，确保集群的高可用性。
哨兵是一个独立的进程，作为进程，它会独立运行。
其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

在这里插入图片描述
哨兵的作用：

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
总结下来：哨兵的职责就是：监控、选主、通知

哨兵模式演示：

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

服务类型	是否为主服务器	IP地址	端口
Redis	是	192.168.31.238	6379
Redis	否	192.168.31.130	6379
Redis	否	192.168.31.128	6379
Sentinel		192.168.31.238	26379
Sentinel		192.168.31.130	26379
Sentinel		192.168.31.128	26379

Redis安装目录下有一个sentinel.conf文件，copy一份进行修改
在这里插入图片描述
cp一份
查看是否cp成功find | grep sentinel.conf

修改redis.conf

#bind 127.0.0.1 -::1  注释掉 # 使得Redis服务器可以跨网络访问
protected-mode no  关闭保护模式
指定主服务器，注意：有关replicaof的配置只是配置从服务器，主服务器不需要配置
replicaof 192.168.31.238 6379

修改sentinel.conf

protected-mode no  禁止保护模式
daemonize yes   开启后台模式
# 配置监听的主服务器，这里sentinel monitor代表监控，
# mymaster代表服务器的名称，
# 192.168.31.238代表监控的主服务器，
# 主服务器的端口6379，
# 2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进failover操作。
sentinel monitor mymaster 192.168.31.238 6379 2
port 26379   端口号
# sentinel auth-pass <master-name> <password> # 如果主机设置密码

启动

[root@heng bin]# redis-server /etc/redis.conf
[root@heng bin]# redis-sentinel /etc/sentinel.conf

查看两个服务是否启动成功
在这里插入图片描述
注意启动的顺序。首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。查看主服务器信息
查看从服务器信息

模拟主服务器宕机redis-cli shutdown

可以看到从机192.168.31.128变成了主机

在这里插入图片描述

重启192.168.31.238（原主机）发现其变成了从机

哨兵如何监控节点

哨兵会周期性地给所有主从节点发送PING命令，当主从节点收到PING命令后，会发送一个响应命令给哨兵，这样就可以判断它们是否正常运作。
在这里插入图片描述

「主观下线」与[客观下线]

如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令，哨兵就会将它们标记为「主观下线」。这个「规定的时间」是配置项 down-after-milliseconds 参数设定的，单位是毫秒。
因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。
为了减少误判的情况，哨兵在部署的时候不会只部署一个节点，而是用多个节点部署成哨兵集群(最少需要三台机器来部署哨兵集群)，通过多个哨兵节点一起判断，就可以就可以避免单个哨兵因为自身网络状况不好，而误判主节点下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
在这里插入图片描述

 down-after-milliseconds
 指定哨兵在监控Redis服务时，当Redis服务在一个默认毫秒数内都无法回答时，单个哨兵认为的主观下线时间，默认为30000（30秒）

在这里插入图片描述
当一个哨兵判断主节点为「主观下线」后，就会向其他哨兵发起命令

SENTINEL is-master-down-by-addr <ip> <port> <current-epoch> <runid>

，其他哨兵收到这个命令后，就会根据自身和主节点的网络状况，做出赞成投票或者拒绝投票的响应。

当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后，这时主节点就会被该哨兵标记为「客观下线」。
在这里插入图片描述 quorum 配置的是 2，那么一个哨兵需要 2 张赞成票，就可以标记主节点为“客观下线”了。这 2 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。

哨兵判断完主节点客观下线后，哨兵就要开始在多个「从节点」中，选出一个从节点来做新主节点。

之所以针对「主节点」设计「主观下线」和「客观下线」两个状态，是因为有可能「主节点」其实并没有故障，可能只是因为主节点的系统压力比较大或者网络发送了拥塞，导致主节点没有在规定时间内响应哨兵的 PING 命令。

哨兵如何选新主节点

把网络状态不好的从节点给过滤掉。首先把已经下线的从节点过滤掉，然后把以往网络连接状态不好的从节点也给过滤掉。
根据从节点的优先级来进行排序，优先级越小排名越靠前
可以通过redis.conf设置节点的优先级
如果优先级相等，选择复制进度靠前的从节点
如果两个从节点优先级和复制进度都一样，比较两个从节点的 ID 号，ID 号小的从节点胜出。
在选举出从节点后，哨兵向被选中的从节点发送SLAVEOF no one 命令，让这个从节点编程新主节点。
在发送 SLAVEOF no one 命令之后，哨兵 Leader 会以每秒一次的频率向被升级的从节点发送 INFO 命令（没进行故障转移之前，INFO 命令的频率是每 10 秒一次），并观察命令回复中的角色信息。当被升级节点的角色信息从原来的 slave 变为 master 时，哨兵 Leader 就知道被选中的从节点已经顺利升级为主节点了。

由哪个哨兵进行转移

需要在哨兵集群中选出一个 leeder，让 Leader 来执行主从切换。
选举 Leader 的过程其实是一个投票的过程，在投票开始前，肯定得有个「候选者」.
哪个哨兵节点判断主节点为「客观下线」，这个哨兵节点就是候选者，所谓的候选者就是想当 Leader 的哨兵。
候选者会向其他哨兵发送命令，表明希望成为 Leader 来执行主从切换，并让所有其他哨兵对它进行投票。
每个哨兵只有一次投票机会，如果用完后就不能参与投票了，可以投给自己或投给别人，但是只有候选者才能把票投给自己。
那么在投票过程中，任何一个「候选者」，要满足两个条件：

第一，拿到半数以上的赞成票;
第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
每位候选者都会先给自己投一票，然后向其他哨兵发起投票请求。如果投票者先收到「候选者 A」的投票请求，就会先投票给它，如果投票者用完投票机会后，收到「候选者 B」的投票请求后，就会拒绝投票。这时，候选者 A 先满足了上面的那两个条件，所以「候选者 A」就会被选举为 Leader。

如果哨兵集群中只有 2 个哨兵节点，此时如果一个哨兵想要成功成为 Leader，必须获得 2 票，而不是 1 票。
所以，如果哨兵集群中有个哨兵挂掉了，那么就只剩一个哨兵了，如果这个哨兵想要成为 Leader，这时票数就没办法达到 2 票，就无法成功成为 Leader，这时是无法进行主从节点切换的。

注意：quorum 的值建议设置为哨兵个数的二分之一加1，例如 3 个哨兵就设置 2，5 个哨兵设置为 3，而且哨兵节点的数量应该是奇数。

如何通知客户端新主节点的信息?

通过 Redis 的发布者/订阅者机制来实现
当哨兵把新主节点选择出来后，客户端就会看到下面的 switch-master 事件，这个事件表示主节点已经切换了，新主节点的 IP 地址和端口信息已经有了。这个时候，客户端就可以用这里面的新主节点地址和端口进行通信了。

switch-master <master-name> <master-old-ip> <master-old-port> <master-new-ip> <master-new-port>

查看日志：可以看到主库的地址发生了改变
在这里插入图片描述

 哨兵集群是如何组成的?
 在主从集群中，主节点上有一个名为__sentinel__:hello的频道，不同哨兵就是通过它来相互发现，实现互相通信的。

主节点：
在这里插入图片描述
从节点：

哨兵 A 把自己的 IP 地址和端口的信息发布到__sentinel__:hello 频道上，哨兵 B 和 C 订阅了该频道。那么此时，哨兵 B 和 C 就可以从这个频道直接获取哨兵 A 的 IP 地址和端口号。

哨兵集群会对「从节点」的运行状态进行监控，那哨兵集群如何知道「从节点」的信息?
主节点知道所有「从节点」的信息，所以哨兵会向主节点发送 INFO 命令来获取所有「从节点」的信息。