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

本文主要是介绍【Redis】Redis 主从复制原理与配置详解：解决单点故障与性能瓶颈的最佳方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

---

主从复制

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

重点理解流程和原理.

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

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

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

1. 主从模式
2. 主从+哨兵模式
3. 集群模式

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

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

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

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

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

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

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

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

配置

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

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

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

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

建立复制

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

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

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

2. 在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效。

3. 直接使⽤ 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 命令查看复制相关状态。

1. 主节点 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

2. 从节点 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 来断开复制。

断开复制主要流程：

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

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

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

切主操作主要流程：

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

通过这种 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 个过程：

主从节点建⽴复制流程图

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

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

master_host: 127.0.0.1
master_port: 6379
master_link_status: down

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

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

部分同步也称增量同步

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

数据同步 psync

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

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

PSYNC 的语法格式

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

PSYNC replicationid offset

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

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

1. 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 主要是在主从复制这部分发挥作用

2. 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 运⾏流程

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

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

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

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

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

全量复制

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

全量复制流程

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

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

为什么不用旧的 rdb 文件？

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

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

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

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

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

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

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

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

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

部分复制

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

图部分复制过程

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

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

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

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

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

复制积压缓冲区

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

复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列，默认⼤⼩为 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]。

这个相当于⼀个基于数组实现的环形队列. 上述区间中的值就是 “数组下标” .

如果当前从节点需要的数据， 已经超出了主节点的积压缓冲区的范围， 则⽆法进⾏部分复制， 只能全量复制了.

实时复制

主从节点在建⽴复制连接后，主节点会把⾃⼰收到的 修改操作 ，通过 tcp ⻓连接的⽅式， 源源不断的传输给从节点，从节点就会根据这些请求来同时修改⾃⾝的数据，从⽽保持和主节点数据的⼀致性.

另外，这样的⻓连接，需要通过心跳包的⽅式来维护连接状态（可用状态）。(这⾥的心跳是指应⽤层⾃⼰实现的心跳，而不是 TCP ⾃带的心跳)

1. 主从节点彼此都有⼼跳检测机制，各⾃模拟成对⽅的客⼾端进⾏通信。
2. 主节点默认每隔 10 秒对从节点发送 ping 命令，判断从节点的存活性和连接状态。
3. 从节点默认每隔 1 秒向主节点发送 replconf ack {offset} 命令，给主节点上报⾃⾝当前的复制偏移量offset。

如果主节点发现从节点通信延迟超过 repl-timeout 配置的值（默认 60 秒），则判定从节点下线，断开复制客⼾端连接。从节点恢复连接后，⼼跳机制继续进⾏。

从节点和主节点直接断开连接有两种情况：

1. 从节点主动和主节点断开连接，通过 slaveof no one。此时从节点自动晋升成主节点
2. 主节点挂了。此时从节点不会自动晋升成主节点，需要人工干预（或者引入哨兵）

主节点无法重启的原因：

1. 多个 redis server 共用了同一个 aof 文件
2. 这个文件被从节点启动之后，会被替换成一个 root 用户的文件，就会导致主节点无法正常打开

解决方法：把多个 redis 服务器的生成的文件也区分开。更靠谱的是直接把多个 redis 服务器的工作目录区分开（修改配置文件中的 dir 选项）

步骤：

1. 停止之前的 redis 服务器
2. 删除执勤啊工作目录下已经生成的 aof 文件，或者也可以通过 chown 命令修改 aof 文件所属的用户
3. 给从节点创建出新的目录，用来作为从节点的工作目录，并且修改从节点的配置文件，设定为新的目录作为工作目录
4. 启动 redis 服务器

小结

主从复制解决的问题:

单点问题.

1. 单个 redis 节点，可⽤性不⾼.
2. 单个 redis 节点，性能有限.

主从复制的特点:

1. Redis 通过复制功能实现主节点的多个副本。
2. 主节点⽤来写，从节点⽤来读。这样做可以降低主节点的访问压⼒。
3. 复制⽀持多种拓扑结构，可以在适当的场景选择合适的拓扑结构。
4. 复制分为全量复制，部分复制和实时复制。
5. 主从节点之间通过⼼跳机制保证主从节点通信正常和数据⼀致性。

主从复制配置的过程:

1. 主节点配置不需要改动。
2. 从节点在配置⽂件中加⼊ slaveof 主节点ip 主节点端⼝ 的形式即可。

主从复制的缺点:

1. 从机多了，复制数据的延时⾮常明显。
2. 主机挂了，从机不会升级成主机，只能通过⼈⼯⼲预的⽅式恢复。（针对这个问题，就引入了哨兵来解决了）

这篇关于【Redis】Redis 主从复制原理与配置详解：解决单点故障与性能瓶颈的最佳方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---