Redis——Redis主从架构原理

摘要

redis高并发与分布式系统的高并发之间的关系：大量使用redis技术的分布式系统，它的高并发能力与redis的高并发密切相关，因此要向提升分布式系统的高并发能力，就要提升redis在高并发场景下的性能。如果我们生产环境中使用的redis是单机的，那么redis的整体性能一定是有瓶颈的。单机的redis要想支撑超过10万+的QPS，是不太可能的，正常情况下单机的QPS在几万级别。。因此，我们说redis支撑高并发的瓶颈在于单机，那么如果redis要支撑10万+的并发，应该怎么做到呢？要想支撑10万+的QPS，我们可以通过基于一主多从的读写分离架构来实现，一台机器作为master，其他机器作为slave，写请求只通过master，slave用来接收读请求。项目中使用到redis的场景，一般是读多写少的，因此我们可以用多个slave来缓解读请求压力，达到支撑10万+读QPS的目的。需要说明的是，redis主从架构实现了读写分离，缓解了单机的读请求压力，提升了整个redis的读QPS。如果我们需要实现更高的读QPS，就可以加一些slave节点，所以我们说redis主从架构其实是可支持水平扩展的读高并发架构。

一、Redis的主从架构原理

在我们日常的业务开发中，经常会用到Redis，假设我们只有部署了一台Redis服务器，某个时刻Redis服务挂了，造成Redis不可用，在此期间，大量的请求将会直接打到数据库，数据库cpu飙升，严重的可能导致数据库直接挂掉，这就是我们经常说的单点故障。为了解决单点问题，一般都需要对redis 配置主从节点，那么redis主节点和从节点之间如何进行数据同步呢? Redis提供了主从复制机制，我个人认为它的作用有以下几点:1)数据冗余、2)单机故障、3)读写分离、4)负载均衡、5)高可用的基石

1.1 redis读写分离

在redis主从架构中，Master节点负责处理写请求，Slave节点只处理读请求。对于写请求少，读请求多的场景，例如电商详情页，通过这种读写分离的操作可以大幅提高并发量，通过增加redis从节点的数量可以使得redis的QPS达到10W+。

1.2 redis主从同步

Master节点接收到写请求并处理后，需要告知Slave节点数据发生了改变，保持主从节点数据一致的行为称为主从同步，所有的Slave都和Master通信去同步数据也会加大Master节点的负担，实际上，除了主从同步，redis也可以从从同步，我们在这里统一描述为主从同步。

二、Redis主从数据同步的方案

2.1 增量同步

redis 同步的是指令流，主节点会将那些对自己的状态产生修改性影响的指令记录在本地的内存 buffer 中，然后异步将 buffer 中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了 (偏移量，这是redis-2.8之后才有的特性)。从节点同步数据的时候不会影响主节点的正常工作，也不会影响自己对外提供读服务的功能，从节点会用旧的数据来提供服务，当同步完成后，需要删除旧数据集，加载新数据，这个时候才会暂停对外服务。

因为内存的 buffer 是有限的，所以 redis 主节点不能将所有的指令都记录在内存 buffer 中。redis 的复制内存 buffer 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

2.2 快照同步

如果节点间网络通信不好，当从节点同步的速度不如主节点接收新写请求的速度时，buffer 中会丢失一部分指令，从节点中的数据将与主节点中的数据不一致，此时将会触发快照同步。

快照同步是一个非常耗费资源的操作，它首先需要在主节点上进行一次 bgsave 将当前内存的数据全部快照到RDB文件中，然后再将快照文件的内容全部传送到从节点。从节点将RDB文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空。加载完毕后通知主节点继续进行增量同步。

在整个快照同步进行的过程中，主节点的复制 buffer 还在不停的往前移动，如果快照同步的时间过长或者复制 buffer 太小，都会导致同步期间的增量指令在复制 buffer 中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环。所以需要配置一个合适的复制 buffer 大小参数，避免快照复制的死循环。

2.3 无盘复制

主节点在进行快照同步时，会进行大量的文件 IO 操作，特别是对于非 SSD 磁盘存储时，快照会对系统的负载产生较大影响。特别是当系统正在进行 AOF 的 fsync 操作时如果发生快照复制，fsync 将会被推迟执行，这就会严重影响主节点的服务效率。

