前言
Redis
的高可用方案包括:持久化、主从复制、哨兵和集群。其中持久化侧重解决的是 Redis
数据的单机备份问题;而主从复制则侧重解决数据的多机热备,此外,主从复制还可以实现负载均衡和故障恢复。
本文主要介绍 Redis
主从复制,包括如何使用主从复制、主从复制相关的配置、主从复制的原理等。
主从复制
主从复制,是指将一台Redis
服务器的数据,复制到其他的Redis
服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。
默认情况下,每台Redis
服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
主从复制的作用:
- 数据冗余:主从复制实现数据的热备份,是持久化之外的一种数据冗余方式
- 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复,实际上是一种服务的冗余
- 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务,分担服务器负载;尤其是读多写少的情况下,通过多个节点分担读负载,大大提高Redis服务器的负载能力。
- 高可用基石:主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础
配置主从
Redis主从复制的开启,完全是在从节点发起,不需要主节点做任何事情。
配置当前主机为指定主机的 slave
节点,有三种方式:
- 配置文件
- 启动命令
- 客户端命令
上述三种方式都可以开启主从复制,命令:slaveof <masterip> <masterport>
下面为客户端命令实例:
127.0.0.1:6379> SLAVEOF 192.168.96.148 6379
OK
实现原理
1、保存主节点信息
从执行主从配置的命令时,从节点服务器内部维护了两个字段:masterip
和masterport
,用于存储主节点的ip和port
slaveof
是异步命令,从节点完成主节点ip和port的保存后,向发送slaveof
命令的客户端直接返回 ok
2、建立 socket 连接
从节点以 1次/s 的频率调用复制定时函数 replicationCron()
,如果发现了有主节点可以连接,便会根据主节点的ip和port,创建 socket 连接,如果连接成功,则:
- 从节点:为该socket建立一个专门处理复制工作的文件事件处理器,负责后续的复制工作,如接收RDB文件、接收命令传播等
- 主节点:接收到从节点的 socket 连接后(即 accept 之后),为该socket创建相应的客户端状态,并将从节点看做是连接到主节点的一个客户端,后面的步骤会以从节点向主节点发送命令请求的形式来进行
3、发送 Ping 命令
从节点成为主节点的客户端之后,发送ping
命令进行首次请求,目的是:检查 socket 连接是否可用,以及主节点当前是否能够处理请求。
从节点发送 ping 命令后,可能出现3中情况:
- 返回 pong :说明 socket 连接正常,且主节点当前可以处理请求,复制过程继续
- 超时:一定时间后从节点仍未收到主节点的回复,说明 socket 连接不可用,则从节点断开 socket 连接,并重连
- 返回 pong 以外的结果:如果主节点返回其他结果,如正在处理超时运行的脚本,说明主节点当前无法处理命令,则从节点断开socket连接,并重连
4、身份验证
如果从节点中设置了 masterauth
选项,则从节点需要向主节点进行身份验证;没有设置该选项,则不需要验证。从节点进行身份验证是通过向主节点发送 auth
命令进行的,auth
命令的参数即为配置文件中的masterauth
的值。
如果主节点设置密码的状态,与从节点 masterauth
的状态一致(一致是指都存在,且密码相同,或者都不存在),则身份验证通过,复制过程继续;如果不一致,则从节点断开 socket 连接,并重连。
5、发送从节点端口信息
身份验证之后,从节点会向主节点发送其监听的端口号,主节点将该信息保存到该从节点对应的客户端的 slave_listening_port
字段中;该端口信息除了在主节点中执行 info Replication
时显示以外,没有其他作用。
复制阶段
Redis
的复制又分为:数据同步和命令传播两个操作。
数据同步阶段
主从节点之间的连接建立之后,便可以开始进行数据同步,该阶段可以理解为从节点数据的初始化。具体执行的方式是:从节点向主节点发送 psync
命令,执行同步操作,并将自己的数据库更新至主服务器数据库当前所处的状态。
数据同步阶段是主从复制最核心的阶段,根据主从节点当前状态的不同,可以分为全量复制和部分复制。
在数据同步阶段之前,从节点是主节点的客户端,主节点不是从节点的客户端;而到了这一阶段后,主从节点互为客户端。原因在于:在此之前,主节点只需要响应从节点的请求即可,不需要主动发请求,而在数据同步阶段和后面的命令传播阶段,主节点需要主动向从节点发送请求,才能完成复制。
命令传播阶段
当完成了数据同步阶段,主从服务器就会进入命令传播阶段,这时主服务器只要一直将自己执行的写命令发送给从服务器,而从服务器只要一直接收并执行主服务器发来的写命令,就可以保证主从服务器一直保持一致了。
复制类型
全量复制
全量复制用于初次复制或者其他无法进行部分复制时的情况,将主节点中的所有数据都发送给从节点,是一个非常重型的操作。
Redis
通过 psync
命令进行全量复制的过程如下:
- 从节点判断无法进行部分复制,向主节点发送全量复制的请求;或从节点发送部分复制的请求,但主节点判断无法进行部分复制
- 主节点收到全量复制命令后,执行
bgsave
,在后台生成RDB
文件,并使用一个缓冲区记录从现在开始执行的所有写命令 - 主节点的
bgsave
命令完成后,将RDB
文件发送给从节点;从节点首先清除自己的旧数据,然后载入接收的RDB
文件,将数据库状态更新至主节点执行bgsave
时的数据库状态 - 主节点将前述复制缓冲区的所有写命令发送给从节点,从节点执行这些写命令,将数据库状态更新至主节点的最新状态
- 如果从节点开启了
AOF
,则会触发bgrewriteaof
的执行,从而保证AOF
文件更新至主节点的最新状态
部分复制
用于网络中断等情况后的复制,只将中断区间主节点执行的写命令发送给从节点,与全量复制相比更加高效。需要注意的是,如果网络中断时间过长,导致主节点没有能够完整的保存中断期间执行的写命令,则无法进行部分复制,仍使用全量复制。
由于全量复制在主节点数据量较大时效率低,因此 Redis 2.8
开始提供部分复制,用于处理网络中断时的数据同步。
复制偏移量
主节点和从节点分别维护一个复制偏移量,代表的是主节点向从节点传递的字节数;主节点每次向从节点传播N个字节数据时,主节点的offset
增加N;从节点每次收到主节点传来的N个字节数据时,从节点的offset
增加N。
offset
用于判断主从节点的数据库状态是否一致:如果二者offset
相同,则一致;如果offset
不同,则不一致,此时可以根据两个offset
找出从节点缺少的那部分数据。例如,如果主节点的offset
是1000,而从节点的offset
是500,那么部分复制就需要将offset
为501-1000的数据传递给从节点。而offset
为501-1000的数据存储的位置,就是下面要介绍的复制积压缓冲区。
复制积压缓冲区
复制积压缓冲区是由主节点维护的、固定长度的、先进先出(FIFO)队列,默认大小1MB;当主节点开始有从节点时创建,其作用是备份主节点最近发送给从节点的数据。注意,无论主节点有一个还是多个从节点,都只需要一个复制积压缓冲区。
在命令传播阶段,主节点除了将写命令发送给从节点,还会发送一份给复制积压缓冲区,作为写命令的备份;除了存储写命令,复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量(offset)。由于复制积压缓冲区定长且是先进先出,所以它保存的是主节点最近执行的写命令;时间较早的写命令会被挤出缓冲区。
由于该缓冲区长度固定且有限,因此可以备份的写命令也有限,当主从节点offset
差距过大超过缓冲区长度时,将无法执行部分复制,只能执行全量复制。反过来说,为了提高网络中断时部分复制执行的概率,可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size);例如如果网络中断的平均时间是60s,而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB,则复制积压缓冲区的平均需求为6MB,保险起见,可以设置为12MB,来保证绝大多数断线情况都可以使用部分复制。
从节点将offset
发送给主节点后,主节点根据offset
和缓冲区大小决定能否执行部分复制:
- 如果
offset
偏移量之后的数据,仍然都在复制积压缓冲区里,则执行部分复制 - 如果
offset
偏移量之后的数据已不在复制积压缓冲区中(数据已被挤出),则执行全量复制
服务器运行ID
每个 Redis
节点,在启动时都会自动生成一个随机ID(每次启动都不一样),由40个随机的十六进制字符组成;runid
用来唯一识别一个 Redis
节点,通过 info server
命令,可以查看节点的 runid
root@32b70cb74b21:/data# redis-cli info server|grep run_id
run_id:289b0f664d2b04e4db54176be6e281b0f34faddc
复制代码
主从节点初次复制时,主节点将自己的 runid 发送给从节点,从节点将这个 runid 保存起来;当断线重连时,从节点会将这个 runid 发送给主节点;主节点根据 runid 判断能否进行部分复制:
- 如果从节点保存的runid与主节点现在的
runid
相同,说明主从节点之前同步过,主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset
和复制积压缓冲区的情况); - 如果从节点保存的
runid
与主节点现在的runid
不同,说明从节点在断线前同步的Redis
节点并不是当前的主节点,只能进行全量复制。
心跳机制
在命令传播阶段,从服务器默认会以每秒一次的频率,向主服务器发送命令:
REPLCONF ACK <replication_offset>
其中 <replication_offset>
是从服务器当前的复制偏移量,发送 REPLCONF ACK
对主从服务器有三个作用:
- 检测主从服务器的网络连接状态
- 辅助实现
min-slaves
选项 - 检测命令丢失
检测主从服务器的网络连接状态
该命令会被主节点用于复制超时的判断。此外,在主节点中使用 info Replication,可以看到其从节点的状态中的lag值,代表的是主节点上次收到该REPLCONF ACK命令的时间间隔,在正常情况下,该值应该是0或1,如果超过1s的话,那么说明主从服务器之间的连接发生了故障。
辅助实现 min-slaves
选项
Redis
主节点中使用min-slaves-to-write
和min-slaves-max-lag
参数,来保证主节点在不安全的情况下不会执行写命令;所谓不安全,是指从节点数量太少,或延迟过高。例如min-slaves-to-write
和min-slaves-max-lag
分别是3和10,含义是如果从节点数量小于3个,或所有从节点的延迟值都大于10s,则主节点拒绝执行写命令。而这里从节点延迟值的获取,就是通过主节点接收到REPLCONF ACK
命令的时间来判断的,即前面所说的info Replication
中的lag值
检测命令丢失
从节点发送了自身的offset
,主节点会与自己的offset
对比,如果从节点数据缺失(如网络丢包),主节点会推送缺失的数据(这里也会利用复制积压缓冲区)。注意, offset 和复制积压缓冲区,不仅可以用于部分复制,也可以用于处理命令丢失等情形;区别在于前者是在断线重连后进行的,而后者是在主从节点没有断线的情况下进行的