Redis:主从同步保持数据一致
- CAP原理
- 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设计与实现