从 Redis 2.8.18 版开始支持无盘复制。所谓无盘复制是主节点会一边遍历内存，一遍将序列化的内容发送到从节点，而不是生成完整的 RDB 文件后才进行 IO 传输从节点还是跟之前一样，先将接收到的内容存储到磁盘文件中，再进行一次性加载。

2.4 主从同步的详细流程

• 在从节点的配置文件中的​​slaveof​​配置项中配置了主节点的IP和port后，从节点就知道自己要和那个主节点进行连接了。
• 从节点内部有个定时任务，会每秒检查自己要连接的主节点是否上线，如果发现了主节点上线，就跟主节点进行网络连接。注意，此时仅仅是取得连接，还没有进行主从数据同步。
• 从节点发送ping命令给主节点进行连接，如果设置了口令认证（主节点设置了requirepass），那么从节点必须发送正确的口令（masterauth）进行认证。
• 主从节点连接成功后，主从节点进行一次快照同步。事实上，是否进行快照同步需要判断主节点的​​run id​​​，当从节点发现已经连接过某个​​run id​​​的主节点，那么视此次连接为重新连接，就不会进行快照同步。相同IP和port的主节点每次重启服务都会生成一个新的​​run id​​​，所以每次主节点重启服务都会进行一次快照同步，如果想重启主节点服务而不改变​​run id​​​，使用​​redis-cli debug reload​​命令。
• 当开始进行快照同步后，主节点在本地生成一份rdb快照文件，并将这个rdb文件发送给从节点，如果复制时间超过60秒（配置项：repl-timeout），那么就会认为复制失败，如果数据量比较大，要适当调大这个参数的值。主从节点进行快照同步的时候，主节点会把接收到的新请求命令写在缓存 buffer 中，当快照同步完成后，再把 buffer 中的指令增量同步到从节点。如果在快照同步期间，内存缓冲区大小超过256MB，或者超过64MB的状态持续时间超过60s（配置项：​​client-output-buffer-limit slave 256MB 64MB 60​​），那么也会认为快照同步失败。
• 从节点接收到RDB文件之后，清空自己的旧数据，然后重新加载RDB到自己的内存中，在这个过程中基于旧的数据对外提供服务。如果主节点开启了AOF，那么在快照同步结束后会立即执行BGREWRITEAOF，重写AOF文件。
• 主节点维护了一个backlog文件，默认是1MB大小，主节点向从节点发送全量数据（RDB文件）时，也会同步往backlog中写，这样当发送全量数据这个过程意外中断后，从backlog文件中可以得知数据有哪些是发送成功了，哪些还没有发送，然后当主从节点再次连接后，从失败的地方开始增量同步。这里需要注意的是，当快照同步连接中断后，主从节点再次连接并非是第一次连接，所以进行增量同步，而不是继续进行快照同步。
• 快照同步完成后，主节点后续接收到写请求导致数据变化后，将和从节点进行增量同步，遇到 buffer 溢出则再触发快照同步。
• 主从节点都会维护一个offset，随着主节点的数据变化以及主从同步的进行，主从节点会不断累加自己维护的offset，从节点每秒都会上报自己的offset给主节点，主节点也会保存每个从节点的offset，这样主从节点就能知道互相之间的数据一致性情况。从节点发送​​psync runid offset​​命令给主节点从而开始主从同步，主节点会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制。
• 主从节点因为网络原因导致断开，当网络接通后，不需要手工干预，可以自动重新连接。
• 主节点如果发现有多个从节点连接，在快照同步过程中仅仅会生成一个RDB文件，用一份数据服务所有从节点进行快照同步。
• 从节点不会处理过期key，当主节点处理了一个过期key，会模拟一条del命令发送给从节点。
• 主从节点会保持心跳来检测对方是否在线，主节点默认每隔10秒发送一次heartbeat，从节点默认每隔1秒发送一个heartbeat。
• 建议在主节点使用AOF+RDB的持久化方式，并且在主节点定期备份RDB文件，而从节点不要开启AOF机制，原因有两个，一是从节点AOF会降低性能，二是如果主节点数据丢失，主节点数据同步给从节点后，从节点收到了空的数据，如果开启了AOF，会生成空的AOF文件，基于AOF恢复数据后，全部数据就都丢失了，而如果不开启AOF机制，从节点启动后，基于自身的RDB文件恢复数据，这样不至于丢失全部数据。

