【Redis】Redis 主从复制原理与配置详解：解决单点故障与性能瓶颈的最佳方案

- 主从复制
- - 配置
  - - 建立复制
    - 断开复制
    - 安全性
    - 只读
    - 传输延迟
  - 拓扑
  - - ⼀主⼀从结构
    - 一主多从结构
    - 树形主从结构
  - 原理
  - - 复制过程
    - 数据同步 psync
    - 全量复制
    - 部分复制
    - 实时复制
  - 小结

主从复制

这部分相关操作不需要记忆!!! 后续⼯作中如果⽤到了能查到即可.

重点理解流程和原理.

单点问题：某个服务器程序，只有一个节点（只搞一个物理服务器，来部署这个服务器程序）

可用性问题，如果这个机器挂了，服务就中断了
性能/支持的并发量有限

在分布式系统中，希望使用多个服务器来部署 redis，存在以下几种 redis 的部署方式：

主从模式
主从+哨兵模式
集群模式

Redis 主从模式中，从节点上的数据不允许修改，只允许读取，所以不存在“我修改了从节点的数据，是否把从节点的数据往主节点上同步”的问题。

某个从节点挂了影响不大，但如果主节点挂了呢？

这就有一定影响了，此时只剩下从节点，只能读数据了，如果需要写数据就没得写了。主从模式主要是针对“读操作”进行并发量&可用性的提高，实际业务场景读操作往往比写操作更频繁；而对于“写操作”无论是可用性还是并发量都非常依赖主节点，而主节点又不能搞多个，因为如果你对主节点a和主节点b同时写了那该听谁的呢？

在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他服务器，满⾜故障恢复和负载均衡等需求。Redis 也是如此，它为我们提供了复制的功能，实现了相同数据的多个 Redis 副本。复制功能是⾼可⽤ Redis 的基础，哨兵和集群都是在复制的基础上构建的。本章内容如下：

介绍复制的使⽤⽅式：如何建⽴或断开复制、安全性、只读等。

说明复制可⽀持的拓扑结构，以及每个拓扑结构的适⽤场景。

分析复制的原理，包括：建⽴复制、全量复制、部分复制、⼼跳检测等。

如果同学⽐较少，那么⼀个⽼师既可以进⾏授课，也可以进⾏答疑；但是随着学⽣多了，⼀个⽼师也就应付不过来了. 就需要配⼏个助教⽼师，助教⽼师从授课⽼师这⾥获取知识，协助授课⽼师答疑.

配置

配置 Redis 主从结构，首先需要启动多个 Redis 服务器。正常来说每个 Redis 服务器程序应该在一个单独的主机，这样才是分布式。但是大多数人应该手里只有一个云服务器，我们可以在一个云服务器主机上运行多个 redis-server 进程。此处需要保证多个 redis-server 的端口。

如何指定 redis-server 的端口呢？

可以在启动程序的时候，通过命令行指定端口号。--port 选项
也可以在配置文件设置端口。【推荐】

这里从 35节如何启动多个redis-server 开始看

建立复制

参与复制的 Redis 实例划分为主节点（master）和从节点（slave）。每个从节点只能有⼀个主节点，⽽⼀个主节点可以同时具有多个从节点。复制的数据流是单向的，只能由主节点到从节点。配置复制的⽅式有以下三种（都是关于 slaveof 命令的）：

在配置⽂件中加⼊ slaveof {masterHost} {masterPort} 随 Redis 启动⽣效。【推荐】

这部分看 36节主从复制-配置主从复制(1)

在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效。
直接使⽤ redis 命令：slaveof {masterHost} {masterPort} ⽣效。

接下来，我们将 redis.conf 配置⽂件复制⼀份 redis-slave.conf（如果你想有多个从节点就复制多份，命名时区分一下每个从节点，比如 slave1.conf、slave2.conf 之类的

进入这些配置文件将端口号修改为 6379 之后的，比如 6380 之类的，并且修改其 daemonize 为 yes。

# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes

接下来，默认启动的 redis 作为主 Redis，重新通过命令⾏启动⼀个 Redis 实例作为从 Redis：

# ubuntu
redis-server /etc/redis/redis-slave.conf --port 6380 --slaveof 127.0.0.1 6379

