Redis基础知识(学习笔记18--主从集群)

一.主从相关的配置

1.1 masterauth

# If the master is password protected (using the "requirepass" configuration
# directive below) it is possible to tell the replica to authenticate before
# starting the replication synchronization process, otherwise the master will
# refuse the replica request.
#
# masterauth <master-password>
#

因为我们要搭建主从集群,且每个主机都有可能会是Master,如果设置验证属性requirepass。一定要每个主机的密码都设置为相同的。此时每个配置文件中都要设置两个完全相同的属性:requirepass与masterauth。其中requirepass用户指定当前主机的访问密码,而masterauth用于指定当前slave访问master时向master提交的访问密码,用于让master验证请求者身份是否合法。

1.2 repl-disable-tcp-nodelay

# Disable TCP_NODELAY on the replica socket after SYNC?
#
# If you select "yes" Redis will use a smaller number of TCP packets and
# less bandwidth to send data to replicas. But this can add a delay for
# the data to appear on the replica side, up to 40 milliseconds with
# Linux kernels using a default configuration.
#
# If you select "no" the delay for data to appear on the replica side will
# be reduced but more bandwidth will be used for replication.
#
# By default we optimize for low latency, but in very high traffic conditions
# or when the master and replicas are many hops away, turning this to "yes" may
# be a good idea.
repl-disable-tcp-nodelay no

该属性用于设置是否禁用TCP特性tcp-nodelay。设置为yes则禁用tcp-nodelay,此时master与slave间的通信会产生延迟,但使用的TCP包数量较少,占用的网络带宽会较小。相反,如果设置为no,则网络延迟会变小,但使用的TCP包数量会较多,相应占用的网络带宽会变大。

知识点补充---tcp-nodelay

为了充分复用网络带宽,TCP总是希望发送尽可能大的数据块。为了达到该目的,TCP中使用了一个名为Nagle的算法。

Nagle算法的原理是,网络在接收到要发送的数据后,并不直接发送,而是等待着数据量足够大(由TCP网络特性决定)时再一次性发送出去。这样,网络上传输的有效数据的比例就等到了大大提升,无效数据的传输极大减少,于是就节省了网络带宽,缓解了网络压力。

 tcp-nodelay 则是TCP协议中Nagle算法的开关。

 1.3 pidfile

# If a pid file is specified, Redis writes it where specified at startup
# and removes it at exit.
#
# When the server runs non daemonized, no pid file is created if none is
# specified in the configuration. When the server is daemonized, the pid file
# is used even if not specified, defaulting to "/var/run/redis.pid".
#
# Creating a pid file is best effort: if Redis is not able to create it
# nothing bad happens, the server will start and run normally.
#
# Note that on modern Linux systems "/run/redis.pid" is more conforming
# and should be used instead.
pidfile /var/run/redis_6379.pid

如果是多实例安装(一台机器上安装多个redis实例),记得要修改这个参数。

当然,另外一些参数配置

端口号(port)、dbfilename、appendfilename、logfile、replica-priority

简单说下 replica-priority

# The replica priority is an integer number published by Redis in the INFO
# output. It is used by Redis Sentinel in order to select a replica to promote【提升;晋升;】
# into a master if the master is no longer working correctly.
#
# A replica with a low priority number is considered better for promotion, so  ##越小优先级越高
# for instance if there are three replicas with priority 10, 100, 25 Sentinel
# will pick the one with priority 10, that is the lowest.
#
# However a special priority of 0 marks the replica as not able to perform the ##特殊的优先级的值为0
# role of master, so a replica with priority of 0 will never be selected by    ##0丧失了称为master的可能性
# Redis Sentinel for promotion.
#
# By default the priority is 100.
replica-priority 100

1.4 个性化的配置依赖参数include

################################## INCLUDES ###################################

# Include one or more other config files here.  This is useful if you
# have a standard template that goes to all Redis servers but also need
# to customize a few per-server settings.  Include files can include
# other files, so use this wisely.
#
# Note that option "include" won't be rewritten by command "CONFIG REWRITE"
# from admin or Redis Sentinel. Since Redis always uses the last processed
# line as value of a configuration directive, you'd better put includes
# at the beginning of this file to avoid overwriting config change at runtime.
#
# If instead you are interested in using includes to override configuration
# options, it is better to use include as the last line.
#
# Included paths may contain wildcards. All files matching the wildcards will
# be included in alphabetical order.
# Note that if an include path contains a wildcards but no files match it when
# the server is started, the include statement will be ignored and no error will
# be emitted.  It is safe, therefore, to include wildcard files from empty
# directories.
#
# include /path/to/local.conf
# include /path/to/other.conf
# include /path/to/fragments/*.conf
#

################################## MODULES #####################################

例如我们想独立出一个配置文件,但是呢,只想修改几个或者少部分参数项,这时候,可以include进基本的配置文件,只把需要修改的参数,重写下即可。

二. 设置主从关系