三、Redis的主从数据同步流程

​3.1 建立长连接

该阶段的主要作用是在主从节点之间建立连接，为数据全量同步做好准备。从库会和主库建立连接，从库执行 replicaof 并发送 psync 命令并告诉主库即将进行同步，主库确认回复后，主从库间就开始同步了。在从节点的配置文件中的 replicaof 配置项中配置了主节点的 IP 和 port 后，从节点就知道自己要和那个主节点进行连接了。从节点内部维护了两个字段，masterhost 和 masterport，用于存储主节点的 IP 和 port 信息。从库执行 ​​replicaof​​​ 并发送 ​​psync​​ 命令，表示要执行数据同步，主库收到命令后根据参数启动复制。命令包含了主库的 runID 和 复制进度 offset 两个参数。

• runID：每个 Redis 实例启动都会自动生成一个 唯一标识 ID，第一次主从复制，还不知道主库 runID，参数设置为 「?」。
• offset：第一次复制设置为 -1，表示第一次复制，记录复制进度偏移量。

主库收到 psync 命令后，会用 FULLRESYNC 响应命令带上两个参数：主库 runID 和主库目前的复制进度 offset，返回给从库。从库收到响应后，会记录下这两个参数。FULLRESYNC 响应表示第一次复制采用的全量复制，也就是说，主库会把当前所有的数据都复制给从库。

完成全量同步后，正常运行过程如何同步呢？

当主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，使用长连接的目的就是避免频繁建立连接导致的开销。在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING 和 REPLCONF ACK。

主发送PING给从：每隔指定的时间，主节点会向从节点发送 PING 命令，这个 PING 命令的作用，主要是为了让从节点进行超时判断。

从节点发主REPLCONF ACK命令：在命令传播阶段，从服务器默认会以每秒一次的频率，向主服务器发送命令：REPLCONF ACK <replication_offset>

其中 replication_offset 是从服务器当前的复制偏移量。发送 REPLCONF ACK 命令对于主从服务器有三个作用：

1. 检测主从服务器的网络连接状态。
2. 辅助实现 min-slaves 选项。
3. 检测命令丢失, 从节点发送了自身的 slave_replication_offset，主节点会用自己的 master\_replication\_offset 对比，如果从节点数据缺失，主节点会从 ​​repl_backlog_buffer​​缓冲区中找到并推送缺失的数据。注意，offset 和 repl_backlog_buffer 缓冲区，不仅可以用于部分复制，也可以用于处理命令丢失等情形；区别在于前者是在断线重连后进行的，而后者是在主从节点没有断线的情况下进行的。

3.2 全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。完成以下个步骤后就完成了从服务器数据初始化的所有操作，从服务器此时可以接收来自用户的读请求。

• 从服务器连接主服务器，发送SYNC命令； 
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令； 
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令； 
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令； 
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

3.3 增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。 增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

断开重连增量复制的实现奥秘就是 ​​repl_backlog_buffer​​​ 缓冲区，不管在什么时候 master 都会将写指令操作记录在 ​​repl_backlog_buffer​​​ 中，因为内存有限， ​​repl_backlog_buffer​​ 是一个定长的环形数组，如果数组内容满了，就会从头开始覆盖前面的内容。

master 使用 ​​master_repl_offset​​​记录自己写到的位置偏移量，slave 则使用 ​​slave_repl_offset​​​记录已经读取到的偏移量。master 收到写操作，偏移量则会增加。从库持续执行同步的写指令后，在 ​​repl_backlog_buffer​​ 的已复制的偏移量 slave_repl_offset 也在不断增加。

正常情况下，这两个偏移量基本相等。在网络断连阶段，主库可能会收到新的写操作命令，所以 ​​master_repl_offset​​​会大于 ​​slave_repl_offset​​。

当主从断开重连后，slave 会先发送 psync 命令给 master，同时将自己的 ​​runID​​​，​​slave_repl_offset​​​发送给 master。master 只需要把 ​​master_repl_offset​​​与 ​​slave_repl_offset​​之间的命令同步给从库即可。

主库将数据同步到从库过程中，可以正常接受请求么？

在生成 RDB 文件之后的写操作并没有记录到刚刚的 RDB 文件中，为了保证主从库数据的一致性，所以主库会在内存中使用一个叫 replication buffer 记录 RDB 文件生成后的所有写操作。

