Redis高可用之主从复制架构（第一部分）

引言

之前的文章 Redis持久化策略AOF、RDB详解及源码分析，我们介绍了Redis中的数据持久化技术，包括 RDB快照 和 AOF日志以及混合持久化 。有了持久化技术，我们就不用担心因Redis所在服务机器宕机，导致数据丢失。但是，持久化技术只是解决了Redis服务宕机后，数据的快速回复问题。并没有从根本上提高Redis的可用性。Redis提供的高可用主要分为：主从模式、哨兵模式和集群模式三种模式。这三种模式我会分为三部分介绍，今天我们就来聊一聊Redis的主从模式。

什么是高可用（分布式的概念）

假设，你的服务系统依赖于redis服务的数据。当Redis出现宕机时，就会导致你的服务系统不可用，这时就需要保证redis的高可用。简单来说就是：一个服务坏了，其他提供相同功能的服务可以顶替之前的服务继续对外提供服务，那么考虑，这些替补服务需要满足哪些条件呢？

1. 数据同步，与当前提供服务的数据一致或者接近一致，这些服务就要进行数据同步；
2. 如何切换，如何告诉对方，服务的提供者换成替补了？

高可用高的程度是由主从切换的时间决定的。通常要达到秒级別的切换。

同步复制和异步复制

• 同步复制：客户端向主服务器修改数据库数据的命令，主服务器再执行完后，需要等待所有的从数据库都同步完成后才返回给客户端。优点：主从高度一致，数据可靠；缺点：每次都需要等待所有的从数据库完成同步，效率低。
• 异步复制：客户端向主服务器修改数据库数据的命令，主服务器再执行完后立即返回给客户端。从服务器与主服务器建立连接，异步从主服务器同步数据。优点：服务的吞吐量高，响应速度快；缺点：数据可能不一致，redis采用的是异步复制。

一、主从复制

Redis 提供的主从模式，是通过复制的方式，将主服务器上的Redis的数据同步复制一份到从 Redis 服务器，这种做法很常见，MySQL的主从也是这么做的。

主节点的Redis我们称之为master，从节点的Redis我们称之为slave，主从复制为单向复制，只能由主到从，不能由从到主。可以有多个从节点，比如1主3从甚至n从，从节点的个数需要根据实际的业务需求来确定。

1.3 主从数据一致性

为了保证主服务器Redis的数据和从服务器Redis的数据的一致性，也为了分担访问压力，均衡负载，应用层面一般采取读写分离的模式。

读操作：主、从库都可以执行，一般是在从库上读数据，对实时性和准确性有100%高真要求的部分业务，可以谨慎评估之后读主库；

写操作：只在主库上写数据，写完之后将写操作指令同步到从库。

二、主从复制搭建

主从复制的搭建完全是在从服务器上配置和发起的，主服务器不需要做任何事。在Redis5.0之前是slaveof < masterip > < masterport >。

2.1 配置文件的方式

在从服务器的 redis.conf 配置文件中加入：

replicaof <masterip> <masterport>

2.2 启动命令的方式

在 redis-server 命令后面加上–replicaof < masterip > < masterport >

比如：

redis-server --replicaof 127.0.0.1  6379

2.3 在服务器客户端通过命令的方式

replicaof <masterip> <masterport>

三、主从复制原理

1.1 复制功能实现

Redis复制功能分为同步和命令传播两个部分：

• 同步操作用于将从服务器的数据库状态更新至和主服务器当前一致的状态，这一步主要是同步主服务器发过来的RDB文件；
• 命令传播操作用于将主服务器开启RDB文件同步后，执行的写命令传播给从服务器，从服务器再完成RDB文件同步后，继续执行这些写命令，从而达到与主服务器一致的状态。

Redis中从服务器对主服务的复制主要分为以下两种情况：

1. 从服务器之前没有复制过任何主服务器，或者从服务器当前要复制的主服务器与之前复制的不是同一个主服务器。
2. 断线后的重连：处于命令传播阶段的主从服务器主要因为网络原因而中断了复制，从服务器通过自动重连到主服务继续进行复制。

1.2 复制流程

1. 客户端通过 redis-server --replicaof master:ip master:port 指定要复制的主服务器
2. 从服务器与主服务器建立网络连接
3. 从服务器向主服务器发送PSYNC 命令
4. 主服务器收到PSYNC命令，执行BGSAVE命令，通过fork进程在子进程中生成RDB文件，并使用一个缓冲区专门记录从现在开始执行的写命令
5. 当主服务器BGSAVE命令执行结束，主服务器会将该RDB文件发送给从服务器，从服务器接收并载入这个RDB文件，将自己的数据库状态更新至与主服务器执行BGSAVE命令时一致的状态
6. 主服务器将记录在缓冲区的写命令发送给从服务器，从服务器执行这些命令达到与主数据库数据一致

PSYNC命令是一个非常耗费资源的操作：

1. 对于主服务器来说，需要执行BGSAVE命令来生成RDB文件，这会耗费主服务大量的CPU、内存及磁盘IO资源
2. 在BGSAVE命令完成后，还需要将RDB文件发送给从服务器，这会占用主从服务器大量的网络资源（带宽和流量），影响主服务器的命令响应时间
3. 对于从服务来说，在载入RDB文件期间，会因为阻塞而无法处理命令请求

