一、主从复制概念

在分布式系统中涉及到一个非常关键的问题：单点问题

如果某个服务器程序只有一个节点（只弄一个物理服务器，来部署这个服务器程序）那么就会出现以下问题：

1. 可用性问题，如果这个机器挂了，意味着服务就中断了
2. 性能问题，一个节点的并发量是非常有限的。

所以就引入了分布式系统，在分布式系统中，往往希望有多个服务器来部署redis服务，从而构成一个redis集群，此时就可以让这个集群给整个分布式系统中其他的服务，提供更稳定、更高效的数据存储功能。

使用多个服务器来部署redis服务，有如下几种方式：

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

本章主要讲述主从模式：

在若干个redis节点中，有的是主节点有的是从节点。

假设有三个物理服务器（称为三个节点）此时就可以把其中的一个节点作为主节点，另外两个作为从节点。

主从模式中，在主节点上保存一堆数据，引入从节点之后，就是要把主节点上面的数据复制出来，然后放到从节点中，后续，主节点这边对于数据有任何修改，都会把这样的修改给同步到从节点上。从节点上的数据要跟随主节点变化，从节点的数据和主节点保持一致。

二、主从模式运行原理

主从模式一般一个主节点有多个从节点，当客户端发来读的请求时，就可以从上述节点中随机挑一个节点，给这个客户端读取数据的服务，一般都是挑选从节点给客服端，当客户端发来写的请求时，只有主节点可以进行写，所以会分配主节点给客户端。

如果写节点已经分配给客户端了，又有客户端发来读或写的请求，那么这个客户端就得等待，因为进行写操作的时候，不允许其他客户端访问，只能等写操作执行完毕以后才能进行读写操作，保证数据的一致性。

为什么说主从模式就提高了性能呢？

因为从节点中的数据和主节点中的数据是一致的，所以后续有客服端来读取数据，就可以从上述节点中随机挑一个节点，给这个客户端提供读取数据的服务。一个节点可以同时被多个客户端同时读取数据。引入了更多的计算机资源，自然就能够支持的并发量就大大提高了，性能也提高了。

这是怎么保证可用性问题呢？

因为每个节点都对应着一个服务器，且这些服务器一般分布在不同的机房中，如果其中一个服务器挂了其他的服务大概率还是保持运行的，那么剩下的服务器也还可以继续服务，

2.1主从复制的演示：

首先将redis的配置文件复制两份到我们的常用的文件夹中：

cp /etc/redis/redis.conf ./slave1.conf
cp /etc/redis/redis.conf ./slave2.conf

然后修改配置文件的端口号，分别修改为6380，6381：

sudo vim ./slave1.conf
port 6380

sudo vim ./slave2.conf
prot 6381

原因是在同一台机器上，运行多个服务器需要不同的端口号来区分它们是哪个进程

配置文件中的daemonize改为yes：

daemonize yes

原因是为了保证redis服务器在后台运行

将保护模式protected-mode修改为no：

protected-mode no

然后启动redis服务器：

redis-server ./slave1.conf

redis-server ./slave2.conf

启动以后，查看redis服务器是否启动成功：

ps -aux | grep redis-server

加上原来就启动了一个端口号为6379的redis服务，此时有三个redis服务在运行，这就算启动成功了

现在它们还没有构成主从结构，此时我们需要将他们设置成主从结构：

配置复制的⽅式有以下三种：

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

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

3. 直接使⽤ redis 命令：slaveof {masterHost} {masterPort} ⽣效

我们采用第一种方式，让端口号为6379的服务器为主节点，其他为从节点，所以修改slave1.conf ，slave2.conf 配置文件：

slaveof 127.0.0.1 6379

注意：配置文件中没有slaveof，需要我们自己加.

改完以后需要我们重启服务器：

可以先使用kill -9 命令关掉这两个进程，然后再启动：

#查看进程pid
ps -aux |grep redis-server
#kill掉这两个进程
kill -9 进程pid

补充：如果我们使用service redis-server start这种方式启动redis服务器的话，就必须使用service redis-server stop来进行停止。

因为使用这种方式，会有另外的一个进程（守护进程）来专门监控指定的服务器进程的运行状态，当监控的服务器挂了的时候，会立刻将该服务器进程进行重启。保证服务器的稳定性和高可用。