为啥从库收到 RDB 文件后要清空当前数据库？

因为从库在通过 ​​replcaof​​命令开始和主库同步前可能保存了其他数据，防止主从数据之间的影响。

replication buffer 到底是什么玩意？

一个在 master 端上创建的缓冲区，存放的数据是下面三个时间内所有的 master 数据写操作。

• 1）master 执行 bgsave 产生 RDB 的期间的写操作；
• 2）master 发送 rdb 到 slave 网络传输期间的写操作；
• 3）slave load rdb 文件把数据恢复到内存的期间的写操作。

Redis 和客户端通信也好，和从库通信也好，Redis 都分配一个内存 buffer 进行数据交互，客户端就是一个 client，从库也是一个 client，我们每个 client 连上 Redis 后，Redis 都会分配一个专有 client buffer，所有数据交互都是通过这个 buffer 进行的。Master 先把数据写到这个 buffer 中，然后再通过网络发送出去，这样就完成了数据交互。

不管是主从在增量同步还是全量同步时，master 会为其分配一个 buffer ，只不过这个 buffer 专门用来传播写命令到从库，保证主从数据一致，我们通常把它叫做 replication buffer。

replication buffer 太小会引发的问题：

replication buffer 由 client-output-buffer-limit slave 设置，当这个值太小会导致主从复制连接断开。

• 1）当 master-slave 复制连接断开，master 会释放连接相关的数据。replication buffer 中的数据也就丢失了，此时主从之间重新开始复制过程。
• 2）还有个更严重的问题，主从复制连接断开，导致主从上出现重新执行 bgsave 和 rdb 重传操作无限循环。

当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接；这种情况可能引起全量复制 -> replication buffer 溢出导致连接中断 -> 重连 -> 全量复制 -> replication buffer 缓冲区溢出导致连接中断的循环。

主从库复制为何不使用 AOF 呢？相比 RDB 来说，丢失的数据更少。

1. RDB 文件是二进制文件，网络传输 RDB 和写入磁盘的 IO 效率都要比 AOF 高。
2. 从库进行数据恢复的时候，RDB 的恢复效率也要高于 AOF。

repl_backlog_buffer 太小的话从库还没读取到就被 Master 的新写操作覆盖了咋办？

我们要想办法避免这个情况，一旦被覆盖就会执行全量复制。我们可以调整 repl\_backlog\_size 这个参数用于控制缓冲区大小。计算公式：

repl_backlog_buffer = second * write_size_per_second

1. second：从服务器断开重连主服务器所需的平均时间；
2. write_size_per_second：master 平均每秒产生的命令数据量大小（写命令和数据大小总和）；

例如，如果主服务器平均每秒产生 1 MB 的写数据，而从服务器断线之后平均要 5 秒才能重新连接上主服务器，那么复制积压缓冲区的大小就不能低于 5 MB。为了安全起见，可以将复制积压缓冲区的大小设为​​2 * second * write_size_per_second​​，这样可以保证绝大部分断线情况都能用部分重同步来处理。

如何确定执行全量同步还是部分同步？

在 Redis 2.8 及以后，从节点可以发送 psync 命令请求同步数据，此时根据主从节点当前状态的不同，同步方式可能是全量复制或部分复制。本文以 Redis 2.8 及之后的版本为例。关键就是 ​​psync​​的执行：

1. 从节点根据当前状态，发送 ​​psync​​命令给 master：

• 如果从节点从未执行过 ​​replicaof​​​ ，则从节点发送 ​​psync ? -1​​，向主节点发送全量复制请求；
• 如果从节点之前执行过 ​​replicaof​​​ 则发送 ​​psync <runID> <offset>​​, runID 是上次复制保存的主节点 runID，offset 是上次复制截至时从节点保存的复制偏移量。

2. 主节点根据接受到的​​psync​​命令和当前服务器状态，决定执行全量复制还是部分复制：

• runID 与从节点发送的 runID 相同，且从节点发送的 ​​slave_repl_offset ​​​之后的数据在 ​​repl_backlog_buffer ​​​缓冲区中都存在，则回复 ​​CONTINUE​​，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可；
• runID 与从节点发送的 runID 不同，或者从节点发送的 slave\_repl\_offset 之后的数据已不在主节点的 ​​repl_backlog_buffer ​​​缓冲区中 (在队列中被挤出了)，则回复从节点 ​​FULLRESYNC <runid> <offset>​​，表示要进行全量复制，其中 runID 表示主节点当前的 runID，offset 表示主节点当前的 offset，从节点保存这两个值，以备使用。