所以Redis要保证在需要的时候才执行PSYNC命令。

1.3 Redis复制策略

Redis 内部使用PSYNC命令来执行复制操作。PSYNC命令具有 全量数据同步 和 增量数据同步 两种模式。全量数据复制很好理解，从服务器需要从头开始复制主服务器的数据；增量数据复制主要用在主从服务器因为网络问题导致的复制中断，在从服务器重新连接到主服务器进行的操作，此时，从服务器只需要执行在断开期间主服务器执行的写命令即可。

增量数据同步的实现，主要由三部分组成：

1. 主服务器和从服务器的复制偏移量：主服务器和从服务器会分别维护一个复制偏移量。主服务器每次在向从服务器传播N个字节的数据，就将自己的偏移量加N；从服务器在收到主服务器N个字节的数据后，会给自己的偏移量加N。如果主从服务器的数据是一致的，那么主从服务器的偏移量总是相同的。相反，说明主从服务器数据不一致。
   
   
2. 主服务的复制积压缓冲区
   主服务器维护了一个固定长度的队列，默认大小1MB。当主服务器执行命令传播是，不仅会将写命令发给所有的从服务器，还会将写命令写入到复制积压缓冲区中。缓冲区会为队列中的每个字节记录响应的复制偏移量。当从服务器重新连接上主服务器时，从服务器通过PSYNC命令将自己的偏移量offset发给主服务器，主服务器会根据这个偏移量决定执行何种同步操作：如果offset+1开始的数据仍然存在于缓冲区，则执行增量数据同步，否则执行全量数据同步。
   如果服务器需要执行大量的写命令，又或者主从断线后要经过很长的时间才能重新建立连接，那么就需要增大缓冲区的大小。可以根据以下公式来估算积压缓冲区的大小：buffer_size = 2* second * write_size_per_second，second是主从断线重连的平均时间，单位s，write_size_per_second是主服务器平均每秒产生的写命令（协议格式的写命令）的数据量。
   
3. 服务器的运行ID
   每个Redis服务器，无论是主服务器还是从服务器，都有自己的运行ID。运行ID在服务器启动时自动生成，由40位随机的十六进制字符组成。当从服务器初次对主服务进行复制时，主服务器会将自己的运行ID发给从服务器，从服务器保存。当出现重连时，从服务器会将自己保存的运行ID发送给主服务器，主服务器拿到运行ID与自己的ID进行比较，如果相等并且offset+1的数据还在积压缓冲区中，则执行增量数据同步，否则执行全量数据同步。
   

四、PSYNC命令实现

replicaof 是异步命令，在从服务器完成“masterhost”和“masterport”的设置后，从服务向发送replicaof 的客户端回复OK，表示指令已经接收，而实际的复制是在返回OK后才开始执行：

• 从服务器根据设置的主服务器的地址和端口，建立套接字连接，如果建立成功；
• 向主服务器发送PING命令，检车网络状态和主服务器能否正常处理命令请求，如果主服务器返回PONG，继续执行，否则从服务器主动断开连接，重新建立套接字连接。
• 是否需要身份认证，主要取决于主服务器的requirepass和从服务器的masterauth字段，如果需要验证，从服务会发送AUTH + masterauth。主服务器会将该值与自己的requirepass比较，相同则通过验证
• 从服务器向主服务器发送自己监听的端口，让主服务器连接，通过这个连接同步数据；
• 从服务器向主服务器发送PSYNC命令，开始执行同步操作。注意：在这一步后，主服务器也充当的是从服务器的客户端，因为只有成为从服务器的客户端，主服务器才能将缓冲区中的命令发送给从服务器执行。
• 在完成了同步的操作后，主从服务器就会进入到命令传播阶段，这时主服务器只需一直将自己执行的写命令发送给从服务器，从服务器执行，就可以保证主从服务器数据一致。

心跳检测

在命令传播阶段，为了监测主从复制的情况，从服务器默认会以每秒一次的频率像主服务器发送命令（心跳检测）：REPLCONF ACK  ，replication_offset是自己得复制偏移量。主要有三个作用：

（1）检测主从服务器的网络连接：如果主服务器超过1s，没有收到从服务器的REPLCONF ACK 命令，则主服务器就知道从服务器的连接出了问题，可以通过向主服务器发送 INFO replication命令，在列出的从服务器烂中，通过lag字段可以知道从服务器最后一次给主服务器发送REPLCONF ACK命令距离现在过去了多少秒。

（2）辅助实现min-slaves配置选项，redis.conf配置文件中min-slaves-to-write和min-slaves-max-lag两个选项可以防止主服务器在不安全的情况下执行写命令。简单来说就是，从服务器的数量不够了，或者每个从服务器的lag太大了，都会停止复制。

（3）检测命令丢失，如果因为网络问题导致主服务器发给从服务器的写命令丢失，主服务器通过replication_offset就知道命令丢了，去积压缓冲区找到重新发给从服务器。

五、主从模式的缺点

主从模型只解决了单点故障问题，没有主动通知机制，需要手动切换，仍然不是高可用，但是主从模型为高可用的实现已经打下了坚实的基础。后面两篇即将介绍的哨兵模式和集群模式实现了真正的高可用。

推荐一个零声学院免费教程，个人觉得老师讲得不错，分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK等技术内容，点击立即学习: