Redis---主从复制 & 哨兵
这是一篇对redis主从复制和哨兵的学习笔记！
目录
一、主从复制
从这里开始，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）
大数据从业者之家,一起探索大数据的无限可能！
更多推荐
45
0- 0
已为社区贡献1条内容
所有评论(0)