一个从库如果和主库断连时间过长，造成它在主库 ​​repl_backlog_buffer ​​的 slave\_repl\_offset 位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。

四、Redis主从架构的安全策略

master持久化对于主从架构的安全保障。

如果采用了主从架构，那么建议必须开启master node的持久化。不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，slave node数据也丢了。

我们设想一个场景，master关闭了RDB和AOF持久化，那么此时master中的数据全部在内存中；此时，master宕机重启后，本地磁盘中是没有数据可以恢复的，就会直接认为本地数据为空的，那么就会将空的数据集同步给slave，那么slave的数据会被全部清空，造成slave数据百分百丢失。因此我们一定要注意：master节点，必须要使用持久化机制

其次，master的各种备份方案，也是要做的，万一说本地的所有文件丢失了，我们还可以从备份中挑选一份rdb去恢复master，这样才能确保master启动的时候，是有数据的。

4.1 Redis的多副本原理

1. redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认自己每次复制的数据量
2. 一个master node可以配置多个slave node
3. slave node也可以连接其他的slave node
4. slave node做复制的时候，是不会block master node的正常工作的（异步）
5. slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了
6. slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量

每个从库会记录自己的 ​​slave_repl_offset​​，每个从库的复制进度也不一定相同。

在和主库重连进行恢复时，从库会通过 psync 命令把自己记录的 ​​slave_repl_offset​​发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

replication buffer 和 repl_backlog

1. replication buffer 对应于每个 slave，通过 ​​config set client-output-buffer-limit slave ​​设置。
2. ​​repl_backlog_buffer ​​是一个环形缓冲区，整个 master 进程中只会存在一个，所有的 slave 公用。repl_backlog 的大小通过 repl-backlog-size 参数设置，默认大小是 1M，其大小可以根据每秒产生的命令、（master 执行 rdb bgsave） +（ master 发送 rdb 到 slave） + （slave load rdb 文件）时间之和来估算积压缓冲区的大小，repl-backlog-size 值不小于这两者的乘积。

总的来说，​​replication buffer​​​ 是主从库在进行全量复制时，主库上用于和从库连接的客户端的 buffer，而 r​​epl_backlog_buffer​​​ 是为了支持从库增量复制，主库上用于持续保存写操作的一块专用 buffer。​​repl_backlog_buffer ​​​是一块专用 buffer，在 Redis 服务器启动后，开始一直接收写操作命令，这是所有从库共享的。主库和从库会各自记录自己的复制进度，所以，不同的从库在进行恢复时，会把自己的复制进度（​​slave_repl_offset​​）发给主库，主库就可以和它独立同步。

4.2 主从应用问题

数据过期问题,主从复制的场景下，从节点会删除过期数据么？

为了主从节点的数据一致性，从节点不会主动删除数据。我们知道 Redis 有两种删除策略：

1. 惰性删除：当客户端查询对应的数据时，Redis 判断该数据是否过期，过期则删除。
2. 定期删除：Redis 通过定时任务删除过期数据。

那客户端通过从节点读取数据会不会读取到过期数据？

Redis 3.2 开始，通过从节点读取数据时，先判断数据是否已过期。如果过期则不返回客户端，并且删除数据。

单机内存大小限制

如果 Redis 单机内存达到 10GB，一个从节点的同步时间在几分钟的级别；如果从节点较多，恢复的速度会更慢。如果系统的读负载很高，而这段时间从节点无法提供服务，会对系统造成很大的压力。

如果数据量过大，全量复制阶段主节点 fork + 保存 RDB 文件耗时过大，从节点长时间接收不到数据触发超时，主从节点的数据同步同样可能陷入全量复制->超时导致复制中断->重连->全量复制->超时导致复制中断的循环。

此外，主节点单机内存除了绝对量不能太大，其占用主机内存的比例也不应过大：最好只使用 50% - 65% 的内存，留下 30%-45% 的内存用于执行 bgsave 命令和创建复制缓冲区等。

博文参考

​​010.Redis 主从架构搭建及原理详解 - 简书​​