当从节点启动的时候会和主节点建立tcp连接，主节点相当于服务器，从节点相当于客户端。

现在在主节点添加一条记录：

可以在从节点也可以读取到数据。这就算主从复制配置成功了。

2.2查看主从结构信息：

info replication

• role ： 节点名称，是主节点还是从节点
• connected_slaves : 表示连接该节点的从节点个数
• state ： 表示连接状态
• offset ： 表示从节点和主节点之间同步数据的进度
• lag ： 表示连接延迟
• master_replid ：主节点的身份编号
• master_replid2 ：表示主节点挂了以后，重新分配的主节点的身份编号
• master_repl_offset ：当offset与master_repl_offset相同时，就表示从节点的数据已经与主节点一致，同步完成

从节点断开主节点的指令：

slaveof no one

从节点断开主从关系以后，他就不再属于其他节点了，里面已经存在的数据也不会抛弃，但是主节点修改数据以后，该从节点就无法在自动同步数据了。

1. 主从复制默认是从节点复制主节点的数据，从节点不能修改。

如果我们将从节点的配置文件中的slave-read-only 改为no,此时就可以修改从节点中的数据了，但这样就会导致从节点中的数据和主节点不一致，这样客户端读到的数据就会存在很大偏差，这不是我们希望看到的，所以一般都是保持yes的。

2. 为了提高主节点和从节点的数据同步速度，可以将配置文件中的repl-disable-tcp-nodely设置为no

因为在tcp传输过程中，如果开启了nagle算法会增加tcp传输的延迟，该算法就是把几个较小的包合并成一个包然后传输，减少包的数量，这样可以减少网络带宽，但会增加传输延迟。

2.3AOF文件对主从关系的影响

如果写数据的请求太多，此时就会给主节点造成一些压力，这时可以通过关闭主节点的AOF，只在从节点上开启AOF。这样可以减轻主节点的负担。

但是这种设定存在一个严重缺陷，如果主节点挂了，那么将不能够让他进行重启。因为如果让他重启了，此时没有AOF文件，就会丢失数据，进一步的主从同步会把从节点的数据也给删了。

解决方法：主节点挂了，让主节点获取到从节点的AOF文件，然后再重启。

2.4主从节点建立复制流程图

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

开始配置主从同步关系之后，从节点只保存主节点的地址信息，此时建⽴复制流程还没有开始，在从节点 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. 命令持续复制。当从节点复制了主节点的所有数据之后，针对之后的修改命令，主节点会持续的把命令发送给从节点，从节点执⾏修改命令，保证主从数据的⼀致性。

三、主从复制的拓扑结构

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

3.1 一主一从结构

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

3.2 一主多从结构

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

3.3 树形主从结构

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

四、数据同步psync

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

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

PSYNC 的语法格式 ：

psync replicationid offset

• replicationid : 是主节点启动的时候生成的复制id，每次启动id都不同，从节点和主节点建立了复制关系以后，就会从主节点这里获取到这个id
• offset：表示偏移量。主节点会把存入的命令字节数进行累加，当从节点的偏移量和主节点的偏移量相同时，就表示从节点已经同步数据完毕。

从节点每秒钟都会把自身的偏移量告诉主节点。replicationid 和offset共同描述了一个数据集合。如果发现两个机器中replicationid和offset一样，就可以认为这两个redis机器上存储的数据就是完全一样的。

当我们使用psync来同步时，psync replicationid -1就表示获取全量数据。psync replicationid 正整数则表示从当前偏移量位置来进行获取数据。

psync执行流程：

• 从节点发送 psync 命令给主节点，replid 和 offset 的默认值分别是 ? 和 -1.

• 主节点根据 psync 参数和⾃⾝数据情况决定响应结果：

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

• 如果回复 +CONTINEU，从节点进⾏部分复制流程。

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

补充：

1. psync ⼀般不需要⼿动执⾏. Redis 会在主从复制模式下⾃动调⽤执⾏.

2. sync 会阻塞 redis server 处理其他请求. psync 则不会.

关于 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 ⾃成⼀派, 继续处理后续的数据.

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
...

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

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

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

