目录
一、主从复制
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
我们在开始前必要包管三台主机网络互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的四大功能
- 故障转移
- 假如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推举算法
新王登基
- 旧主拜服
- 老master回来也得怂（成为新master的从机）
2.2.5 哨兵的个数最好是多个
- 哨兵节点的数目应为多个，哨兵本身应该集群，包管高可用
- 哨兵节点的数目应该是奇数个
- 各个哨兵节点的配置应该一致
- 假如哨兵节点部署在Docker等容器里，要注意端口的正确映射
- 哨兵集群+主从复制，并不能包管数据零丢失：s当master挂了的时间，写业务是进不来的，哨兵要先发现，再推举leader，再到推选出新的master，这是必要一些时间的（5-10 s），在这段时间内肯定是要丢数据的。这也是哨兵的缺陷，所以也就在后面引出来了集群（cluster）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
