引言
我们之前操作 Redis 都是单机版,但是实际应用中没人使用单机版,都是搭建集群的方式。这篇文章要介绍的主从复制,是指将一台 Redis 服务器的数据,复制到其他 Redis 服务器,我们将前者称为主节点 master,将后者称为从节点 slave(replica)。在这个过程中,数据的复制是单向的,即只能从主节点到从节点。并且从节点只能读数据,不能写数据,实现读写分离。
- 一个主节点可以有多个从节点,一个从节点只能有一个主节点。所有的服务器默认都是主节点。
- 从节点下面还可以有从节点,形成一个图的结构
主从复制的优点
- 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
- 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
- 负载均衡:在主从复制的基础上,配合读写分离,写数据时应用连接主节点,读数据时应用连接从节点,分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高 Redis 服务器的并发量。
- 高可用基础:主从复制是哨兵模式和集群能够实施的基础。
开启主从复制
主从复制的前提就是多个 Redis 服务器,因此要多个配置文件。
开启主从复制的方式有两种:
配置配置文件
从服务器配置master节点
# 主节点ip port # replicaof <masterip> <masterport> # 主节点的认证密码(可选) # masterauth <master-password>
显示命令开启
客户端使用该命令
slaveof [ip] [port]
INFO REPLLICATION
命令可查看节点信息
主从复制的具体实现
主从复制的实现可以分为三个阶段:建立连接、数据同步、命令传播
1. 建立连接
发送 slaveof 异步命令
建立 socket 连接
连接成功后从节点会为该 socket 建立一个专门处理复制工作的文件事件处理器,负责后续的复制工作,如接收 RDB 文件、接收命令传播等;
发送 ping 命令
从节点成为主节点的客户端之后,发送 ping 命令进行首次请求,目的是检查 socket 连接是否可用,以及主节点当前是否能够处理请求。
身份验证
取决于从节点是否设置 masterauth 选项,而这个又取决于主节点是否设置 requirepass
发送从节点端口信息
2. 数据同步
连接建立完成后,要进行主从数据库的数据同步,这一步也可以看作从节点中数据的初始化。数据同步有旧版和新版两种。我们先来看看旧版 Redis 怎么实现数据同步的
旧版同步
旧版同步使用的命令是 sync,同步方式是全量复制。以下是sync命令的执行步骤:
- 从服务器向主服务器发送 sync 命令
- 主服务器收到后执行 BGSAVE 的rgb持久化命令,生成一个RDB文件。并用一个缓冲区记录生成rgb文件期间执行的所有写命令。
- 主服务器将 rgb 文件发送给从服务器,从服务器载入整个 rgb 文件,同步数据库状态至执行 BGSAVE 时主服务的状态
- 主服务器将记录在缓冲区的写命令发送给从服务器。至此从服务和主服务数据库状态达到一致。
旧版同步功能的缺陷:
断线后重连需要再次发送 sync 同步命令,主服务再次生成 rgb 文件,从服务器载入恢复数据库状态。简单来说就是断线后又要全量复制,但其实没有必要,我们只需要同步断线后到重新连接期间主服务器变化的数据即可。
并且,sync是一个非常耗费资源的操作,因此旧版同步是非常低效的。
新版同步
新版同步使用的命令是 psync ,同步方式是增量复制
psync 有完成重同步和部分重同步两种模式。完整重同步其实就是sync,主要用于处理初次服务的情况。部分重同步主要用于处理断线后重连的情况。部分重同步不需要重新生成、传送和载入整个rdb文件,只需要将从服务器缺少的写命令发送给从服务器执行即可。完美的解决了旧版同步效率低下的问题。
下面我们就来看看他是如何实现的?首先要了解几个概念
主节点和从节点的复制偏移量
主节点的复制积压缓冲区
当从服务器重新连接上主机时,会通过 psync 命令把自己的offset发给主节点
- 如果offset之后的数据全部在队列中,执行部分重同步(增量复制)
- 如果offset之后的数据不全在队列中,执行完整重同步(全量复制)
服务器的运行ID
当从节点对主节点进行初次复制时,主节点会把自己的运行ID发给从节点,从节点保存并在断线重连上主节点时把次ID发送给主节点:
- 如果此ID和主节点当前连接的ID一致,说明是同一个状态,可以进行增量复制
- 如果不同,只能进行全量复制
总结:psync的执行流程:
命令传播
数据同步阶段完成后,主从节点进入命令传播阶段;在这个阶段主节点将自己执行的写命令发送给从节点,从节点接收命令并执行,从而保证主从节点数据的一致性。
这个阶段没啥可说的,就是把主节点执行的写命令发给从节点,让它们也执行一次,保证主从一致性
心跳检测
在命令传播阶段,从服务器默认会以每秒一次的频率向主服务器发送replconf ACK <replication_offset>
,其中replication_offset
是它当前的复制偏移量。心跳检测的目的有以下三个:
检测主从服务器的网络连接状态
如果主服务器超过一秒没有收到从服务的该命令,那么主服务器就知道主从连接出现问题了
辅助实现min-slaves
主服务我们可以配置以下两个参数来防止不安全写命令传播,如果从节点小于3或者lag大于10,主服务器都会拒绝执行写命令
# 从节点的最小个数 # min-replicas-to-write 3 # 从节点lag的最大值 # min-replicas-max-lag 10
检测命令丢失
上面说过心跳检测命令还发送了从节点自身保存的offset。主节点会与自己的 offset 进行对比,如果从节点数据缺失(如网络丢包),主节点会找到缺失的数据,并把这些数据重新推送给服务器(这里也会利用复制积压缓冲区)。
参考