补充：replid + offset 共同标识了⼀个 “数据集”，如果两个节点, 他们的 replid 和 offset 都相同, 则这两个节点上持有的数据, 就⼀定相同

4.1全量复制

全量复制流程:

1. 从节点发送 psync 命令给主节点进⾏数据同步，由于是第⼀次进⾏复制，从节点没有主节点的运⾏ ID 和复制偏移量，所以发送 psync ? -1。

2. 主节点根据命令，解析出要进⾏全量复制，回复 +FULLRESYNC 响应。

3. 从节点接收主节点的运⾏信息进⾏保存。

4. 主节点执⾏ bgsave 进⾏ RDB ⽂件的持久化。

5. 主节点发送 RDB ⽂件给从节点，从节点保存 RDB 数据到本地硬盘。

6. 主节点将从⽣成 RDB 到接收完成期间执⾏的写命令，写⼊缓冲区中，等从节点保存完 RDB ⽂件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 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 数据通过⽹络发送给从节点. 这样就节省了⼀系列的写硬盘和读硬盘的操作开销.

4.2部分复制

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

1. 当主从节点之间出现⽹络中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并终止复制连接。

2. 主从连接中断期间主节点依然响应命令，但这些复制命令都因⽹络中断⽆法及时发送给从节点，所以暂时将这些命令滞留在复制积压缓冲区中。

3. 当主从节点⽹络恢复后，从节点再次连上主节点。

4. 从节点将之前保存的 replicationId 和 复制偏移量offset作为 psync 的参数发送给主节点，请求进⾏部分复制。(主节点如果发现replicationid不一样，那就会进行全量复制，否则再使用offset进行部分复制)

5. 主节点接到 psync 请求后，进⾏必要的验证。随后根据 offset 去复制积压缓冲区查找合适的数据，并响应 +CONTINUE 给从节点。

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

注意：全量复制以后，主节点数据改动时，也会进行部分复制。

复制积压缓冲区

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

复制积压缓冲区是一个先进先出的定长队列，其本质上是一个环形队列，用于保存最近已复制的数据。这个缓冲区在主节点与从节点之间的数据复制过程中发挥着重要作用，特别是在部分复制和复制命令丢失的数据补救时。通过将写入命令暂存于复制积压缓冲区，即使在网络连接中断或者从节点未能及时响应的情况下，主节点也能够保持这些写入命令的备份。一旦连接恢复，主节点会逐步将复制积压缓冲区中的数据发送给从节点，从而确保主从节点之间的数据一致性。

复制积压缓冲区相关的统计信息可以通过主节点的 info replication 命令获取。其中，repl_backlog_active 表示复制缓冲区是否启用，repl_backlog_size 表示缓冲区的最大长度，repl_backlog_first_byte_offset 表示缓冲区的起始偏移量，而 repl_backlog_histlen 表示已保存数据的有效长度。通过这些统计指标，我们可以计算出复制积压缓冲区内的可用偏移量范围，即从 repl_backlog_first_byte_offset 开始，到 repl_backlog_first_byte_offset + repl_backlog_histlen 结束，这个范围内的值相当于环形队列中的数组下标

复制缓冲区相关统计信息可以通过主节点的 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 // 已保存数据的有效⻓度

4.3实时复制

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

另外, 这样的⻓连接, 需要通过⼼跳包的⽅式来维护连接状态. (这⾥的⼼跳是指应⽤层⾃⼰实现的⼼跳, ⽽不是 TCP ⾃带的⼼跳).

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

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

五、主从复制总结

主从复制特点：

1. redis通过复制功能实现主节点的多个副本
2. 主节点用来写，从节点用来读，这样可以降低主节点的访问压力
3. 主从复制支持多种拓扑结构，可以在适当的场景选择合适的拓扑结构
4. 复制分为全量复制，部分复制，实时复制
5. 主从节点之间通过心跳机制保证主从节点连接正常和数据一致性、

主从复制配置的过程：

1. 主节点配置不需要改动
2. 从节点在配置文件中加入slaveof 主节点ip 主节点端口号 的形式即可。

主从复制的缺点：

1. 从节点多了，复制数据的延时非常明显
2. 主节点挂了，从节点不会升级为主节点，只能通过人工干预的方式恢复。