Redis 的数据持久化技术，可以解决机器宕机，数据丢失的问题，并没有从根本上解决 Redis 的可用性。我们需要的是解决 Redis 的高可用，减少甚至避免 Redis 服务发生宕机的可能，来从根本上解决数据丢失问题。

目前实现Redis高可用的模式主要有三种： 主从模式、哨兵模式、集群模式。这篇文章我们来一起学习主从模式。

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

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

采取读写分离的模式：

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

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

你可以设想一下，不管是主库还是从库，都能接收客户端的写操作。那么，一个直接的问题就是：如果客户端对同一个数据（例如 k1）前后修改了三次，每一次的修改请求都发送到不同的实例上，在不同的实例上执行，那么，这个数据在这三个实例上的副本就不一致了（分别是 v1、v2 和 v3）。在读取这个数据的时候，就可能读取到旧的值。

如果我们非要保持这个数据在三个实例上一致，就要涉及到加锁、实例间协商是否完成修改等一系列操作，但这会带来巨额的开销，当然是不太能接受的。

而主从库模式一旦采用了读写分离，所有数据的修改只会在主库上进行，不用协调三个实例。主库有了最新的数据后，会同步给从库，这样，主从库的数据就是一致的。

那么，主从库同步是如何完成的呢？主库数据是一次性传给从库，还是分批同步？要是主从库间的网络断连了，数据还能保持一致吗？下面我们来一起学习。

1. 创建目录

mkdir -p /data/redis/master/data
mkdir -p /data/redis/slave1/data
mkdir -p /data/redis/slave2/data

2. 主配置文件：

bind 0.0.0.0
port 6379
daemonize yes
requirepass "123456"
logfile "/usr/local/redis/log/redis1.log"
dbfilename "pointer1.rdb"
dir "/usr/local/redis/data"
appendonly yes
appendfilename "appendonly1.aof"
masterauth "123456"

3. 两个从配置文件：

bind 0.0.0.0
port 6380
daemonize yes
requirepass "123456"
logfile "/usr/local/redis/log/redis2.log"
dbfilename "pointer2.rdb"
dir "/usr/local/redis/data"
appendonly yes
appendfilename "appendonly2.aof"

# 从本机 6379 的 redis 实例复制数据，Redis 5.0 之前使用 slaveof
replicaof 8.129.113.233 6379
# 从节点开启只读模式（默认）
replica‐read‐only yes
# 从节点访问主节点的密码，和 requirepass ⼀样
masterauth "123456"

bind 0.0.0.0
port 6381
daemonize yes
requirepass "123456"
logfile "/usr/local/redis/log/redis3.log"
dbfilename "pointer3.rdb"
dir "/usr/local/redis/data"
appendonly yes
appendfilename "appendonly3.aof"

# 从本机 6379 的 redis 实例复制数据，Redis 5.0 之前使用 slaveof
replicaof 8.129.113.233 6379
# 从节点开启只读模式（默认）
replica‐read‐only yes
# 从节点访问主节点的密码，和 requirepass ⼀样
masterauth "123456"

# 启动主
./redis-server /data/redis/master/data/redis.conf
# 启动从
./redis-server /data/redis/slave1/data/redis.conf
# 启动从
./redis-server /data/redis/slave2/data/redis.conf

主从复制分两种：主从刚连接的时候，进⾏全量同步；全量同步结束后，进⾏增量同步。

• 全量同步 - 首次配置完成，主从库连接之后；

• 增量同步 - 全量同步结束后

  • 准实时同步 - 主从正常运行期间；
  • Append增量数据 + 准实时同步 - 主从库间网络断开重连。

主从库第一次复制过程大体可以分为 3 个阶段：准备阶段（即建立连接准备）、主库同步数据到从库阶段、发送同步期间增量指令到从库的阶段。

这个阶段的主要作用是建立主从之间的连接，连接成立之后，才能够做数据全量同步。主要包含如下步骤：

1. 从节点的配置文件中的 replicaof 配置项中配置了主节点的 ip 和 port ，配置完成之后，从节点就知道要跟哪个主节点进行连接；

2. 当连接成功之后，从库开启 replicaof 操作，同时发送 psync 指令告诉主库，我准备开始同步了。命令包含了主库的 runID 和 复制进度 offset 两个参数；

   • runID：每个 Redis 实例启动都会自动生成一个唯一标识 ID，第一次主从复制，还不知道主库 runID，所以参数会默认设置为：?；
   • offset：因为第一次复制，没有偏移量，所以默认设置为 -1，这样就默认从第1条指令开始复制；

3. 主库收到 psync 命令后根据参数启动复制，使用 FULLRESYNC 响应命令，同时带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库；

4. 从库收到响应后，记录下这两个参数。

1. master 执行 bgsave 命令生成 RDB 文件，并将文件发送给从库，从库收到 RDB 文件后保存到磁盘，清空当前 Redis 库中的数据，再将 RDB 文件数据加载到内存中。

2. 同时主库为每一个 slave 开辟一块 replication buffer 缓冲区记录，用于记录主库生成 RDB 文件后那段时间（那段时间的产生的写命令没有被记录到 RDB 文件中，但是主库又会源源不断的接收到新的请求指令，记录缓冲区是为了保证数据不丢失）产生的所有写指令。

1. 在 主库同步数据给从库 整个初始化工作完成之后，继续执行从 replication buffer 缓冲区发送过来的数据，避免数据断层。

2. 主数据同步到从库的过程中，主库不会被阻塞，可以正常处理其他任意操作，这也是 Redis 保证高性能的必备条件。

