概念
- 如果把数据都存储到一台服务器上,当服务器出现宕机后,数据会丢失。而把数据备份到多台服务器上,那么当一台服务器发生故障后,其他服务器仍然可以继续提供服务。由于是多台服务器,所以服务器之间的
数据要保持一致性
。 于是Redis提供了主从复制模式,采用的是「读写分离」的方式。主服务器负责读写,从服务器一般只负责读
注意:第一次同步是全量同步的方式。
主从服务器同步流程
- 使用
replicaof(Redis 5.0 之前使用 slaveof)
命令形成主服务器和从服务器的关系。
# 服务器 B 执行这条命令,此时服务器 B 就会变成服务器 A 的「从服务器」
replicaof <服务器 A 的 IP 地址> <服务器 A 的 Redis 端口号>
主从服务器间的第一次同步的过程可分为三个阶段:
- 第一阶段是建立链接、协商同步;
- 第二阶段是主服务器同步数据给从服务器;
- 第三阶段是主服务器发送新写操作命令给从服务器。
具体流程
- 执行了
replicaof
命令后,从服务器就会给主服务器发送psync
命令,该命令包含主服务器的 runID(每个Redis服务器启动的唯一标识)
和复制进度 offset
。第一次同步runID="?",offset=-1
。 - 主服务器收到
psync
命令后,会用FULLRESYNC
(全增量)作为响应命令返回给对方。 - 主服务器会执行
bgsave
命令来fork
一个子进程生成 RDB 文件(异步的,不会阻塞主线程
),然后把文件发送给从服务器。 - 从服务器收到 RDB 文件后,会先清空当前的数据,然后载入 RDB 文件。
- 在此期间 写操作命令并没有记录到刚刚生成的 RDB 文件中,这时主从服务器间的数据就不一致了。
- 为了保证主从服务器的数据一致性,主服务器在下面这三个时间间隙中将收到的写操作命令,写入到
replication buffer
缓冲区里:- 主服务器生成 RDB 文件期间;
- 主服务器发送 RDB 文件给从服务器期间;
- 「从服务器」加载 RDB 文件期间;
- 从服务器加载完数据后,会回复一个确认消息给主服务器。主服务器将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器,服务器执行发来的命令。
命令传播
- 主从服务器在完成第一次同步后,双方之间就会维护一个
TCP 长连接
。目的是避免频繁的 TCP 连接和断开带来的性能开销。
分摊压力
问题
- 主服务器会做两件耗时的操作:生成 RDB 文件和传输 RDB 文件。当从服务器比较多的时候,就会带来两个问题:
- 如果主服务器的内存数据非大,在执行 fork() 函数时是会阻塞主线程的,从而使得 Redis 无法正常处理请求;
- 传输 RDB 文件会占用主服务器的网络带宽,会对主服务器响应命令请求产生影响。
解决办法
- 主服务器生成 RDB 和传输 RDB 的压力可以分摊到充当经理角色的从服务器。
'在「从服务器」上执行下面这条命令,使其作为目标服务器的从服务器'
replicaof <目标服务器的IP> 6379
增量复制
- 主从第一次同步后就是保持长连接,但是由于网络问题,连接可能断开,当网络恢复后,主从服务器会采用
增量复制
的方式继续同步
增量复制的流程 - 从服务器在恢复网络后,会发送 psync 命令给主服务器,此时的 psync 命令里的 offset 参数不是 -1;
- 主服务器收到该命令后,然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据;
- 主服务将主从服务器断线期间,所执行的写命令发送给从服务器,然后从服务器执行这些命令。
主服务器
repl_backlog_buffer
,是一个「环形」缓冲区,用于主从服务器断连后,从中找到差异的数据;- 在主服务器进行命令传播时,不仅会将写命令发送给从服务器,还会将写命令写入到 repl_backlog_buffer 缓冲区里。
replication offset
,标记上面那个缓冲区的同步进度,主从服务器都有各自的偏移量,主服务器使用master_repl_offset
来记录自己「写」到的位置,从服务器使用slave_repl_offset
来记录自己「读」到的位置。- 网络断开恢复后,从服务器会通过 psync 命令将自己的复制偏移量
slave_repl_offset
发送给主服务器,主服务器根据自己的master_repl_offset - slave_repl_offset
的值决定执行增量还是全量- 从服务器要读取的数据还在 repl_backlog_buffer 缓冲区里,那么主服务器将采用增量同步的方式;
- 从服务器要读取的数据已经不存在 repl_backlog_buffer 缓冲区里,那么主服务器将采用全量同步的方式。
- 网络断开恢复后,从服务器会通过 psync 命令将自己的复制偏移量
总结
- 为了避免在网络恢复时,主服务器频繁地使用全量同步的方式,我们应该调整下 repl_backlog_buffer 缓冲区大小,尽可能的大一些,减少出现从服务器要读取的数据被覆盖的概率,从而使得主服务器采用增量同步的方式。
面试题
1.Redis主从节点时长连接还是短连接?
- 长连接
2.怎么判断 Redis 某个节点是否正常工作?
- 通过互相的 ping-pong 心态检测机制,如果有一半以上的节点去 ping 一个节点的时候没有 pong 回应,集群就会认为这个节点挂掉了,会断开与这个节点的连接。
- Redis 主节点默认每隔 10 秒对从节点发送 ping 命令,判断从节点的存活性和连接状态。
- Redis 从节点每隔 1 秒发送 replconf ack{offset} 命令。
- 监测主从节点网络状态;
- 上报自身复制偏移量, 检查复制数据是否丢失, 如果从节点数据丢失, 再从主节点的复制缓冲区中拉取丢失数据。
3.主从复制架构中,过期key如何处理?
- 主节点处理了一个key或者通过淘汰算法淘汰了一个key,这个时间主节点模拟一条del命令发送给从节点,从节点收到该命令后,就进行删除key的操作。
4.Redis 是同步复制还是异步复制?
- Redis 主节点每次收到写命令之后,先写到内部的缓冲区,然后异步发送给从节点。
5.主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别?
出现的阶段不一样:
- repl backlog buffer 是在增量复制阶段出现,
一个主节点只分配一个 repl backlog buffer;
- replication buffer 是在全量复制阶段和增量复制阶段都会出现,
主节点会给每个新连接的从节点,分配一个 replication buffer;
- repl backlog buffer 是在增量复制阶段出现,
这两个 Buffer 都有大小限制的,当缓冲区满了之后,发生的事情不一样:
- 当 repl backlog buffer 满了,因为是环形结构,会直接
覆盖起始位置数据;
- 当 replication buffer 满了,会导致连接断开,删除缓存,从节点重新连接,
重新开始全量复制。
- 当 repl backlog buffer 满了,因为是环形结构,会直接
6.为什么会出现主从数据不一致?
- 主从节点间的命令复制是异步进行的,所以无法实现强一致性保证(主从数据时时刻刻保持一致)。
- 主节点并不会等到从节点实际执行完命令后,再把结果返回给客户端,而是主节点自己在本地执行完命令后,就会向客户端返回结果了。如果从节点还没有执行主节点同步过来的命令,主从节点间的数据就不一致了。
7.如何应对主从数据不一致?
- 第一种方法,尽量保证主从节点间的网络连接状况良好,避免主从节点在不同的机房。
- 第二种方法,可以开发一个外部程序来监控主从节点间的复制进度
- 如果某个从节点的进度差值大于我们预设的阈值,可以让客户端不再和这个从节点连接进行数据读取。不过,为了避免出现客户端和所有从节点都不能连接的情况,我们需要把复制进度差值的阈值设置得大一些。
8.主从切换如何减少(不可能保证数据完全不丢失)数据丢失?
主从切换过程中,产生数据丢失的情况有两种:
- 异步复制同步丢失
- 集群产生脑裂数据丢失
异步复制同步丢失?
- 主从复制时异步的,当客户端发送写请求给主节点的时候,客户端会返回 ok,接着主节点将写请求异步同步给各个从节点,如果此时主节点还没来得及同步给从节点时发生了断电,那么主节点内存中的数据会丢失。
减少异步复制的数据丢失的方案
- Redis 配置里有一个参数
min-slaves-max-lag
,当主从数据复制和同步延迟超过该值,那么主节点会拒绝接收任何请求
- 假设将
min-slaves-max-lag=10s
,如果数据同步完成所需要时间超过10s,master 就拒绝写入新请求。这样主从数据控制在10s内,即使主节点宕机也只损失10s数据- 对于客户端,当客户端发现 master 不可写后,将数据暂时写入本地缓存和磁盘中,在一段时间(等 master 恢复正常)后重新写入 master 来保证数据不丢失,也可以将数据写入 kafka 消息队列,等 master 恢复正常,再隔一段时间去消费 kafka 中的数据,让将数据重新写入 master 。
集群产生脑裂数据丢失?
- 由于网络问题,主从节点之间失去联系,当主节点与客户端正常,主从数据不同步;哨兵重新选取主节点,此时有两个主节点。等网络恢复,旧主节点会降级为从节点,再与新主节点进行同步复制的时候,由于会从节点会清空自己的缓冲区,所以导致之前客户端写入的数据丢失了。
减少脑裂的数据丢的方案
min-slaves-to-write x
,主节点必须要有至少 x 个从节点连接,如果小于这个数,主节点会禁止写数据。min-slaves-max-lag x
,主从数据复制和同步的延迟不能超过 x 秒,如果主从同步的延迟超过 x 秒,主节点会禁止写数据。- 主节点连接的从节点中至少有 N 个从节点,「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒,否则,主节点就不会再接收客户端的写请求了。
9.主从如何做到故障自动切换?
- 主节点挂了 ,从节点是无法自动升级为主节点的,这个过程需要人工处理,在此期间 Redis 无法对外提供写操作。
- 此时,
Redis 哨兵机制
起作用,哨兵在发现主节点出现故障时,由哨兵自动完成故障发现和故障转移,并通知给应用方,从而实现高可用性。
文章节选自https://xiaolincoding.com/