一、主从复制

从这里开始，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）

淘先锋技术网

Redis---主从复制 & 哨兵