2.1 查看

先查看下主从关系,查看指令

> info replication

在主节点上执行,

返回值 role 代表当前节点的角色;

connected_slaves的数值代表 从节点 的个数;

如果有slave节点的话,会以slave0、slave1 呈现出具体的slave信息(ip:port:state:offset:lag)。

而在从节点上执行的话,返回值是不一样的:

返回值role 代表集群角色,其他的返回值还有master_ip、master_port、master_link_status、master_last_io_seconds_age、master_sync_in_process、slave_read_only等等。

需要注意的是从节点是不可以执行写命令的,否则报错

(error)READONLY You can't write against a read only replica.

2.2 设置命令

在从节点上执行命令,如下

> slaveof host(主节点ip) port(主节点的端口号)

 只执行上面的命令,如果从节点重启的话,主从关系就会失效,即丢失已设置的主从关系。

2.3. 分级管理

若redis主从集群中的slave较多时,他们的数据同步过程会对master形成较大的性能压力。此时,可以对这些slave进行分级管理。

 设置方式很简单,只需要让低级别slave指定其slaveof的主机为上一级slave即可。不过,上一级slave的状态仍为slave,只不过,其是更上一级的slave。

调整主从关系,不需要关闭已有关系,再重建,而是直接执行 slaveof host port 进行调整即可。

2.4 容灾冷处理

在master/slave的redis集群中,若master出现了宕机怎么办?有两种处理方式,一种是通过手工角色调整,使slave晋升为master的冷处理;一种是使用哨兵模式,实现redis集群的高可用HA,即热处理。

无论master是否宕机,slave都可以通过下面的命令,将自己提升为master。

> slaveof no one

如果其原本就有下一级的slave,那么,其就直接变为了这些slave的真正的master了。而原来的master就会失去了这个原来的slave。

三. 主从复制原理

 3.1 主从复制过程

当一个redis节点(slave)接收到类似slaveof 127.0..1 6379 的指令后直至其可以从master持续复制数据,大体经历了如下几个过程:

(1)保存master地址

当slave接收到slaveof <master_ip> <master_port>指令后,slave会立即将新的master的地址保存下来。

(2)建立连接

slave中维护着一个定时任务,该定时任务会尝试着与该master建立socker连接。

(3)slave发送ping命令

 连接成功后,slave会发送ping命令,进行首次通信。如果slave没有收到master的回复,则slave就会主动断开连接,下次的定时任务会重新尝试连接。

(4)对slave身份验证

master 在接收到slave的ping命令后,并不会立即对其进行回复,而是先对Salve进行身份验证。如果验证不通过,则会发送消息拒绝连接;。验证通过,master 向slave发送连接成功响应。

(5)master持久化

slave在成功接收到master的响应后,slave向master发出数据同步请求。master在接收到数据同步请求后,fork出一个子进程,让子进程以异步方式立即进行数据持久化。

(6)数据发送

持久化完毕后,master再fork出一个子进程,让子进程以异步方式将数据发送给slave。slave会将接收到的数据不断写入到本地的持久化文件中。

在slave数据同步过程中,master的主进程仍在不断地接受着客户端的写操作,且不仅将新的数据写入到master内存,同时也写入到了同步缓存。当master的持久化文件中的数据发送完毕后,master会再将同步缓存中新的数据发送给slave,由slave将其写入到本地持久化文件中。数据同步完成。

(7)slave恢复内存数据

数据同步完毕后,slave就会读取本地持久化文件,将其恢复到本地内存数据,然后就可以对外提供服务了。

(8)持续增量复制

对外服务中master持续接收到写操作,会以增量方式发送给slave,以保证主从数据的一致性。

 流程概况如下

考虑到数据发送过程中,仍由数据进来,补充如下:

3.2 数据同步演变过程

(1)sync 同步

redis 2.8 版本之前,首次通信成功后,slave会向master发送sync数据同步请求,然后master就会将其所有数据全部发送给slave,由slave保存到其本地的持久化文件中。这个过程称为全量复制。

但这里存在一个问题:在全量复制过程中可能会出现网络抖动而导致复制过程中断。当网络恢复后,slave与master重新连接成功,此时slave会重新发送sync请求,然后会从头开始全量复制。

由于全量复制过程非常耗时,所以期间出现网络抖动的概率很高。而中断后的从头开始不仅需要消耗大量的系统资源、网络带宽,而且可能会出现长时间无法完成全量复制的情况。

(2)psync

redis 2.8 版本之后,全量复制采用了psync(Partial Sync,不完全同步)同步策略。当全量复制过程出现由于网络抖动而导致复制过程中断时,当重新连接成功后,复制过程可以“断点续传”。即从断点位置开始继续复制,而不用从头再来。这样大大提升了性能。

为了实现psync,整个系统做了三个大的变化:

A. 复制偏移量

系统为每个需要传送数据进行了编号,该编号从0开始,每个字节一个编号。该编号称为复制偏移量。参与复制的主从节点都会维护该复制偏移量。

