Redis---主从复制 & 哨兵

目录

一、主从复制

1、什么是主从复制呢？

2、案例演示 

2.1  配置文件  

2.2   一主二仆

2.2.1 相关题目：

2.3  薪火相传  &  反客为主

3、复制原理和工作流程

3.1、slave启动，同步清初

3.2  首次连接，全量复制

3.3  心跳持续，保持通信（和TCP的心跳数据包很像）

 3.4  进入平稳，增量复制

3.5  从机下线，重连续传

4、主从复制的缺点

二、哨兵

2.1  案例演示：

2.1.1  配置

 2.2.2  主机下线后的场景

2.2.3  哨兵的运行流程

 2.2.4  master选举算法

2.2.5  哨兵的个数最好是多个

---

一、主从复制

从这里开始，Redis就从单机走向了多台机器，为了高可用的特性，redis引入了复制、哨兵、集群，而复制又是哨兵和集群的基础

1、什么是主从复制呢？

• 主从复制

  • mmaster以写为主，slave以读为主
  • 当master数据变化时，自动将新的数据异步同步到其他slave数据库

优点：

• 读写分离     （如果读写都是只有一个数据库的话，redis的压力也太大了）

• down机恢复

• 数据备份

• 水平扩容支撑高并发

​

 怎么玩呢？

1、配主不配从

 2、配置权限

• master如果配置了 requirepass 参数，需要密码登录
• slave 需要配置 masterauth来设置检验密码，否则的话master会拒绝slave的访问请求

3、基本命令

2、案例演示 

配置一个master，两个slave

• 3台虚拟机，拷贝redis.conf文件

 我们在开始前需要保证三台主机网络互ping通且注意防火墙配置

2.1  配置文件  

 配置从机：

2.2   一主二仆

先master后两台slave启动

 我们也可以查看主机和从机的日志，能够看到从机连接上了主机的

查看主机日志：

查看从机日志：

 当然，我们也可也用info  replication 命令来查看

2.2.1 相关题目：

1、从机可以进行写操作吗？

不能，从机只是主机的备份，只能读，不能写。主机是可读可写的

2、slave是从头开始复制还是从切入点开始复制？

 首次一锅端（刚连入会把主机的数据全部跟上），后续跟随，master写一个，slave跟一个

3、主机shutdown之后，从机会不会上位？

 4、主机先down了，等重启之后，从属关系还在吗？

青山依旧在（通过配置文件写死），如果是通过命令进行修改的，从属关系就没了

写进配置文件是持久稳定版，只用slaveof 命令是临时的

2.3  薪火相传  &  反客为主

薪火相传：

• 上一个slave可以是下一个slave的master，slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻主master的写压力
• 中途变更转向：会清除之前的数据，重新建立拷贝最新的
• slaveof  新主库IP 新主库端口

反客为主：

• slaveof  no  one  使当前数据库停止与其他数据库的同步，转成主数据库

3、复制原理和工作流程

3.1、slave启动，同步清初

slave启动成功连上master后，会发送一个sync命令，

slave首次全新连接master，一次完全同步（全部复制）将会自动执行，并且是覆盖掉slave原来的数据

3.2  首次连接，全量复制

• master节点收到sync命令后会在后台开始保存快照（即RDB持久化，主从复制会触发RDB），同时收集所有接收到的用于修改数据集命令缓存起来，master节点执行RDB持久化后，master将rdb快照文件和缓存的命令发送到所有slave，以完成一次完全同步
• 而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中，从而完成复制初始化

3.3  心跳持续，保持通信（和TCP的心跳数据包很像）

master发出PING包的周期，默认是10秒

 3.4  进入平稳，增量复制

• master 继续将新的所有收集到的修改命令自动一次传给slave，完成同步

3.5  从机下线，重连续传

• master 会检查backlog里面的offset，master和slave都会保存一个复制的offset怀有一个masterId
• offset 是保存在backlog 中的。master只会把已经复制的offset后面的数据赋值给slave，类似断电续传

4、主从复制的缺点

1、复制延时，信号衰减

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，

