前言

Redis为了保证服务高可用，其中一种实现就是主从模式，即一个Redis服务端作为主节点，若干个Redis服务端作为主节点的从节点，从而实现即使某个服务端不可用时，也不会影响Redis服务的正常使用。本篇文章将对主从模式中为了保证主节点和从节点数据一致而实现的主从同步机制进行学习。

正文

一. 主从数据同步概述

Redis主从模式中，一个高可用的Redis服务由一个Redis主节点（Master，后续简称为主节点）和若干Redis从节点（Slave，后续简称为从节点）组成。

Redis中采用读写分离来保证主节点和从节点之间的数据一致性，具体实现如下。

• 主节点支持数据写入和数据读取，从节点只支持数据读取；
• 主节点会与从节点之间执行主从数据同步，以保证主节点数据与从节点数据一致。

主从数据同步分为如下几种情况。

• 从节点与主节点建立连接时进行全量同步；
• 主节点与从节点正常运行时的同步；
• 主节点与从节点连接断开后又重连时会进行增量同步或全量同步。

本篇文章将对Redis中的主从数据同步的几种情况进行学习。

二. 从节点与主节点建立连接时的全量同步

从节点与主节点建立连接时的全量同步可以用下图进行示意。

对于上图所示步骤，说明如下。

1. 从节点通过配置文件中的replicaof {masterip} {port} 获得主节点ip和port，然后向主节点发送psync {repID} {offset} 指令，其中repID表示主节点唯一标识，offset为复制偏移量，因为当前从节点与主节点尚未连接，且尚未开始复制，所以repID为 ?，offset为-1；
2. 主节点收到psync {repID} {offset} 指令后，会响应从节点并发送fullresync {repID} {offset} 指令，从节点会将主节点的repID和offset保存下来；
3. 主节点收到psync {repID} {offset} 指令后，会执行bgsave异步的生成RDB文件，然后主节点将RDB文件发送给从节点，从节点接收到RDB文件后，会清空内存数据，然后加载RDB文件的数据到内存中；
4. 由于主节点生成RDB文件时是异步生成的，此时主节点是非阻塞的，可以继续处理业务，所以在生成RDB文件期间，发送RDB文件期间和从节点加载RDB文件期间主节点执行的写指令均会存放到缓冲区replication_buffer中，所以当从节点加载完RDB文件后，主节点会将replication_buffer中的内容发送给从节点，从节点会执行replication_buffer中的指令，从而达到和主节点一致的状态。

特别说明：在全量同步期间，主节点是非阻塞的，同时从节点很大程度上是非阻塞的，从节点的非阻塞表现在可以通过配置让从节点在全量同步期间使用旧内存数据来处理查询指令，但是从节点在删除旧内存数据并加载RDB文件数据到内存中这段时间里，从节点是阻塞的（4.0版本前，删除旧数据和加载RDB文件都会阻塞从节点，4.0版本开始，删除旧数据可以通过配置变成不阻塞从节点，但是加载RDB文件还是会阻塞从节点）。

最后说明一个异常情况，那就是replication_buffer是有大小限制的，如果replication_buffer大小超过了限制，主节点会断开与从节点的同步连接，此时replication_buffer的数据会被清空，然后会重新开始全量同步，所以replication_buffer大小需要设置一个合理值。

更多C++后端开发技术点知识内容包括C/C++，Linux，Nginx，ZeroMQ，MySQL，Redis，MongoDB，ZK，流媒体，音视频开发，Linux内核，TCP/IP，协程，DPDK多个高级知识点。

【文章福利】另外还整理一些C++后台开发架构师 相关学习资料，面试题，教学视频，以及学习路线图，免费分享有需要的可以点击 C++后端学习资料 免费领取

三. 主节点与从节点正常运行时的同步

参见redis.io/docs/manual…中的一段话。

When a master and a replica instances are well-connected, the master keeps the replica updated by sending a stream of commands to the replica to replicate the effects on the dataset happening in the master side due to: client writes, keys expired or evicted, any other action changing the master dataset.

即正常运行期间，主节点会向从节点发送写指令流来同步主节点的数据变更到从节点。

四. 主节点与从节点断开连接又重连时的增量同步

在第二节中提到了从节点在启动后并需要与主节点进行全量同步时，会向主节点发送psync {repID} {offset} 指令，这里先对repID和offset进行解释。

repID

repID即Replication ID，是Redis节点作为主节点启动时，或者从节点被晋升为主节点时，该主节点都会生成一个新的repID（思考一下什么情况还会有旧的repID），后续连接到该主节点的从节点在第一次全量同步的建立连接阶段会保存一份主节点的repID，所以具有相同repID的节点的数据具有相关性。

offset

offset即偏移量，可以理解为当前节点的数据的逻辑时间。举个例子，某个节点A的offset为500，和节点A具有相同repID的节点B的offset为520，那么表明节点B的数据比节点A的数据更新，节点A需要再执行一些写指令才能够让节点A的数据状态和节点B一致。

有了上述两点认识，现在思考一个问题：主节点和从节点如果因为某些原因，断开了连接，而断开连接这段时间里主节点又处理了一些写指令，那么从节点重新连接后，应该怎么将断开连接那段时间里的写指令同步给重连的从节点？通常的想法就是再执行一次全量同步，在2.8之前的版本，确实是这么实现的，但从2.8版本开始，引入了增量同步，具体的实现如下。

• 主节点维护着一份repl_backlog_buffer缓冲区域，叫做复制积压缓冲区，主节点在任何时候执行写指令时，都会将写指令记录在repl_backlog_buffer中，repl_backlog_buffer是一个环形数组，所以当数组满时，后续再添加的写指令会覆盖旧的写指令，因此主节点还使用了一个叫做master_repl_offset的偏移量，来记录主节点的存到repl_backlog_buffer中的最新写指令的位置，master_repl_offset就是上面提到的offset，只不过在主节点中叫做master_repl_offset；
• 从节点也有一个偏移量叫做slave_repl_offset，用来记录从节点已经从主节点的repl_backlog_buffer中同步到的最新写指令的位置；
• 主节点收到写指令后，master_repl_offset增加，从节点从主节点的repl_backlog_buffer同步了写指令后，slave_repl_offset增加；
• 从节点断开重连后，会向主节点发送psync {repID} {slave_repl_offset} 指令，此时slave_repl_offset通常会小于master_repl_offset，所以主节点仅需要将slave_repl_offset到master_repl_offset之间的写指令同步给从节点，这就是增量同步。

特别注意：如果repl_backlog_buffer中记录的从节点断开连接期间的写指令已经被后续的写指令覆盖，那么此时不能执行增量同步，而是需要执行全量同步，所以需要将repl_backlog_buffer的大小设置一个合理的值，来尽可能的保证不出现重连后需要全量同步的情况。

总结

以一张图进行总结。

原文链接：详解Redis的主从同步原理 - 掘金