本章内容

主要作用

Redis主从同步作用主要有以下几点：

• 数据冗余：通过主从同步实现数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点继续提供服务，实现故障的快速恢复。
• 负载均衡：在主从同步基础上，配合读写分离，由主节点提供写服务，由从节点提供读服务，分担服务器负载。在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。注意：Redis读写分离并不是完全实时同步，从节点中的数据可能会存在一定的延迟，对于实时性要求高的场景需要访问主节点。

实现原理

Redis主从服务器刚建立连接时，进行全量复制；全量复制结束后，进行增量复制。从节点在任何时候都可以发起全量复制。

Redis主从同步主要有两种：全量同步、增量同步。

全量同步

当新的从节点加入集群时，第一次主从同步为全量同步。

处理流程

Redis全量同步主要分为三个阶段：建立连接并协商同步、同步并加载RDB文件

、同步并加载新增写命令。如图所示：

全量同步主要步骤：

• 1.建立连接并协商同步：
• 1）从节点通过向主节点发送replicaof（5.0版本以前为slaveof）命令与主节点建立主从关系。
• 2）从节点向主节点发送psync ? -1命令。
• 3）主节点接收来自从节点的psync命令并向从节点响应+FULLRESYNC {runId} {offset}，从节点根据响应信息记录主节点的runid和offset。
• 2.同步并加载RDB文件
• 1）主节点执行bgsave命令fork出一个子进程读取内存数据生成对应的RDB文件，并将此后接收的客户端写命令写入该从节点对应的复制缓冲区（replication_buffer）。
• 2）将生成的RDB文件发送给从节点。
• 3）从节点接收来自主节点的RDB文件，将其存储到本地磁盘上，清空本地内存中的数据，并执行load命令，将快照文件中的数据加载到本地内存中。
• 4）加载完成后向主节点发送确认消息，通知主节点RDB文件加载完成。
• 3.同步并加载新增写命令：
• 1）主节点收到从节点发送的确认消息，将复制缓冲区记录的写命令发送给从节点。
• 2）从节点接收来自主节点复制缓冲区的新增写命令，并将其写入本地内存中。

注意：在全量复制期间，主节点的写操作会被阻塞，直到全量复制完成。因此，在数据量较大的情况下，全量复制可能会耗费较长时间，影响主节点的性能。

psync命令

psync命令格式：

psync {runId} {offset}

其中：

• runId表示从节点所复制主节点的运行Id。
• offset表示当前从节点已复制的数据偏移量。

psync执行流程，如图所示：

流程说明：

从节点向主节点发送psync {runId} {offset}，runId是目标主节点的运行Id，如果是第一次复制，由于不知道主库的runId，因此将runId设为：？，offset是从节点保存的复制偏移量，如果是第一次复制则为-1（表示全量复制）。

主节点会根据从节点请求携带的runId和offset返回结果：

• 如果回复+FULLRESYNC {runId} {offset} ，则从节点将触发全量复制流程。
• 如果回复+CONTINUE，则从节点将触发增量复制。
• 如果回复+ERR，则说明主节点不支持psync命令，将使用sync执行全量复制。

主从节点复制偏移量

• 1）参与复制的主从节点都会维护自身的复制偏移量。
• 2）主节点在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在info replication中的master_repl_offset指标中。
• 3）从节点每秒钟上报自身的的复制偏移量（slave_repl_offset）给主节点，主节点会保存从节点的复制偏移量。
• 4）从节点在接收到主节点发送的命令后，会累加自身的偏移量，统计信息在info replication中的slave_repl_offset指标中。
• 5）通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。

主节点复制积压缓冲区

• 1）复制积压缓冲区（repl_backlog_buffer）是一个保存在主节点的一个固定长度的先进先出的队列，默认为1MB。
• 2）复制积压缓冲区在从节点连接时创建，主节点处理写命令时，会将写命令发送给从节点，同时，也会将写命令写入复制积压缓冲区。
• 3）复制积压缓冲区主要用于增量同步，通过info replication可以查看相关信息。

