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）
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。