redis：复制

ShineLee / 2023-08-31 / 原文

学习自：《Redis开发与运维》PDF 351页

0、简写

m：master，主节点

s：slave，从节点

1、前言

在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他机器，满足故障恢复、负载均衡等需求。

Redis也提供了复制功能，实现了相同数据的多个Redis副本。复制功能是高可用Redis的基础，Redis的哨兵和集群都是在复制的基础上实现高可用的。

2、配置

1）建立复制

参与复制的Redis实例划分为主节点（master）、从节点（slave）。默认情况下都是m。

每个s只能有一个m，而一个m却可以同时具有多个s。

数据复制只能从m到s，即只有m才具有写的能力。

复制的配置方式（3种）：

Redis启动前：conf文件中加入replicaof {masterHost} {masterPort}，Redis启动时生效；
Redis启动时：命令redis-cli后加入选项--replicaof {masterHost} {masterPort}；
Redis启动后：使用命令replicaof {masterHost} {masterPort}

测试

两台机器，IP分别为：

192.168.10.20（主节点）
192.168.10.11

其中要把192.168.10.11变为从节点，就要在它的conf文件中添加一项：

replicaof 192.168.10.20 6397

之后先后启动m和s，此时主从复制就建立成功了。

测试时，在m上进行set操作：

192.168.10.20:6379> set hello 2023-8-30
OK

此时，这个set的值会自动复制到s上：

192.168.10.11:6379> get hello
"2023-8-30"

关于节点的复制状态信息可以通过info replication查看：

192.168.10.20:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.10.11,port=6379,state=online,offset=506,lag=1
master_failover_state:no-failover
master_replid:12e06f0f4564fbd8c62d1116c3d6ccc04d8ebf77
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:506
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:506

192.168.10.11:6379> info replication
# Replication
role:slave
master_host:192.168.10.20
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_read_repl_offset:506
slave_repl_offset:506
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:12e06f0f4564fbd8c62d1116c3d6ccc04d8ebf77
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:506
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:506

2）断开复制

实现：replicaof no one

流程：

断开与m的复制关系；
s晋升为m；

s断开后不会删除已获得的数据，只是无法再从主节点上获取数据。

也可以切换为另一个m：replicaof newIP newPort

此时s会删除已有的数据后再对新的m进行复制操作。

3）安全性

节点可以通过设置requirepass来设置密码验证，所有登录该节点的连接都要通过-a或者auth进行验证。

如果m节点设置了requirepass，那么s节点还要设置masterauth并与其保持一致，否则无法正确连接。

4）只读

通过配置replica-read-only=yes配置s的只读模式。

该项尽量不要修改，因为主从复制是从m到s，对s的任何修改是无法被m感知到的，从而造成主从不一致的问题。

5）传输延迟

m、s节点一般部署在不同的机器上，复制时的网络延迟就成为了需要考虑的问题。

Redis提供了repl-disable-tcp-nodelay用于控制是否关闭TCP_NODELAY，默认关闭：

关闭，m产生的命令无论大小都会及时发给s，这样主从延迟会变小，但是增加了网络带宽消耗。适用于主从网络环境良好的场景，如同机架、同机房部署。低延迟
开启，m会合并较小的TCP数据包从而节省带宽。默认的发送时间间隔取决于Linux内核，一般默认40ms。这种配置节省了带宽，但是增大了主从间的延迟。适用于网络环境复制或带宽紧张的场景，如跨机房部署。高容灾性

6）拓扑

Redis的复制拓扑结构可以支持单层、多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从。

①一主一从

使用：写命令并发高

最简单的拓扑结构，当m出问题时，s提供故障转移支持。

当写命令并发高且需要持久化时，可以只在s上开启AOF，这样可以既保证数据安全性又能避免持久化对m的性能干扰。

但是当m关闭持久化功能时，如果m脱机要避免自动重启操作。因为m没有开启持久化，因此自动重启后数据清空，此时s复制m会导致s也被清空，从而丧失了持久化的意义。安全的做法是在s上执行slaveof no one断开与m的复制关系，再重启s从而避免这一问题。

②一主多从（星形拓扑）

适用于：读命令并发高

这种结构下，应用端可以用多个s节点来实现读写分离。

对于读占比较大的情况，可以把读命令发到s来为m分担压力。

常用于一些比较耗时的读命令：keys、sort等，可以在一台s上执行，防止慢查询对m的阻塞从而影响线上服务的稳定性。