# centos
redis-server /etc/redis-slave.conf --port 6380 --slaveof 127.0.0.1 6379

注意: 修改配置主要是修改从机的配置. 主机配置不变.

通过 netstat -nlpt 确保两个 Redis 均已正确启动。

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:6380          0.0.0.0:*               LISTEN

通过 redis-cli 可以连接主 Redis 实例，通过 redis-cli -p 6380 连接从 Redis。并且观察复制关系。

127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> get hello
"world"

127.0.0.1:6380> get hello
"world"

从运⾏结果中看到复制已经⼯作了，针对主节点 6379 的任何修改都可以同步到从节点 6380 中，复制过程如图所⽰。

Redis 主从节点复制过程

可以通过 info replication 命令查看复制相关状态。

主节点 6379 复制状态信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=100,lag=0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:100
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:100

从节点 6380 复制状态信息

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:170
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2fbd35a8b8401b22eb92ff49ad5e42250b3e7a06
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:170
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:170

断开复制

slaveof 命令不但可以建⽴复制，还可以在从节点执⾏ slaveof no one 来断开与主节点复制关系。例如在 6380 节点上执⾏ slaveof no one 来断开复制。

断开复制主要流程：

断开与主节点复制关系。
从节点晋升为主节点。

从节点断开复制后并不会抛弃原有数据，只是⽆法再获取主节点上的数据变化

通过 slaveof 命令还可以实现切主操作，将当前从节点的数据源切换到另⼀个主节点。执⾏ slaveof {newMasterIp} {newMasterPort} 命令即可。

切主操作主要流程：

断开与旧主节点复制关系。
与新主节点建⽴复制关系。
删除从节点当前所有数据。
从新主节点进⾏复制操作。

通过这种 slaveof 的命令行方式确实修改了主从结构，但这个是临时的，如果重启了 redis 服务器，仍然会按照最初在配置文件中设置的内容建立主从关系

安全性

对于数据⽐较重要的节点，主节点会通过设置 requirepass 参数进⾏密码验证，这时所有的客⼾端访问必须使⽤ auth 命令实⾏校验。从节点与主节点的复制连接是通过⼀个特殊标识的客⼾端来完成，因此需要配置从节点的 masterauth 参数与主节点密码保持⼀致，这样从节点才可以正确地连接到主节点并发起复制流程。

只读

默认情况下，从节点使⽤ slave-read-only=yes 配置为只读模式。由于复制只能从主节点到从节点，对于从节点的任何修改主节点都⽆法感知，修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。

传输延迟

主节点和从节点直接通过网络来传输（TCP）

TCP 内部支持了 nagle 算法（默认开启），开启了，就会增加 TCP 的传输延迟，节省了网络带宽；关闭了，就会减少 TCP 的传输延迟，增加了网络带宽。

主从节点⼀般部署在不同机器上，复制时的⽹络延迟就成为需要考虑的问题，Redis 为我们提供了 repl-disable-tcp-nodelay 参数⽤于控制是否关闭 TCP_NODELAY，默认为 no，即开启 tcpnodelay 功能，说明如下：

当关闭时，主节点产⽣的命令数据⽆论⼤⼩都会及时地发送给从节点，这样主从之间延迟会变⼩，但增加了⽹络带宽的消耗。适⽤于主从之间的⽹络环境良好的场景，如同机房部署。
当开启时，主节点会合并较⼩的 TCP 数据包从⽽节省带宽。默认发送时间间隔取决于 Linux 的内核，⼀般默认为 40 毫秒。这种配置节省了带宽但增⼤主从之间的延迟。适⽤于主从⽹络环境复杂的场景，如跨机房部署。

拓扑

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

⼀主⼀从结构

⼀主⼀从结构是最简单的复制拓扑结构，⽤于主节点出现宕机时从节点提供故障转移⽀持，如图所⽰。当应⽤写命令并发量较⾼且需要持久化时，可以只在从节点上开启 AOF，这样既可以保证数据安全性同时也避免了持久化对主节点的性能⼲扰。但需要注意的是，当主节点关闭持久化功能时，如果主节点宕机要避免⾃动重启操作。

改进方法：当主节点挂了之后，就需要让主节点去从节点这里获取到 AOF 文件，再启动

