Redis：主从同步保持数据一致

在实际的业务开发中，很多公司都没有使用集群，但是都采用了主从同步，当master 挂掉的时候，运维让从库过来接管，服务就可以继续，否则 master 需要经过数据恢复和重启的过程，这就可能会拖很长的时间，影响线上业务的持续服务。

Redis如果发生了宕机，我们可以通过AOF日志和RDB文件的形式恢复数据，从而保证尽量少丢失数据来提升可靠性。但是如果服务本身不可用，在其恢复期间也是无法服务新的数据存取的请求。

都说Redis具有高可靠性，主要指的是两层含义：一是数据尽量少丢失，二是服务尽量少中断。AOF和RDB保证了前者，而对于后者，Redis的做法就是增加副本冗余量，将一份数据同时保存在多个实例上。即使有一个实例出现了故障，需要过一段时间才能恢复，其他实例也可以对外提供服务，不会影响业务使用。

在了解主从复制前，可以先回顾下CAP原理；

CAP原理

• C - Consistent ，一致性
• A - Availability ，可用性
• P - Partition tolerance ，分区容忍性
  分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的，这意味着必然会有网络断开的风险，这个网络断开的场景的专业词汇叫着「网络分区」。

在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的「一致性」将无法满足，因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」，也就是暂停分布式节点服务，在网络分区发生时，不再提供修改数据的功能，直到网络状况完全恢复正常再继续对外提供服务。

一句话概括 CAP 原理就是——网络分区发生时，一致性和可用性两难全。

Redis主从同步

Redis采用主从库来保证数据的最终一致性，主从库之间采用的读写分分离；

• 读操作：主库、从库都可以接收；
• 写操作：主库先执行，然后主库将写操作同步给从库；

Redis 的主从数据是异步同步的，所以分布式的 Redis 系统并不满足「一致性」要求。当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供修改服务，所以 Redis 满足「可用性」。

Redis 保证「最终一致性」，从节点会努力追赶主节点，最终从节点的状态会和主节点的状态将保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，一旦网络恢复，从节点会采用多种策略努力追赶上落后的数据，继续尽力保持和主节点一致。

为什么采用读写分离？
不管是主库还是从库，都能接收客户端的写操作。如果非要保持这个数据在三个实例的一致性，就涉及到加锁、实例间协商是否完成修改等一系列操作，就会带来巨额的开销。

主从库模式一旦采用了读写分离，所有数据的修改只会在主库上进行，不用协调三个实例。主库有了最新的数据后，会同步给从库，这样，主从库的数据就是一致的。

主从库的第一次同步

启动多个Redis实例时，相互之间就可以通过replicaof命令形成主库和从库的关系。 例如现在有两个实例，分别是实例1（127.0.0.1)和实例2（127.0.0.2）,在实例2上执行如下命令就可成为实例1的从库，并且从实例1上复制数据。

replicaof 127.0.0.1 6379

阶段一：主从库间建立连接、协商同步

• 从库给主库发送psync命令，表示要进行数据同步，主库根据这个命令来启动复制；
• psync包含了主库的runID和复制进度offset两个参数；
• • runID：每个Redis实例启动时都会自动生成的一个随机ID，用来唯一标记这个实例，第一次连接时将runID设为“？”。
• • offset，此时设为-1，表示第一次复制；
• 主库收到psync命令后，会用FULLRESYNC响应命令带上两个参数：主库runID和主库目前的复制进度offset，返回给从库。从库收到响应后，会记录下这两个参数。

阶段二：主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载

• 主库执行bgsave命令，生成RDB文件，将噶文件发给从库；
• 从库接收到RDB文件后，会先清空当前数据库，然后加载RDB文件；
• 在主库将数据同步给从库的过程中，主库不会被阻塞，仍然可以正常接收请求；

阶段三：主库会把第二阶段执行过程中新收到的写命令，再发送给从库
为了保证主从库的数据一致性，主库会在内存中用专门的replication buffer，记录RDB文件生成后收到的所有写操作；

主从全量复制时主库的压力

一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成RDB文件和传输RDB文件。

如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于fork子进程生成RDB文件，进行数据全量同步。fork这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输RDB文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。

采用主-从-从模式，通过“主-从-从”模式将主库生成RDB和传输RDB的压力，以级联的方式分散到从库上。

在刚才介绍的主从库模式中，所有的从库都是和主库连接，所有的全量复制也都是和主库进行的。现在，我们可以通过“主-从-从”模式将主库生成RDB和传输RDB的压力，以级联的方式分散到从库上。

我们可以再选择一些从库（例如三分之一的从库），在这些从库上执行如下命令，让它们和刚才所选的从库，建立起主从关系。

replicaof 所选从库的IP 6379

这些从库就会知道，在进行同步时，不用再和主库进行交互了，只要和级联的从库进行写操作同步就行了，这就可以减轻主库上的压力，如下图所示：

一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，可以避免频繁建立连接的开销。

但是主从库网络断连活着阻塞，主从库之间无法进行命令传播，那么从库的数据也没法和主库保持一致。

主从库间网络断开连接？

网络断了之后，主从库会采用增量复制的方式继续同步。听名字大概就可以猜到它和全量复制的不同：全量复制是同步所有数据，而增量复制只会把主从库网络断连期间主库收到的命令，同步给从库。

那么，增量复制时，主从库之间具体是怎么保持同步的呢？这里的奥妙就在于repl_backlog_buffer这个缓冲区。我们先来看下它是如何用于增量命令的同步的。

当主从库断连后，主库会把断连期间收到的写操作命令，写入replication buffer，同时也会把这些操作命令也写入repl_backlog_buffer这个缓冲区。

repl_backlog_buffer是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

刚开始主库和从库的起始位置相同，随着主库不断接收新的写操作，会逐渐偏离起始位置，用偏移量来衡量这个偏移距离的大小，对于从库来说，对应的偏移量就是master_repl_offset。主库接收的新写操作越多，这个值就会越大。

主从库的连接恢复之后，从库首先会给主库发送psync命令，并把自己当前的slave_repl_offset发给主库，主库会判断自己的master_repl_offset和slave_repl_offset之间的差距。

在网络断连阶段，主库可能会收到新的写操作命令，所以，一般来说，master_repl_offset会大于slave_repl_offset。此时，主库只用把master_repl_offset和slave_repl_offset之间的命令操作同步给从库就行。

就像刚刚示意图的中间部分，主库和从库之间相差了put d e和put d f两个操作，在增量复制时，主库只需要把它们同步给从库，就行了。

因为repl_backlog_buffer是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的操作。如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。

为了避免这一情况，可以调整repl_backlog_size这个参数，缓冲空间的计算公式是：缓冲空间大小 = 主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小。

参考文献

1、极客时间-Redis核心技术与实战；
2、掘金-Redis深度历险
3、Redis设计与实现