可以通过 命令info replication 的返回结果中的 slave_repl_offset (从节点)或 master_repl_offset(主节点 代表已发送出去的数据)值查看。

B.主节点复制ID

当master启动后,就会动态生成一个长度为40位的16进制字符串作为当前master的复制ID,该ID是在进行数据同步时slave识别master使用的。通过 info replication 的master_replid属性可查看到该ID。

特别注意:master redis 重启,动态生成的复制ID就会变化。

C.复制积压缓冲区

当master有连接的slave时,在master中就会创建并维护一个队列backlog,默认大小为1MB,该队列称为复制积压缓冲区。master接收到了写操作,数据不仅会写入到了master主存,写入到了master中为每个slave配置的发送缓存,而且还会写入到复制积压缓冲区。其作用就是用于保存最近操作的数据,以备“断点续传”时做数据补偿,防止数据丢失。

D. psync 同步过程

psync是一个由slave提交的命令,其格式为psync <master_replid> <repl_offset> ,表示当前slave要从指定中的repl_offset+1处开始复制。 repl_offset表示当前slave已经完成复制的数据的offset。该命令保证了“断点续传”的实现。

在第一次开始复制时,slave并不直到master的动态ID,并且一定时从头开始复制,所以其提交的psync命令为PSYNC ? -1。即master_replid 为问号(?),repl_offset为-1。

如果复制过程中断后,slave与master成功连接,则save再次提交psync命令。此时psync命令的repl_offset参数为其前面已经完成复制的数据的偏移量。

其实,并不是slave提交psync命令后就可以立即从master处开始复制,而是需要master给出响应结果后,根据响应结果来执行。master根据slave提交的请求及master自身情况会给出不同的响应结果。响应结果有三种可能:

  • FULLRESYNC <master_replid> <repl_offset>:告知slave当前master的动态ID及可以开始全量复制了,这里的repl_offset一般为0。
  • CONTINUE:告知slave可以按照你提交的repl_offset后面位置开始“续传”了。
  • ERR:告知slave,当前master的版本低于redis 2.8 ,不支持psync,你可以开始全量复制。

 psync过程概况如下

E. psync存在的问题

  • 在psync数据同步过程中,若slave重启,在slave内存中保存的master的动态ID与续传需要的offset都会消失,“断点续传”将无法进行,从而只能进行全量复制,导致资源浪费。
  • 在psync数据同步过程中,master宕机后slave会发生“易主”,从而导致slave需要从新master进行全量复制,形成资源浪费。

(3)psync 同步的改进

Redis 4.0 对psync进行了改进,提出了“同源增量同步”策略。

A. 解决slave重启问题

针对“slave重启时master动态ID丢失问题”,改进后的psync将master的动态ID直接写入到了slave的持久化文件中。

slave重启后直接从本地持久化文件中读取master的动态ID,然后向master提交获取复制偏移量的请求。master会根据提交请求的slave地址,查找到保存在master中的复制偏移量,然后向slave回复FULLRESYNC <master_replid> <repl_offset>,以告知slave其马上要开始发送的位置。然后master开始“断点续传”。

B. 解决slave易主问题

slave易主后需要和新master进行全量复制,本质原因是新master不认识slave提交的psync请求中的“原master的动态ID”。如果slave发送psync <原master_replid> <repl_offset> 命令,新的master能够识别出该slave要从原master复制数据,而自己的数据都是从该master复制来的。那么新master就会明白,其与该slave"师出同门",应该接收其“断点续传”同步请求。

而新master中恰好保存的有“原master的动态ID”。由于改进后的psync中每个slave都在本地保存了当前的master的动态ID,所以当slave晋升为新的master后,其本地仍保存有之前master的动态ID。而这一点也恰恰为解决“slave易主”问题提供了条件。通过master的info replication 中master_replid2 可以查看到。如果尚未发送易主,则该值为40个0。

(4) 无盘操作

Redis 6.0 对同步过程又进行了改进,提出了“无盘全量同步”与“无盘加载”策略,避免了耗时的IO操作。

  • 无盘全量同步:master的主进程fork出的子进程直接将内存中的数据发送给slave,无需经过磁盘。
  • 无盘加载:slave在接收到master发送来的数据后不需要将其写入到磁盘文件,而是直接写入到内存,这样slave就可快速完成数据恢复。

(5) 共享复制积压缓冲区

Redis 7.0 版本对复制积压缓冲区进行了改进,让各个slave的发送缓冲区共享复制积压缓冲区。这使得复制积压缓冲区的作用,除了可以保障数据的安全性外,还作为所有slave的发送缓冲区,充分利用了复制积压缓冲区。

 

学习参阅特别声明

【Redis视频从入门到高级】

【https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】

 

热门相关:大叔在左奶狗在右   重生之大文豪   带着仓库到大明   末日乐园   漫画故事   如意小郎君