⼀主⼀从拓扑

主节点即可以写操作也可以读操作，从节点只可以读操作，这样从节点就帮主节点分摊了一些读请求

一主多从结构

⼀主多从结构（星形结构）使得应⽤端可以利⽤多个从节点实现读写分离，如图 5-3 所⽰。对于读⽐重较⼤的场景，可以把读命令负载均衡到不同的从节点上来分担压⼒。同时⼀些耗时的读命令可以指定⼀台专⻔的从节点执⾏，避免破坏整体的稳定性。对于写并发量较⾼的场景，多个从节点会导致主节点写命令的多次发送从⽽加重主节点的负载（对主节点写一次操作就要对从节点发送多次更新）。

⼀主多从拓扑

树形主从结构

树形主从结构（分层结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引⼊复制中间层，可以有效降低住系欸按负载和需要传送给从节点的数据量，如图 6-4 所⽰。数据写⼊节点 A 之后会同步给 B 和 C 节点，B 节点进⼀步把数据同步给 D 和 E 节点。当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰，可以采⽤这种拓扑结构。

存在的问题：到达底下的叶子节点的请求可能很慢

图 5-4 树形拓扑

原理

复制过程

如图所⽰，下⾯详细介绍建⽴复制的完整流程。从图中可以看出复制过程⼤致分为 6 个过程：

主从节点建⽴复制流程图

保存主节点（master）的信息。

开始配置主从同步关系之后，从节点只保存主节点的地址信息（IP、端口），此时建⽴复制流程还没有开始，在从节点 6380 执⾏ info replication 可以看到如下信息：

master_host: 127.0.0.1
master_port: 6379
master_link_status: down

从统计信息可以看出，主节点的 ip 和 port 被保存下来，但是主节点的连接状态（master_link_status）是下线状态。

从节点（slave）内部通过每秒运⾏的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与主节点建立基于 TCP 的⽹络连接。如果从节点⽆法建⽴连接，定时任务会⽆限重试直到连接成功或者⽤⼾停⽌主从复制。
发送 ping 命令。连接建⽴成功之后，从节点通过 ping 命令确认主节点在应⽤层上是否是⼯作良好的。如果 ping 命令的结果 pong 回复超时，从节点会断开 TCP 连接，等待定时任务下次重新建⽴连接。
权限验证。如果主节点设置了 requirepass 参数，则需要密码验证，从节点通过配置 masterauth参数来设置密码。如果验证失败，则从节点的复制将会停⽌。
同步数据集。对于⾸次建⽴复制的场景，主节点会把当前持有的所有数据全部发送给从节点，这步操作基本是耗时最⻓的，所以⼜划分称两种情况：全量同步和部分同步，下⼀节重点介绍。

部分同步也称增量同步

命令持续复制。当从节点复制了主节点的所有数据之后，针对之后的修改命令，主节点会持续的把命令发送给从节点，从节点执⾏修改命令，保证主从数据的⼀致性。

数据同步 psync

Redis 使⽤ psync 命令完成主从数据同步，同步过程分为：全量复制和部分复制。

全量复制：⼀般⽤于初次复制场景，Redis 早期⽀持的复制功能只有全量复制，它会把主节点全部数据⼀次性发送给从节点，当数据量较⼤时，会对主从节点和⽹络造成很⼤的开销。
部分复制：⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景，当从节点再次连上主节点后，如果条件允许，主节点会补发数据给从节点。因为补发的数据远⼩于全量数据，可以有效避免全量复制的过⾼开销。

PSYNC 的语法格式

psync 不需要手动执行，Redis 服务器建立好主从同步关系之后，自动执行 psync。从节点负责执行 psync，从节点从主节点这边拉取数据

PSYNC replicationid offset

如果 replicationid 设为 ? 并且 offset 设为 -1 此时就是在尝试进⾏全量复制.

如果 replicationid offset 设为了具体的数值，则是尝试进⾏部分复制.

replicationid/replid (复制id)

这个相当于主节点的身份标识，描述”数据的来源“

主节点的复制 id。主节点重新启动，或者从节点晋级成主节点，都会⽣成⼀个 replicationid。(同⼀个节点，每次重启，⽣成的 replicationid 也会变化)。