对于写并发较高的场景，多个s会导致m节点的写命令多次发送从而造成过度的网络带宽消耗，增加了m的负载，影响了服务稳定性。

③树状主从

树状主从使得s不但可以复制m，也可以作为其他s的m节点继续向下层复制。

通过引入复制中间层，可以有效降低m负载和需要传给s的数据量。

3、原理

1）复制过程

replicaof 127.0.0.1 6379

在s执行replicaof之后，复制过程开始运作，具体流程如下图：

整个复制过程分为6部分：

①保存m信息

执行replicaof之后s值保存了m的地址信息便直接返回，这时复制流程还没开始，在s上执行指令info replication之后可以看到如下信息：

master_host:127.0.0.1
master_port:6379
master_link_status:down

前两项是m的ip和port，master_link_status是m的连接状态，此时是down、下线状态。

执行slaveof之后Redis会打印如下日志：

SLAVE OF 127.0.0.1:6379 enabled (user request from 'id=65 addr=127.0.0.1:58090
fd=5 name= age=11 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=
32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

据此，运维人员就能定位发送slaveof的C端，方便追踪和发现问题。

②主从建立socket连接

s内部通过每秒运行的定时任务维护复制相关的逻辑，当定时任务发现存在新的m时，会尝试与它建立网络连接

s会建立一个Socket套接字，上图中，s就建立了一个端口为24555的Socket，专门用于接收m发送的复制命令。连接成功后打印如下日志：

* Connecting to MASTER 127.0.0.1:6379
* MASTER <-> SLAVE sync started

如果s无法建立连接，定时任务会无限重试直到连接成功或执行replicaof no one取消。

在失败时，可以在s的info replication中查看指标master_link_down_sinc_seconds，它会记录与m连接失败的系统时间。同时日志中也会出现如下内容：

# Error condition on socket for SYNC: {socket_error_reason}

③发送ping命令

连接建立成功后，s发送ping请求首次通信，ping的目的是：

检测m与s间的socket是否可用
检测s当前是否可以接受处理命令

如果发送ping之后，s没收到m的pong回复或者超时，比如网络超时或者m阻塞，此时s会断开复制连接，下次定时任务会发起重连。

当s发送的ping命令成功返回，Redis会打印如下日志，并继续后续的复制流程：

Master replied to PING, replication can continue...

④权限认证

如果m配置了requirepass，那么s必须配置masterauth保证与m有相同的密码才能通过验证。

⑤同步数据集

主从复制连接正常通信后，对于首次建立的连接，m会把所有数据全部发给s，此为耗时最长的步骤。

同步分为：全量同步RDB和增量同步AOF，具体可见redis：AOF与RDB

⑥命令持续复制

当m把当前数据同步给了s之后，就完成了复制的建立流程。之后m会持续的把写命令发送给s，保证主从数据一致性。

2）数据同步

主从同步需要有三个组件支持：

①主从各自的复制偏移量

②m的复制积压缓冲区

③m的运行id

①复制偏移量

参与复制的主从节点都会维护自身的复制偏移量。m在处理完写命令之后，会把命令的字节长度做累加记录，统计信息在info replication中的master_repl_offset指标中。

s节点在收到m的命令后，也会累加记录了自身的偏移量。统计在info replication的slave_repl_offset中。

复制偏移量的具体维护如下图所示：

通过对比主从节点的复制偏移量，可以判断二者是否一致。

可以通过m的统计信息，计算出master_repl_offset - slave_repl_offset的字节数，判断主从节点间复制差异量，如果差异量过大，说明可能发生了网络延迟、命令阻塞。

②复制积压缓冲区

复制积压缓冲区是保存在m上的一个长度固定的队列，默认大小1MB，当m与s相连，并且响应写命令时，除了把该命令发给s，还会将之写入复制积压缓冲区。

缓冲区的本质是先进先出的定长队列，所以可以实现保存最近已复制数据的功能，用于补救部分复制和复制命令丢失的数据。

复制缓冲区的相关信息保存于m的info replication中：

127.0.0.1:6379> info replication
# Replication
role:master
...
repl_backlog_active:1 // 开启复制缓冲区
repl_backlog_size:1048576 // 缓冲区最大长度
repl_backlog_first_byte_offset:7479 // 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen:1048576 // 已保存数据的有效长度。

可以计算出复制缓冲区内的偏移量范围：

[repl_backlog_first_byte_offset,repl_backlog_first_byte_offset+repl_backlog_histlen]

③m的运行id

每个节点启动（重启会改变ID）后都会动态分配一个40b的十六进制字符串作为运行ID。运行ID的主要作用是唯一识别Redis节点。一个s节点可以通过保存的m运行ID识别自己当前复制的是哪个m。在用ip+port的方式识别m时，如果m重启变更了整体数据集（RDB/AOF文件），此时s基于偏移量复制将是不安全的，也因此当运行了ID变化之后将做全量复制，当前节点的ID可以在info server中查看：

127.0.0.1:6379> info server
# Server
redis_version:3.0.7
...
run_id:545f7c76183d0798a327591395b030000ee6def9

重启Redis会使节点的运行ID发生变化。

# redis-cli -p 6379 info server | grep run_id
run_id:545f7c76183d0798a327591395b030000ee6def9
# redis-cli -p shutdown
# redis-server redis-6379.conf
# redis-cli -p 6379 info server | grep run_id
run_id:2b2ec5f49f752f35c2b2da4d05775b5b3aaa57ca

如何保证重启时运行ID不会发生变化？

可以用redis-cli debug reload命令重新加载RDB并保证run_id不变，从而避免不必要的全量复制。

但是debug reload会阻塞当前节点主线程，阻塞期间会生成本地RDB快照、清空数据之后再加载RDB文件。对于大数据量m和无法容忍阻塞的场景要谨慎使用。

④psync命令

s使用psync命令完成部分复制、全量复制。

用法：psync {runId} {offset}

选项：

runId：所复制的m的id，默认为空
offset：当前s保存的复制偏移量，如果是第一次参与复制则默认值为-1

运行流程：

1）s发送psync命令给m，根据runId识别m，根据offset判断复制偏移量

2）m根据psync参数与自身情况决定如何响应：

+FULLRESYNC {runId} {offset}，s将触发全量复制；
+CONTINUE，s将触发部分复制；
+ERR，说明无法识别psync命令，可能是版本原因，也可能是psync命令有问题

3）全量复制

全量复制是Redis最早支持的复制方式，也是主从第一次建立复制时必须经历的阶段。

触发全量复制的命令是sync与psync，其中sync只适用于2.8以下的版本，psync适用于2.8及以上的版本：

全量复制的具体流程为：

1）s发送psync命令，由于是第一次复制，所以s没有m的id和复制偏移量，所以真正发送的指令是psync -1；

2）m根据psync -1判断出是全量复制，回复+FULLRESYNC；

3）s收到m的响应，记录下run_id与offset，此时还会打印日志：

Partial resynchronization not possible (no cached master)
Full resync from master: 92d1cb14ff7ba97816216f7beb839efe036775b2:216789

4）m执行bgsave，保存RDB到本地，关于bgsave见redis：AOF与RDB中的bgsave一节。

此时m上出现与bgsave相关的日志：

M * Full resync requested by slave 127.0.0.1:6380
M * Starting BGSAVE for SYNC with target: disk
C * Background saving started by pid 32618
C * RDB: 0 MB of memory used by copy-on-write
M * Background saving terminated with success

Redis 3.0之后，输出的日志开头会有M、S、C标识：

M：该行为m节点日志
S：该行为s节点日志
C：子进程日志

5）m发送RDB文件给s，s将之保存在本地并直接作为s的数据文件，当RDB接收完毕后，s会打印如下日志，其中记录了m发送的数据量：

16:24:03.057 * MASTER <-> SLAVE sync: receiving 24777842 bytes from master

对于数据量较大的m，比如RDB>6GB，此时传输文件会非常耗时。可以通过细致分析Full resync和MASTER↔SLAVE这两行日志的时间来计算出RDB从创建到传输完毕的消耗时间。如果总时间超过了repl-timeout，那么s将放弃接收RDB文件并清理已经下载的临时文件，导致全量复制失败，此时s会打印如下日志：

M 27 May 12:10:31.169 # Timeout receiving bulk data from MASTER... If the problem
persists try to set the 'repl-timeout' parameter in redis.conf to a larger value

针对数据量较大的节点，可以调高repl-timeout（默认是60）防止出现全量同步超时。

默认值为60，是6GB文件在千兆网卡理论带宽（100MB/s）下传输完毕的时间。