尤其是在高并发的条件下，会有很多个从机的存在，延时就更长了。

2、Master挂了怎么办？（等寄吗？）

挂了的话，从机只能原地待命，相当于整个服务器都处于瘫痪的状态。

我们这时候就需要一种高可用的机制：在剩下的slave中选择一位Master出来，（这也就有了后来的哨兵和集群）

二、哨兵

为什么要引入哨兵呢？

引入哨兵其实是为了解决主从复制的痛点：上面我们也说了，当主从复制的主机down之后，整个服务器相当于都瘫痪了（这和高可用的理念违背了），从机只能在那里憨乎乎的等待，我们能不能加一个监控的东西，来监控主机和从机，一旦主机down了，就会通过某种算法（投票），推选出一位新的主机，增强redis的容灾性呢？

引入的监控装置就是今天的主角：哨兵

 redis的四大功能

• 主从监控
  • 监控主从redis库运行是否正常
• 消息通知
  • 哨兵可以将故障转移的结果发送到客户端

• 故障转移
  • 如果master异常，则会进行主从切换，将其中一个slave作为新master
• 配置中心
  • 客户端通过连接哨兵来获得当前Redis服务的主节点地址

2.1  案例演示：

2.1.1  配置

架构配置：

3个哨兵加上一主二从

• 3个哨兵
  • 要有多个哨兵（防止哨兵挂了，还有就是防止因网络抖动而导致的误判），奇数个哨兵（方便投票）
  • 自动监控和维护集群，不存放数据，只是监控
• 1主2从
  • 用于数据读取和存放

 文件配置：

哨兵的配置和普通的redis配置用到的文件不一样，哨兵用到的文件是sentienl.conf

 我们来解释一下quornum：

quorum：确认客观下线的最少的哨兵数量，具体是什么意思呢？

我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

配置sentienl文件：

哨兵在运行的时候需要的配置文件不是redis.conf，而是sentienl文件，（这个文件比conf的文件要小的多），我们需要配置他，方便进行操作，观察现象。

 2.2.2  主机下线后的场景

我们先将主机和两台从机启动起来，进行一下操作，然后再验证一下主从复制是否正常，如果正常之后，我们再启动三个哨兵，我们再来验证一下主从复制。（这些只是基本操作hhh，肯定不会有问题的），我们这里最关心的还是主机挂掉的情况

我们可以自己关闭6379服务器，模拟master挂了

两台从机数据是否正常？

我们在从机上get一下k1，观察一下现象：

 这是怎么回事呢？我们待会儿再去读一次看看

 所以我们可以知道：两台从机的数据不会丢失，（只是内部会进行一些网络重连的延迟），

• 两台从机的数据不会丢失
• 会从其他两台从机选出一个新的master
• 挂掉的master重连回来，直接变成新master的从机

• 本文中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf会在运行中进行动态更改
• 在 master_redis.conf 切换中，会自动多一行slaveof的配置,sentinal的监控对象也会发生改变

2.2.3  哨兵的运行流程

SDOWN主观下线

• SDOWN 是单个sentinel 自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件

• sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度

ODOWN客观下线

• ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机

选举出领导者哨兵

先选出哨兵中的leader（兵王），然后由leader去选举出新的master

• 当主节点被判断客观下线以后，各个哨兵节点会进行协商，县选举出一个领导者哨兵节点并由该领导者节点进行failover（故障迁移）

• Raft算法 选出领导者节点（先到先得）

 2.2.4  master选举算法

新王登基

• 某个slave 备选成为新 master

• 群臣俯首
  • 一朝天子一朝臣，重新认老大

• 旧主拜服
  • 老master回来也得怂（成为新master的从机）

2.2.5  哨兵的个数最好是多个

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数个
• 各个哨兵节点的配置应该一致
• 如果哨兵节点部署在Docker等容器里，要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据零丢失：s当master挂了的时候，写业务是进不来的，哨兵要先发现，再选举leader，再到推选出新的master，这是需要一些时间的（5-10 s），在这段时间内肯定是要丢数据的。这也是哨兵的缺陷，所以也就在后面引出来了集群（cluster）