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

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

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

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

采取读写分离的模式：

你可以设想一下，不管是主库还是从库，都能接收客户端的写操作。那么，一个直接的问题就是：如果客户端对同一个数据（例如 k1）

前后修改了三次，每一次的修改请求都发送到不同的实例上，在不同的实例上执行，那么，这个数据在这三个实例上的副本就不一致了（分别是 v1、v2 和 v3）。在读取这个数据的时候，就可能读取到旧的值。

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

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

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

2.主配置文件：

3.两个从配置文件：

2.2 启动 Redis

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

相关视频推荐：

大厂秋招面试必备-从redis应用以及原理说起

redis如何实现分布式锁延时队列以及限流应用

90分钟搞定redis存储结构原理

LinuxC++后台服务器开发架构师免费学习地址

【文章福利】：小编整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！~点击加入（需要自取）

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

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

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

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

三个步骤完成了 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

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

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

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

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

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

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

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

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

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

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

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

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

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

原文:【Redis】Redis 主从复制 + 读写分离

侵删~