redis优化系列Redis主从原理主从常用配置

少年击剑更吹箫,剑气箫心一例消。这篇文章主要讲述redis优化系列Redis主从原理主从常用配置相关的知识,希望能为你提供帮助。
一、主从复制原理主从复制过程大体可以分为3个阶段:连接建立阶段(即准备阶段)、数据同步阶段、命令传播阶段。
在从节点执行 slaveof 命令后,复制过程便开始运作,下面图示大概可以看到,从图中可以看出复制过程大致分为6个过程

redis优化系列Redis主从原理主从常用配置

文章图片

主从配置之后的日志记录也可以看出这个流程(看主redis或从redis日志都可以):
vi` `/var/log/redis/redis``.log

redis优化系列Redis主从原理主从常用配置

文章图片

1)保存主节点(master)信息:
执行 slaveof 后 Redis 会打印如下日志:
redis优化系列Redis主从原理主从常用配置

文章图片

2)从节点(slave)底层内部通过每秒运行的定时任务维护复制相关逻辑,当定时任务发现存在新的主节点后,会尝试与该节点建立网络连接
从节点与主节点建立网络连接示例图:
redis优化系列Redis主从原理主从常用配置

文章图片

从节点会建立一个 socket 套接字,从节点建立了一个端口为51234的套接字,专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志:
redis优化系列Redis主从原理主从常用配置

文章图片

如果从节点无法建立连接,定时任务会无限重试直到连接成功或者手动执行 slaveof no one 取消复制(断开主从)
注:对一个从redis节点服务器执行命令 slaveof no one 将使得这个从redis节点服务器关闭复制功能,并从 从redis节点服务器转变回主redis节点服务器,原来同步所得的数据集不会被丢弃。
关于连接失败,可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标,它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志,方便发现问题:
# Error condition on socket for SYNC: socket_error_reason
3)发送 ping 命令
连接建立成功后从节点发送 ping 请求进行首次通信,ping 请求主要目的如下:

①、检测主从之间网络套接字是否可用。
②、检测主节点当前是否可接受处理命令。
③、如果发送 ping 命令后,从节点没有收到主节点的 pong 回复或者超时,比如网络超时或者主节点正在阻塞无法响应命令,从节点会断开复制连接,下次定时任务会发起重连。
redis优化系列Redis主从原理主从常用配置

文章图片

redis优化系列Redis主从原理主从常用配置

文章图片

从节点发送的 ping 命令成功返回,Redis 打印如下日志,并继续后续复制流程:
redis优化系列Redis主从原理主从常用配置

文章图片

4)权限验证。如果主节点设置了 requirepass 参数,则需要密码验证,从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证;如果验证失败复制将终止,从节点重新发起复制流程。
5)同步数据集。主从复制连接正常通信后,对于首次建立复制的场景,主节点会把持有的数据全部发送给从节点,这部分操作是耗时最长的步骤。


6)命令持续复制。当主节点把当前的数据同步给从节点后,便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点,保证主从数据一致性。
redis优化系列Redis主从原理主从常用配置

文章图片

二、全量复制和部分复制 2.1 相关概念
全量复制:用于初次复制或其它无法进行部分复制的情况,将主节点中的所有数据都发送给从节点,是一个非常重型的操作,当数据量较大时,会对主从节点和网络造成很大的开销
部分复制:用于处理在主从复制中因网络闪断等原因造成的数据丢失场景,当从节点再次连上主节点后,(如果条件允许,后面会说到具体那些条件需要被满足),主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据,可以有效避免全量复制的过高开销,需要注意的是,如果网络中断时间过长,造成主节点没有能够完整地保存中断期间执行的写命令,则无法进行部分复制,仍使用全量复制
复制偏移量:参与复制的主从节点都会维护自身复制偏移量。主节点(master)在处理完写入命令后,会把命令的字节长度做累加记录,统计信息在 info replication 中的 master_repl_offset 指标中:
提醒:记得进入redis客户端执行该命令
#在从节点的redis中执行以下命令``redis-cli``info replication

截图如下:
redis优化系列Redis主从原理主从常用配置

文章图片

从节点(slave)每秒钟上报自身的复制偏移量给主节点,因此主节点也会保存从节点的复制偏移量,统计指标如下:
再次提醒:记得进入redis客户端执行 info replication 命令
#在主节点的redis中执行以下命令``redis-cli``info replication

截图如下:
redis优化系列Redis主从原理主从常用配置

文章图片

从节点在接收到主节点发送的命令后,也会累加记录自身的偏移量。统计信息在 info replication 中的 slave_repl_offset 中
复制积压缓冲区:复制积压缓冲区是保存在主节点上的一个固定长度的队列,默认大小为1MB(可以调整大小,具体调整多大看各自需求业务来调整),当主节点有连接的从节点(slave)时被创建,这时主节点(master)响应写命令时,不但会把命令发送给从节点,还会写入复制积压缓冲区。
在命令传播阶段(也可以说是 同步数据阶段),主节点除了将写命令发送给从节点,还会发送一份给复制积压缓冲区,作为写命令的备份;除了存储写命令,复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量(offset) 。由于复制积压缓冲区定长而且先进先出,所以它保存的是主节点最近执行的写命令;时间较早的写命令会被挤出缓冲区。
redis优化系列Redis主从原理主从常用配置

文章图片

2.2 Redis全量复制的过程如下图所示:
redis优化系列Redis主从原理主从常用配置

文章图片