主节点runId

• 1）每个Redis节点启动时，都会生成一个40位的runId。
• 2）runId的主要作用是用来识别Redis节点。如：使用ip+port的方式，主节点重启并修改了RDB/AOF数据，从节点再基于重启前的偏移量进行复制会存在风险。因此，当runId发生变更后，从节点将进行全量复制（Redis重启后，默认从节点会进行全量复制）。

重要参数

• repl-timeout：表示数据复制超时时长，默认为60s，在全量同步过程中，由于RDB文件过大（如：超过6GB）而导致传输时间超过参数repl-timeout设定的时长时，会导致全量复制失败，可以适当调大repl-timeout参数值。
• client-output-buffer-limit：表示客户端输出缓存限制，默认为0，表示不做限制，如果设定的值不为0，达到设定的阈值后，会断开链接并释放内存。
• 配置规则说明：
• client-output-buffer-limit normal 0 0 0：表示对于普通客户端，关闭该参数限制。
• client-output-buffer-limit slave 256MB 64MB 60：表示对于从节点客户端，如果输出缓存内存占用达到256M或超过64M的时间达到60s，则关闭从节点连接。
• client-output-buffer-limit pubsub 32mb 8mb 60：表示对于Pub/Sub客户端，如果输出缓存内存占用达到32M或超过8M的时间达到60s，则关闭客户端连接。

命令传播

主从复制完成后，主节点每接收一个写操作都会通过复制缓冲区（replication_buffer）发送给从节点，保证主从节点数据一致。

增量同步

在Redis2.8以前的版本中，当主从节点网络连接断开后，即使只有少量数据未同步到从节点，从节点重新连上主节点后也会触发全量复制。从Redis2.8版本开始，支持增量数据传输，当从节点重新连上主节点后，主节点只需将断连期间执行的命令发送给从节点，无需进行全量复制。

处理流程

Redis主从增量同步主要分为两个阶段：建立连接并协商同步、同步并加载新增写命令。如图所示：

增量同步主要步骤：

• 1.建立连接并协商同步：
• 1）从节点通过向主节点发送replicaof命令与主节点建立主从关系。
• 2）从节点向主节点发送psync {runid} {offset}命令。
• 3）主节点接收来自从节点的psync命令，根据从节点发送psync命令时携带的的runId和slave_repl_offset判断执行增量复制还是全量复制，判断依据是：如果从节点发送的runId与当前主节点的runId一致且从节点发送的slave_repl_offset未超过主节点复制积压缓冲区（repl_backlog_buffer）的长度，则向从节点响应+CONTINUE命令，开始增量复制，否则进行全量复制。
• 2.同步并加载新增写命令：
• 1）主节点根据从节点发送psync命令时携带的slave_repl_offset从复制缓冲区（replication_buffer）中获取增新增的写命令发送给从节点。
• 2）从节点接收来自主节点复制缓冲区的新增写命令，并将其写入本地内存中。并更新本地存储的offset为最新的offset。

注意：repl_backlog_buffer只是在从库断开连接重连时判断是否进行增量同步（即：slave_repl_offset在repl_backlog_buffer内），新增写命令是通过复制缓冲区发送给从库。

复制缓冲区与复制积压缓冲区区别

复制缓冲区（replication_buffer）和复制积压缓冲区（repl_backlog_buffer）都是与主从同步相关的概念，但它们的作用和实现方式不同：

• 复制缓冲区是指主节点将待复制的数据先写入缓冲区，等待从节点连接后再将数据发送给从节点。
• 复制积压缓冲区是指从节点在与主节点断开连接时，为了避免数据丢失，将待复制的数据先存储在缓冲区中，等待连接恢复后再将数据发送给主节点。