3. replication buffer 缓冲区创建在 master 主库上，存放的数据是下面三个时间内 master 数据的所有写操作。

   • master 执行 bgsave 生产 rdb 的期间的写操作；
   • master 传输 rdb 文件到 slave 期间的写操作；
   • slave 加载 rdb 文件将数据初始化到内存期间的写操作。

三个步骤完成了 Redis 主从的全量复制。这边需要注意的是，Redis 中的通信，无论是主库跟从库之间，还是与客户端之间的数据交互。本质上都是通过分配内存 buffer 来进行的，Master 会先把数据写到 buffer 中，再通过网络发送出去，从而完成数据交互。

RDB 文件作为二进制文件，无论是网络传输还是写入时的磁盘IO，效率都要比 AOF 高很多。同样的，从库进行数据恢复的时候，效率也会高一些。所以我们会选择 RDB 文件做同步而不是 AOF 模式。

在网络断开之后或者从实例服务故障恢复之后，主从库会采用增量复制的方式继续同步，而不是全量同步的模式，这样会大大降低开销，提升效率。

增量复制： 就是指网络中断或者从库重启等情况后的复制，只将中断期间主节点执行的写命令发送给从节点，与全量复制相比更加高效。

主从库重新连接之后可以实现增量复制。关键就在 repl_backlog_buffer 缓冲区上面。

因为 master 会将写指令操作记录在 repl_backlog_buffer 缓冲区中，并使用 master_repl_offset 记录 master 写入的位置偏移量，slave 则使用 slave_repl_offset 记录读的偏移量。master 新增写操作的时候，偏移量则会增加。从库持续执行同步的写指令后，slave_repl_offset 也会不断增加。一般情况下，这两个偏移量会保持同步，如下图左。

但是网络断开或者从库故障期间，主实例 Redis 一般会收到新的写操作命令，但从实例则暂停执行，所以 master_repl_offset 会大于 slave_repl_offset。如下图右。

需要注意的是， repl_backlog_buffer 并不是如图中显示的貌似无限队列的模式，而是一个类似环形数组，如果数组内容满了，就会从头开始覆盖前面的内容，因为给到的内存空间是有限的。

在主从之间重新连接之后，slave 会先发送 psync 命令给 master，同时将自己的 {runID,slave_repl_offset} 两个参数发送给 master。master 只需要把 master_repl_offset 与 slave_repl_offset 之间的命令同步给从库即可。增量复制的流程类似如下：

在配置repl_backlog_buffer 的时候，需要综合考虑各种因素，太大了会导致增量执行周期比较长，还不如RDB全量覆盖。太小了有可能从库还没读取到就被 Master 的新写操作覆盖了，那样也只能执行全量复制。

所以我们需要给出一个合理缓冲区size。一般有如下的计算公式共参考：repl_backlog_buffer_size = seconds * write_size_per_second

• seconds：正常情况下从库断开，到重连主库所需的平均时间，秒为单位。

• write_size_per_second：主库平均每秒产生的写命令数据量大小。

如：主服务器大约每秒产生 0.5MB 的写指令数据，而断开到重连一般需要 30s，那么缓冲区的大小就是 0.5 * 30s = 15 MB。

但是我们一般会保留一点buffer，比如预留 0.5 倍，那就是 ： 1.5 * 15 MB = 22.5 MB 。

上面的工作都是为了完成完整复制，那在完成全量复制之后，主从开始进入正常有序的同步了，具体应该怎么做呢？

主从完成全量复制之后，他们之间需要保持连接。当主库收到操作指令的时候，通过这个连接同步给从库，这个过程称之为：基于长连接的命令传播。

为了保证传播的有效性和稳定性，从节点采用心跳机制进行侦测，发送命令：PING 和 REPLCONF ACK。

每隔指定的时间（比如 1 分钟，可配置），主节点会向从节点发送 PING 命令，侦测从节点有无超时来判断从节点的健康情况。

命令执行传播的阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令，将复制的偏移量发送过去。

• REPLCONF ACK <replication_offset>

replication_offset 的属性指的是当前从实例服务器的复制偏移量。

• 从实例发送 REPLCONF ACK 命令对于主要实例，主要有以下作用：

  • 检测主从服务器的网络通路是否正常。

  • 辅助实现 min-slaves 选项，使用 Redis 的 min-slaves-to-write（少于n个从实例时，拒绝执行写命令） 和 min-slaves-max-lag（主从延迟大于等于n秒时，拒绝执行写命令）两个选项可以防止主服务器在不安全的情况下执行写命令。

  • 检测命令丢失, 从节点发送了 slave_replication_offset，主节点会对比 master_replication_offset ，如果不一致，说明从节点数据缺失，主节点会从 repl_backlog_buffer 缓冲区中找到并推送缺失的数据。

主从复制的作用一个是为分担读写压力，均衡负载，另一个是为了保证部分实例宕机之后服务的持续可用性，所以 Redis 演变出主从架构和读写分离。

主从复制的步骤包括：建立连接的阶段、数据同步的阶段、基于长连接的命令传播阶段。

数据同步可以分为全量复制和部分复制，全量复制一般为第一次全量或者长时间主从连接断开。

命令传播阶段主从节点之间有 PING（主到从的的探测） 和 `REPLCONF ACK（从到主的ack应答） 命令，这种互相确认心跳的模式保证数据同步的稳定性。

主从模式是比较低级的可用性优化，要做到故障自动转移，异常预警，高保活，还需要更为复杂的哨兵或者集群模式。