如上图所示:
1、Redis 内部会发出一个同步命令,刚开始是 Psync 命令,Psync ? -1表示要求 master 主机同步数据
2、主机会向从机发送 runid 和 offset,因为 slave 并没有对应的 offset,所以是全量复制
3、从机 slave 会保存 主机 master 的基本信息 save masterInfo
4、主节点收到全量复制的命令后,执行 bgsave 命令(异步执行),在后台生成RDB文件(快照文件),并使用一个缓冲区(称为复制缓冲区)记录从现在开始执行的所有写命令
5、主机发送 RDB 文件给从机
6、主机发送缓冲区数据到从机
7、刷新旧的数据,从节点在载入主节点的数据之前要先将老数据清除
8、加载 RDB 文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。
全量复制开销,主要有以下几项:
1、bgsave 时间
2、RDB 文件网络传输时间
3、从节点清空数据的时间
4、从节点加载 RDB 的时间
注:生成一个几GB 十几GB的RDB快照文件 大概是需要2-5分钟的样子
2.3 部分复制(又称 增量复制)
部分复制是 Redis 2.8 以后出现的,之所以要加入部分复制,是因为全量复制会产生很多问题,比如像上面的时间开销大、无法隔离等问题, Redis 希望能够在 master 出现抖动(相当于断开连接)的时候,可以有一些机制将复制的损失降低到最低。
部分复制的过程如下图所示:
redis优化系列Redis主从原理主从常用配置

文章图片

如上图所示:
1、如果网络抖动(连接断开 connection lost)
2、主机 master 还是会写 replbackbuffer(复制缓冲区)
【redis优化系列Redis主从原理主从常用配置】3、从机 slave 会继续尝试连接主机
4、从机 slave 会把自己当前 runid 和偏移量传输给主机 master,并且执行 pysnc 命令同步
5、如果 master 发现从节点的偏移量是在缓冲区的范围内,就会返回 continue(在指的是继续复制的意思) 命令,如果从节点的偏移量不在缓冲区的范围之内,就不会进行部分复制操作了,这样就意味着它会执行全量复制,所以我们要尽量避免这种情况的发生。
6、同步了 offset 的部分数据,所以部分复制的基础就是偏移量 offset
正常情况下redis是如何决定是全量复制还是部分复制?
从节点将offset(偏移量)发送给主节点后,主节点根据offset(偏移量)和缓冲区大小决定能否执行部分复制;
如果offset偏移量之后的数据,仍然都在复制积压缓冲区里,则执行部分复制;
如果offset偏移量之后的数据已不在复制积压缓冲区中(数据已被挤出),则执行全量复制;
缓冲区大小调节:
由于缓冲区长度固定且有限,因此可以备份的写命令也有限,当主从节点offset的差距过大超过缓冲区长度时,将无法执行部分复制,只能执行全量复制。反过来说,为了提高网络中断时部分复制执行的概率,可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size)来设置;例如如果网络中断的平均时间是60s,而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB,则复制积压缓冲区的平均需求为6MB,保险起见,可以设置为12MB,来保证绝大多数断线情况都可以使用部分复制。
服务器运行ID(runid):
每个Redis节点(无论主从),在启动时都会自动生成一个随机ID(每次启动都不一样),由40个随机的十六进制字符组成;runid用来唯一识别一个Redis节点。 通过info server命令,可以查看节点的runid:

redis优化系列Redis主从原理主从常用配置

文章图片

主从节点初次复制时,主节点将自己的runid发送给从节点,从节点将这个runid保存起来;当断线重连时,从节点会将这个runid发送给主节点;主节点根据runid判断能否进行部分复制:
如果从节点保存的runid与主节点现在的runid相同,说明主从节点之前同步过,主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)
如果从节点保存的runid与主节点现在的runid不同,说明从节点在断线前同步的Redis节点并不是当前的主节点,只能进行全量复制。
三、主从复制的常用相关配置1、从redis节点配置:
①、slaveof < masterip> < masterport>
slave实例需要配置该项,指向master的(ip, port)
②、masterauth < master-password>
如果master实例启用了密码保护,则该配置项需填master的启动密码,若master未启用密码,该配置项需要注释掉
③、slave-serve-stale-data
指定slave与master连接中断时的动作。默认为yes,表明slave会继续应答来自client的请求,但这些数据可能已经过期(因为连接中断导致无法从master同步)。若配置为no,则slave除正常应答" INFO" 和" SLAVEOF" 命令外,其余来自客户端的请求命令均会得到" SYNC with master in progress" 的应答,直到该slave与master的连接重建成功或该slave被提升为master
④、slave-read-only
指定slave是否只读,默认为yes。若配置为no,这表示slave是可写的,但写的内容在主从同步完成后会被删掉
⑤、repl-disable-tcp-nodelay
指定向slave同步数据时,是否禁用socket的NO_DELAY选项。若配置为yes,则禁用NO_DELAY,则TCP协议栈会合并小包统一发送,这样可以减少主从节点间的包数量并节省带宽,但会增加数据同步到slave的时间。若配置为no,表明启用NO_DELAY,则TCP协议栈不会延迟小包的发送时机,这样数据同步的延时会减少,但需要更大的带宽。通常情况下,应该配置为no以降低同步延时,但在主从节点间网络负载已经很高的情况下,可以配置为yes
注:主从节点进行数据传输是基于tcp协议进行传输的
⑥、slave-priority
指定slave的优先级。在不只1个slave存在的部署环境下,当master宕机时,Redis Sentinel会将priority值最小的slave提升为master。需要注意的是,若该配置项为0,则对应的slave永远不会被Redis Sentinel自动提升为master

    推荐阅读