两者的作用都是为了保证主从同步的可靠性和数据完整性。如果从节点和主节点间的网络断连时间过长，复制积压缓冲区可能被新写入的命令覆盖，此时从节点就没有办法和主节点进行增量复制了，而是只能进行全量复制。为了避免这个问题，可以调大复制积压缓冲区的大小。而复制缓冲区的大小可以通过参数replication_buffer来设置。

无盘化同步

在全量复制过程中，主节点会将数据保存在磁盘的RDB文件中再发送给从节点，如果主节点上的磁盘空间有限或者是使用比较低速的磁盘，这种操作会给主节点带来较大的压力。在Redis2.8版本后，可以通过无盘复制来降低磁盘空间带来的影响，由主节点开启一个socket，在内存中创建RDB文件，再将RDB文件发送给从节点，不使用磁盘作为中间存储。

无盘复制一般应用在磁盘空间有限但是网络状态良好的情况下。

无盘复制相关参数：

• repl-diskless-sync ：是否开启无磁盘复制。
• repl-diskless-sync-delay：默认为5秒。等待一定时长再开始复制，目的是等待更多从节点连接。

主从心跳机制

主从节点建立连接后，会通过长连接维护彼此的心跳。

主从节点心跳检测机制：

• 1）主从节点彼此都有心跳检测机制，各自模拟成对方的客户端进行通信，通过client list命令可以查看复制相关客户端信息，主节点的连接状态为flags=M，从节点的连接状态为flags=S。
• 2）主节点默认每隔10s向从节点发送ping命令，判断从节点的存活状态。可以通过参数repl-ping-slave-period控制发送频率。
• 3）从节点在主线程中每隔1s发送replconf ack {offset}命令，向主节点上报自身当前的复制偏移量。replconf命令的作用：
• 实施监测主从节点的网络状态，上报自身复制偏移量，检查复制数据是否丢失，如果从节点数据丢失，则从主节点的复制缓冲区中拉取丢失的数据。保证从节点的最少活跃数量和活跃从节点允许的最大延时时长通过min-slaves-to-write和min-slaves-max-lag参数进行设置：
• min-slaves-to-write 2：表示从节点活跃数量少于2时，强制关闭master写功能，停止数据同步。
• min-slaves-max-lag 10：表示活跃从节点的延迟时长>=10s时，强制关闭master写功能，停止数据同步。
• 主节点根据replconf命令判断从节点超时时间，体现在info replication统计的lag信息中，lag表示与从节点最后一次通信延迟的秒数，正常延迟应该在0～1之间。如果超过repl-timeout参数设置的值（默认为60s），则判定从节点下线并断开复制客户端连接。即使主节点判定从节点下线，如果从节点重新恢复，则心跳检测会继续进行。

主从同步优缺点

主从同步的优点：

• 数据备份和恢复：从节点可以作为数据备份，保证在主节点宕机或丢失数据时进行快速恢复。
• 读写分离：从节点可以处理读请求，减轻主节点压力，提高服务读写性能。
• 高可用性：主节点宕机时，利用哨兵机制，将从节点自动切换为主节点继续提供服务。
• 扩展性：通过新增从节点数量，可以实现横向扩展，增加集群处理能力。

主从同步的缺点：

• 延迟：主节点处理数据时，需要广播数据给所有从节点，会有一定的网络传输延迟。
• 一致性问题：Redis采用异步复制机制，当主节点修改了数据但还未同步到从节点时，如果此时发生主节点宕机，就可能出现数据不一致的情况。

【阅读推荐】

更多精彩内容请移步【南秋同学】个人主页查阅Redis系列合集（持续更新中）。

想了解常用数据结构与算法（如：数组、链表、栈、队列、快速排序、堆与堆排序、二分查找、动态规划、广度优先搜索算法、深度优先搜索算法等）的同学请移步->数据结构与算法系列合集（持续更新中）。

【作者简介】

一枚热爱技术和生活的老贝比，专注于Java领域，关注【南秋同学】带你一起学习成长～