从节点在和主节点建⽴连接之后，就会获取到主节点的 replicationid。

通过 info replication 即可看到 replicationid

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:1da596acecf5a34b4b2aae45bd35be785691ae69
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

关于 master_replid 和 master_replid2

每个节点需要记录两组 master_replid . 这个设定解决的问题场景是这样的:

⽐如当前有两个节点 A 和 B，A 为 master， B 为 slave.

此时 B 就会记录 A 的 master_replid.

如果⽹络出现抖动，B 以为 A 挂了，B ⾃⼰就会成为主节点. 于是 B 给⾃⼰分配了新的 master_replid.

此时就会使⽤ master_replid2 来保存之前 A 的 master_replid.

后续如果⽹络恢复了，B 就可以根据 master_replid2 找回之前的主节点.
后续如果⽹络没有恢复，B 就按照新的 master_replid ⾃成⼀派，继续处理后续的数据.

runid 是每个节点都不相同的，replid 则是具有主从关系的节点都是相同的

runid 主要是用在支撑实现 redis 哨兵这个功能，也就是和主从复制这部分关系不大

replid 主要是在主从复制这部分发挥作用

offset (偏移量)

描述“数据的复制进度”

参与复制的主从节点都会维护⾃⾝复制偏移量。主节点（master）在处理完写⼊命令后，会把命令的字节⻓度做累加记录，统计信息在 info replication 中的 master_repl_offset 指标中。

相当于从节点和主节点之间，同步数据的进度

127.0.0.1:6379> info replication
# Replication
role:master
...
master_repl_offset:1055130

从节点（slave）每秒钟上报⾃⾝的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量，统计指标如下：

127.0.0.1:6379> info replication
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1055214,lag=1
...

lag 表示延迟，因为主从节点是通过网络通信，就可能存在延迟。如果是在同一个主机上，通过环回IP 就不太会出现延迟

从节点在接受到主节点发送的命令后，也会累加记录⾃⾝的偏移量。统计信息在 info replication 中的slave_repl_offset 指标中：

127.0.0.1:6380> info replication
# Replication
role:slave
...
slave_repl_offset:1055214

复制偏移量的维护如图所⽰。通过对⽐主从节点的复制偏移量，可以判断主从节点数据是否⼀致。

replicationid 和 offset 共同描述劜一个“数据集合“

如果发现两个机器的 replicationid 和 offset 一样，就可以认为两个 redis 机器上存储的数据完全一样

复制偏移量维护

这个偏移量，就相当于 “学习进度”.

⽐如⽼师这边准备了 10 个课件的内容. 助教要想给同学答疑，也就需要学习完这 10 个课件的内容. 这个偏移量就是当前助教学到了第⼏个课件了.

replid + offset 共同标识了⼀个 “数据集”.

如果两个节点，他们的 replid 和 offset 都相同，则这两个节点上持有的数据，就⼀定相同.

psync 运⾏流程

从节点发送 psync 命令给主节点，replid 和 offset 的默认值分别是 ? 和 -1。（保持默认值就是获取全量数据）
主节点根据 psync 参数和⾃⾝数据情况决定响应结果：

如果回复 +FULLRESYNC replid offset，则从节点需要进⾏全量复制流程。
如果回复 +CONTINEU，从节点进⾏部分复制流程。

主节点会自行判定，看当前是否方便给部分数据，不方便就直接给全量

如果回复 -ERR，说明 Redis 主节点版本过低，不⽀持 psync 命令。从节点可以使⽤ sync 命令进⾏全量复制。

psync ⼀般不需要⼿动执⾏。Redis 会在主从复制模式下⾃动调⽤执⾏.
sync 会阻塞 redis server 处理其他请求。psync 则不会.

全量复制

全量复制是 Redis 最早⽀持的复制⽅式，也是主从第⼀次建⽴复制时必须经历的阶段。全量复制的运⾏流程如图所⽰。

全量复制流程

从节点发送 psync 命令给主节点进⾏数据同步，由于是第⼀次进⾏复制，从节点没有主节点的运⾏ ID 和复制偏移量，所以发送 psync ? -1。
主节点根据命令，解析出要进⾏全量复制，回复 +FULLRESYNC 响应。
从节点接收主节点的运⾏信息进⾏保存。
主节点执⾏ bgsave 进⾏ RDB ⽂件的持久化。（这里是新建一个 rdb 文件）

也可以用 AOF，但 RDB 是二进制格式，比较节省空间，因为是通过网络传输，如果过大就会占用过多网络带宽，也就更慢了

为什么不用旧的 rdb 文件？

旧的 rdb 文件可能和当前新数据存在差异，这是 rdb 的缺点

主节点发送 RDB ⽂件给从节点，从节点保存 RDB 数据到本地硬盘。
主节点将从⽣成 RDB 到接收完成期间执⾏的写命令，写⼊缓冲区中，等从节点保存完 RDB ⽂件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 rdb 的⼆进制格式追加写⼊到收到的 rdb ⽂件中，保持主从⼀致性。

第4步创建 rdb 文件，第5步传输 rdb 文件，两步都是很耗时的，此时主节点很可能还会继续接收心的修改操作，而这些修改的数据也要同步给从节点。当从节点收完了主节点发来的 rdb 文件之后，主节点就会把这些新修改的操作通过缓冲区发送给从节点

从节点清空⾃⾝原有旧数据。
从节点加载 RDB ⽂件得到与主节点⼀致的数据。
如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进⾏ bgrewrite 操作，得到最近的 AOF ⽂件。

通过分析全量复制的所有流程，我们会发现全量复制是⼀件⾼成本的操作：主节点 bgsave 的时间，RDB 在⽹络传输的时间，从节点清空旧数据的时间，从节点加载 RDB 的时间等。所以⼀般应该尽可能避免对已经有⼤量数据集的 Redis 进⾏全量复制。

有磁盘复制 vs 无磁盘复制(diskless)

默认情况下，进⾏全量复制需要主节点⽣成 RDB ⽂件到主节点的磁盘中，再把磁盘上的 RDB ⽂件通过发送给从节点。

Redis 从 2.8.18 版本开始⽀持无磁盘复制。主节点在执⾏ RDB ⽣成流程时，不会⽣成 RDB ⽂件到磁盘中了，而是直接把⽣成的 RDB 数据通过⽹络发送给从节点。这样就节省了⼀系列的写硬盘和读硬盘的操作开销。

即使引入无硬盘模式，但整个操作仍然比较重量，比较耗时的。网络传输是没法省的，相比网络传输，读写硬盘是小数目。

部分复制

部分复制主要是 Redis 针对全量复制的过⾼开销做出的⼀种优化措施，使⽤ psync replicationId offset 命令实现。当从节点正在复制主节点时，如果出现⽹络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区存在数据则直接发送给从节点，这样就可以保持主从节点复制的⼀致性。补发的这部分数据⼀般远远⼩于全量数据，所以开销很⼩。整体流程如图所⽰。

图部分复制过程

当主从节点之间出现⽹络中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并终端复制连接。
主从连接中断期间主节点依然响应命令，但这些复制命令都因⽹络中断⽆法及时发送给从节点，所以暂时将这些命令滞留在复制积压缓冲区中。
当主从节点⽹络恢复后，从节点再次连上主节点。
从节点将之前保存的 replicationId 和复制偏移量offset 作为 psync 的参数发送给主节点，请求进⾏部分复制。
主节点接到 psync 请求后，进⾏必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据，并响应 +CONTINUE 给从节点。

主节点会看这个进度是否在当前的复制积压缓冲区之内，如果确实在就可以进行部分复制。如果确实当前从节点的进度已经超出积压缓冲区的范围就进行全量复制。

因为复制积压缓冲区会记录最近一段时间修改的数据，但总量有限，随着时间推移就会把旧的数据逐渐删掉

。主节点将需要从节点同步的数据发送给从节点，最终完成⼀致性。

如果某个课件传输失败了，助教可以单独要这个缺失的课件

复制积压缓冲区

就是一个内存中的简单的队列

复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列，默认⼤⼩为 1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写⼊复制积压缓冲区，如图所⽰。

由于缓冲区本质上是先进先出的定⻓队列，所以能实现保存最近已复制数据的功能，⽤于部分复制和复制命令丢失的数据补救。复制缓冲区相关统计信息可以通过主节点的 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]。