薪火相传

我们知道redis的主从复制还有一个常见的架构  ---薪火相传

使用这种结构可以有效减轻master节点的复制数据同步压力

注意这里的6380节点仍然是slave节点

可以理解为一个中间节点,仍然是不可以写只可以读取的

我们只需要使用

slaveof ip port 

这里可能访问节点的时候出现问题,这是在节点变化期间

多次尝试即可

当然我们还可以让其自立门户

slaveof no one

直接当老大

前言

复制的原理和流程

这里复制首先由slave来进行同步

1.首次连接是使用的全量复制

salve本身的数据也会被直接覆盖   主从复制的时候会触发rdb 将rdb发送给从库完成复制的初始化

2.后面就是保持持续通信

每隔10s发送一个心跳包

3.进入平稳,增量复制

后续slave增量同步master的信息

4.从机下线 断点续传

这时候是有一个offset

master会检查backlog的偏移量

会将对应复制的偏移量传送给从机,类似与断点续传

前面我们说到了redis的主从复制

我们知道这里主机可以读写

从机只能读取

如果主机宕机,从机则会无限时间的等待

这样当然是我们不想看到的

所以这里引入了哨兵集群

主要负责监控master节点是否宕机

负责选举出新的master节点

配置哨兵

由于博主的机器原因

这里是在6379节点开启了三个哨兵集群

因为机器内存不够,但是鼓励各位小伙伴使用六台虚拟机来完成任务

首先我们配置master分支的conf文件

这里我们需要和上一篇一样配置对应的访问master节点的密码

架构如下

我们需要配置三个sentinel的配置文件

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir "/myredis"
sentinel monitor mymaster 192.168.111.169 6379 2
sentinel auth-pass mymaster 111111

对应配置即可

注意最后两行的含义

需要配置master的名称 ip 端口 法定票数

这里的法定票数就是多少个哨兵认为master挂了就真的挂了

这里有两个概念

主观下线:一个节点在默认超时时间内(30s)没有感受到master的存在

客观下线:超过法定票数的哨兵都这样认为master挂了

然后使用这样的方式可以成功启动哨兵集群

使用ps -ef来查看对应的哨兵服务是否成功启动

后面我们可以尝试手动断开原来的master节点

我们会发现redis会自动选举新的master节点

对应如何选举的咱们下面慢慢说 

注:原来的master节点即使回归之后,也只能当小弟了,不会出现对应的master冲突

两个小错误

可能刚刚断开连接还没完全恢复,是正常的异常警告

不影响后续的操作

注意这里重新选举之后新的sentinel文件也会进行对应的配置 

对应的redis配置文件也会进行对应的动态更新

对应的从节点会将对应的主节点进行对应的配置

也会进行对应的增量更新

那么选举节点的原理是什么样的呢?

选举兵王

首先我们使用有三个哨兵节点的

三个哨兵节点首先会使用raft算法进行选举一个哨兵之王(leader)

然后由哨兵节点去进行操作对应的redis节点

raft算法

本质上还是一个先到先得的原则

假设现在是abc三个节点

a向bc发生对应的申请

同理b也是发送申请

c也是同理

a先接受到谁的申请就把自己的票投送给谁

投票最多的则作为兵王

选举master

这里我们所有的master的对应的操作是由兵王来操作的

我们按照三个评判标准来进行评价

这三个评判标准的优先级和文章顺序一样

1.根据权限大小

在redis配置文件设置的权限大小

默认是100 可以手动配置

2.偏移量

我们知道每个节点的网络情况不同

slave节点可能复制的量不同

复制量大的优先

3.根据runid

runid根据字典序  小的优先

选举出来之后由leader哨兵来进行对应的先让选出来的slave进行一个

slaveof no one 

在对其他的slave节点进行对应的

slaveof ip port操作

让其他节点成为自己的小弟

注意这里的源master节点也被加在小弟列表中了