曾无好事来相访,赖尔高文一起予。这篇文章主要讲述#yyds干货盘点#Redis之主从复制详述相关的知识,希望能为你提供帮助。
1、简介主从复制是Redis分布式的基石,也是Redis高可用的保障。在Redis中,被复制的服务器称为主服务器(Master),对主服务器进行复制的服务器称为从服务器(Slave)。
主从复制的配置非常简单,有三种方式(其中IP-主服务器IP地址/PORT-主服务器Redis服务端口):
2、主从复制的演进Redis的主从复制机制,并不是一开始就像6.x版本一样完善,而是一个版本一个版本迭代而来的。它大体上经过三个版本的迭代:
随着版本的增长,Redis主从复制机制逐渐完善;但是他们的本质都是围绕同步(sync)和命令传播(command propagate)两个操作展开:
2.1 版本2.8以前2.1.1 同步
2.8以前的版本,从服务器对主服务器的同步需要从服务器向主服务器发生sync命令来完成:
2.1.2 命令传播
当同步工作完成之后,主从之间需要通过命令传播来维持数据状态的一致性。
如下图,当前主从服务器之间完成同步工作之后,主服务接收客户端的DEL K6指令后删除了K6,此时从服务器仍然存在K6,主从数据状态并不一致。为了维持主从服务器状态一致,主服务器会将导致自己数据状态发生改变的命令传播到从服务器执行,当从服务器也执行了相同的命令之后,主从服务器之间的数据状态将会保持一致。
2.1.3 缺陷
从上面看不出2.8以前版本的主从复制有什么缺陷,这是因为我们还没有考虑网络波动的情况。了解分布式的兄弟们肯定听说过CAP理论,CAP理论是分布式存储系统的基石,在CAP理论中P(partition网络分区)必然存在,Redis主从复制也不例外。当主从服务器之间出现网络故障,导致一段时间内从服务器与主服务器之间无法通信,当从服务器重新连接上主服务器时,如果主服务器在这段时间内数据状态发生了改变,那么主从服务器之间将出现数据状态不一致。
在Redis 2.8以前的主从复制版本中,解决这种数据状态不一致的方式是通过重新发送sync命令来实现。虽然sync能保证主从服务器数据状态一致,但是很明显sync是一个非常消耗资源的操作。
sync命令执行,主从服务器需要占用的资源:
从上面三点可以看出,sync命令不仅会导致主服务器的响应能力下降,也会导致从服务器在此期间拒绝对外提供服务。
2.2 版本2.8-4.02.2.1 改进点
针对2.8以前的版本,Redis在2.8之后对从服务器重连后的数据状态同步进行了改进。改进的方向是减少全量同步(full resynchronizaztion)的发生,尽可能使用增量同步(partial resynchronization)。在2.8版本之后使用psync命令代替了sync命令来执行同步操作,psync命令同时具备全量同步和增量同步的功能:
2.2.2 psync如何实现
Redis为了实现从服务器断线重连后的增量同步,增加了三个辅助参数:
2.2.2.1 复制偏移量在主服务器和从服务器内都会维护一个复制偏移量
正常同步的情况如下:
通过对比主从服务器之间的复制偏移量是否相等,能够得知主从服务器之间的数据状态是否保持一致。
假设此时A/B正常传播,C从服务器断线,那么将出现如下情况:
【#yyds干货盘点#Redis之主从复制详述】很明显有了复制偏移量之后,从服务器C断线重连后,主服务器只需要发送从服务器缺少的100字节数据即可。但是主服务器又是如何知道从服务器缺少的是那些数据呢?
2.2.2.2 复制积压缓冲区复制积压缓冲区是一个固定长度的队列,默认为1MB大小。当主服务器数据状态发生改变,主服务器将数据同步给从服务器的同时会另存一份到复制积压缓冲区中。
复制积压缓冲区为了能和偏移量进行匹配,它不仅存储了数据内容,还记录了每个字节对应的偏移量:
当从服务器断线重连后,从服务器通过psync命令将自己的复制偏移量(offset)发送给主服务器,主服务器便可通过这个偏移量来判断进行增量传播还是全量同步。
Redis的复制积压缓冲区的大小默认为1MB,如果需要自定义应该如何设置呢?
很明显,我们希望能尽可能的使用增量同步,但是又不希望缓冲区占用过多的内存空间。那么我们可以通过预估Redis从服务断线后重连的时间T,Redis主服务器每秒接收的写命令的内存大小M,来设置复制积压缓冲区的大小S。
S = 2 * M * T
注意这里扩大2倍是为了留有一定的余地,保证绝大部分的断线重连都能采用增量同步。
2.2.2.3 服务器运行 ID看到这里是不是再想上面已经可以实现断线重连的增量同步了,还要运行ID干嘛?其实还有一种情况没考虑,就是当主服务器宕机后,某台从服务器被选举成为新的主服务器,这种情况我们就通过比较运行ID来区分。
2.2.3 完整的psync
完整的psync过程非常的复杂,在2.8-4.0的主从复制版本中已经做到了非常完善。psync命令发送的参数如下:
psync <
runid>
<
offset>
当从服务器没有复制过任何主服务器(并不是主从第一次复制,因为主服务器可能会变化,而是从服务器第一次全量同步),从服务器将会发送:
psync ? -1
一起完整的psync流程如下图:
2.3 版本4.0Redis 2.8-4.0版本仍然有一些改进的空间,当主服务器切换时,是否也能进行增量同步呢?因此Redis 4.0版本针对这个问题做了优化处理,psync升级为psync2.0。
psync2.0 抛弃了服务器运行ID,采用了replid和replid2来代替,其中replid存储的是当前主服务器的运行ID,replid2保存的是上一个主服务器运行ID。
通过replid和replid2我们可以解决主服务器切换时,增量同步的问题:
推荐阅读
- PyTorch教程 层和块
- SpringCloud升级之路2020.0.x版-41. SpringCloudGateway 基本流程讲解
- #yyds干货盘点#技术路线的选择重要但不具有决定性
- #yyds干货盘点# 5. Python 循环的本质就是一段代码懒得重复写
- #yyds干货盘点# web安全day13(简单深透测试流程)
- oeasy教您玩转vim - 70 - # 折叠细节
- SpringMVC接收参数 具体示例#yyds干货盘点#
- JAVA关于列表查询参数校验的问题
- Linux是什么系统(为什么要学习Linux?)