跳至主要內容

Redis高级-主从复制

清峰大约 21 分钟

Redis高级-主从复制

从真实的生产事故说起

2021年双11期间，某电商平台惊魂一刻

凌晨2:30，Redis主服务器突然崩溃。瞬间，整个电商系统陷入瘘痪：

  • 购物车服务不可用：用户无法添加、查看商品
  • 用户会话失效：大量用户被强制退出登录
  • 实时排行榜清空：双11热门商品榜单消失
  • 秒杀活动停止：无法获取库存信息

影响范围：

  • 直接损失：1.5小时服务不可用，损失订单800+万元
  • 间接损失：用户体验下降，品牌形象受损，后续运营成本增加

根因分析： 这起事故的根本原因是采用了单机 Redis 架构，没有任何冗余和备份机制。这正是Redis主从复制要解决的核心问题。

业务场景中的高可用需求

现代互联网应用的“三高”挑战

在构建高质量的互联网服务时，我们面临着“三高”架构的挑战：

主从复制概念

知道了三高的概念之后，我们想：你的“Redis”是否高可用？那我们要来分析单机redis的风险与问题

问题1.机器故障

  • 现象：硬盘故障、系统崩溃
  • 本质：数据丢失，很可能对业务造成灾难性打击
  • 结论：基本上会放弃使用redis.

问题2.容量瓶颈

  • 现象：内存不足，从16G升级到64G，从64G升级到128G，无限升级内存
  • 本质：穷，硬件条件跟不上
  • 结论：放弃使用redis

结论：

为了避免单点Redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份。

多台服务器连接方案：

  • 提供数据方：master

主服务器，主节点，主库主客户端

  • 接收数据方：slave

从服务器，从节点，从库从客户端

  • 需要解决的问题：

数据同步（master的数据复制到slave中）

这里我们可以来解释主从复制的概念：

概念：主从复制即将master中的数据即时、有效的复制到slave中

特征：一个master可以拥有多个slave，一个slave只对应一个master

职责：master和slave各自的职责不一样

master:

写数据

执行写操作时，将出现变化的数据自动同步到slave

读数据（可忽略）

slave:

读数据

写数据（禁止）

主从复制的作用

  • 读写分离：master写、slave读，提高服务器的读写负载能力
  • 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数 量，通过多个从节点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
  • 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
  • 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
  • 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

主从复制工作流程

主从复制过程大体可以分为3个阶段

  • 建立连接阶段（即准备阶段）
  • 数据同步阶段
  • 命令传播阶段（反复同步）

而命令的传播其实有4种，分别如下：

主从复制的工作流程（三个阶段）

阶段一：建立连接

建立slave到master的连接，使master能够识别slave，并保存slave端口号

流程如下：

  1. 步骤1：设置master的地址和端口，保存master信息
  2. 步骤2：建立socket连接
  3. 步骤3：发送ping命令（定时器任务）
  4. 步骤4：身份验证
  5. 步骤5：发送slave端口信息

至此，主从连接成功！

当前状态：

slave：保存master的地址与端口

master：保存slave的端口

总体：之间创建了连接的socket

阶段二：数据同步

全量同步和增量同步

  • 在slave初次连接master后，复制master中的所有数据到slave
  • 将slave的数据库状态更新成master当前的数据库状态

同步过程如下：

  1. 步骤1：请求同步数据
  2. 步骤2：创建RDB同步数据
  3. 步骤3：恢复RDB同步数据
  4. 步骤4：请求部分同步数据
  5. 步骤5：恢复部分同步数据

至此，数据同步工作完成！

当前状态：

slave：具有master端全部数据，包含RDB过程接收的数据

master：保存slave当前数据同步的位置

总体：之间完成了数据克隆

数据同步阶段master说明

1：如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行

2：复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，致使slave陷入死循环状态。

repl-backlog-size ?mb
  1. master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执 行bgsave命令和创建复制缓冲区

数据同步阶段slave说明

  1. 为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务
   slave-serve-stale-data yes|no

  1. 数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令

  2. 多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果master带宽不足，因此数据同步需要根据业务需求，适量错峰

  3. slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是 slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟 较大，数据一致性变差，应谨慎选择

阶段三：命令传播
  • 当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态，同步的动作称为命令传播
  • master将接收到的数据变更命令发送给slave，slave接收命令后执行命令

命令传播阶段的部分复制

命令传播阶段出现了断网现象：

网络闪断闪连：忽略

短时间网络中断：增量复制

长时间网络中断：全量复制

这里我们主要来看部分复制，增量复制的三个核心要素

  1. 服务器的运行 id（run id）
  2. 主服务器的复制积压缓冲区
  3. 主从服务器的复制偏移量
  • 服务器运行ID（runid）
概念：服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id

组成：运行id由40位字符组成，是一个随机的十六进制字符
例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce

作用：运行id被用于在服务器间进行传输，识别身份
如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别

实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发送给slave，
slave保存此ID，通过info Server命令，可以查看节点的runid
  • 复制缓冲区
概念：复制缓冲区，又名复制积压缓冲区，是一个先进先出（FIFO）的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
	复制缓冲区默认数据存储空间大小是1M
	当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列
作用：用于保存master收到的所有指令（仅影响数据变更的指令，例如set，select）

数据来源：当master接收到主客户端的指令时，除了将指令执行，会将该指令存储到缓冲区中

复制缓冲区内部工作原理：

组成

  • 偏移量

    概念：一个数字，描述复制缓冲区中的指令字节位置

    分类：

    • master复制偏移量：记录发送给所有slave的指令字节对应的位置（多个）
    • slave复制偏移量：记录slave接收master发送过来的指令字节对应的位置（一个）

    作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用

    数据来源：

    • master端：发送一次记录一次
    • slave端：接收一次记录一次

  • 字节值

工作原理

  • 通过offset区分不同的slave当前数据传播的差异
  • master记录已发送的信息对应的offset
  • slave记录已接收的信息对应的offset

流程更新(全量复制/增量复制)

我们再次的总结一下主从复制的三个阶段的工作流程：

心跳机制

什么是心跳机制？

进入命令传播阶段候，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线

master心跳：

  • 内部指令：PING
  • 周期：由repl-ping-slave-period决定，默认10秒
  • 作用：判断slave是否在线
  • 查询：INFO replication 获取slave最后一次连接时间间隔，lag项维持在0或1视为正常

slave心跳任务

  • 内部指令：REPLCONF ACK
  • 周期：1秒
  • 作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令
  • 作用2：判断master是否在线

心跳阶段注意事项：

  • 当slave多数掉线，或延迟过高时，master为保障数据稳定性，将拒绝所有信息同步
min-slaves-to-write 2
min-slaves-max-lag 8

slave数量少于2个，或者所有slave的延迟都大于等于8秒时，强制关闭master写功能，停止数据同步

  • slave数量由slave发送REPLCONF ACK命令做确认

  • slave延迟由slave发送REPLCONF ACK命令做确认

至此：我们可以总结出完整的主从复制流程：

主从复制常见问题

频繁的全量复制

  • 伴随着系统的运行，master的数据量会越来越大，一旦master重启，runid将发生变化，会导致全部slave的全量复制操作

内部优化调整方案：

1：master内部创建master_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave

2：在master关闭时执行命令shutdown save，进行RDB持久化,将runid与offset保存到RDB文件中

repl-id  repl-offset

通过redis-check-rdb命令可以查看该信息

3：master重启后加载RDB文件，恢复数据，重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中

master_repl_id=repl  master_repl_offset =repl-offset

通过info命令可以查看该信息

作用：本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master

  • 第二种出现频繁全量复制的问题现象：网络环境不佳，出现网络中断，slave不提供服务

问题原因：复制缓冲区过小，断网后slave的offset越界，触发全量复制

最终结果：slave反复进行全量复制

解决方案：修改复制缓冲区大小

repl-backlog-size ?mb

建议设置如下：

1.测算从master到slave的重连平均时长second

2.获取master平均每秒产生写命令数据总量write_size_per_second

3.最优复制缓冲区空间 = 2 * second * write_size_per_second

频繁的网络中断

  • 问题现象：master的CPU占用过高 或 slave频繁断开连接

问题原因

slave每1秒发送REPLCONFACK命令到master

当slave接到了慢查询时（keys * ，hgetall等），会大量占用CPU性能

master每1秒调用复制定时函数replicationCron()，比对slave发现长时间没有进行响应

最终结果：master各种资源（输出缓冲区、带宽、连接等）被严重占用

解决方案：通过设置合理的超时时间，确认是否释放slave

repl-timeout seconds

该参数定义了超时时间的阈值（默认60秒），超过该值，释放slave

  • 问题现象：slave与master连接断开

问题原因

master发送ping指令频度较低

master设定超时时间较短

ping指令在网络中存在丢包

解决方案：提高ping指令发送的频度

repl-ping-slave-period seconds

超时时间repl-time的时间至少是ping指令频度的5到10倍，否则slave很容易判定超时

数据不一致

问题现象：多个slave获取相同数据不同步

问题原因：网络信息不同步，数据发送有延迟

解决方案

优化主从间的网络环境，通常放置在同一个机房部署，如使用阿里云等云服务器时要注意此现象

监控主从节点延迟（通过offset）判断，如果slave延迟过大，暂时屏蔽程序对该slave的数据访问
slave-serve-stale-data	yes|no

开启后仅响应info、slaveof等少数命令（慎用，除非对数据一致性要求很高）

当主服务器不进行持久化时复制的安全性

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。

为什么不持久化的主服务器自动重启非常危险呢？为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。

  • 我们设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。
  • 这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。
  • 节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。
  • 当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。

如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。

为什么主从全量复制使用RDB而不使用AOF？

1、RDB文件内容是经过压缩的二进制数据（不同数据类型数据做了针对性优化），文件很小。而AOF文件记录的是每一次写操作的命令，写操作越多文件会变得很大，其中还包括很多对同一个key的多次冗余操作。在主从全量数据同步时，传输RDB文件可以尽量降低对主库机器网络带宽的消耗，从库在加载RDB文件时，一是文件小，读取整个文件的速度会很快，二是因为RDB文件存储的都是二进制数据，从库直接按照RDB协议解析还原数据即可，速度会非常快，而AOF需要依次重放每个写命令，这个过程会经历冗长的处理逻辑，恢复速度相比RDB会慢得多，所以使用RDB进行主从全量复制的成本最低。

2、假设要使用AOF做全量复制，意味着必须打开AOF功能，打开AOF就要选择文件刷盘的策略，选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量复制数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景，其实是不需要开启AOF的。

为什么还有无磁盘复制模式？

Redis 默认是磁盘复制，但是如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

无磁盘复制模式：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。适用于disk较慢，并且网络较快的时候。

使用repl-diskless-sync配置参数来启动无磁盘复制。

使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间；master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了; 否则就可以一起传。

为什么还会有从库的从库的设计？

通过分析主从库间第一次数据同步的过程，你可以看到，一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。

如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量复制。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。那么，有没有好的解决方法可以分担主库压力呢？

其实是有的，这就是“主 - 从 - 从”模式。

在刚才介绍的主从库模式中，所有的从库都是和主库连接，所有的全量复制也都是和主库进行的。现在，我们可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力，以级联的方式分散到从库上。

简单来说，我们在部署主从集群的时候，可以手动选择一个从库（比如选择内存资源配置较高的从库），用于级联其他的从库。然后，我们可以再选择一些从库（例如三分之一的从库），在这些从库上执行如下命令，让它们和刚才所选的从库，建立起主从关系。

replicaof 所选从库的IP 6379

这样一来，这些从库就会知道，在进行同步时，不用再和主库进行交互了，只要和级联的从库进行写操作同步就行了，这就可以减轻主库上的压力，如下图所示：

img
img

级联的“主-从-从”模式好了，到这里，我们了解了主从库间通过全量复制实现数据同步的过程，以及通过“主 - 从 - 从”模式分担主库压力的方式。那么，一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，可以避免频繁建立连接的开销。

读写分离及其中的问题

在主从复制基础上实现的读写分离，可以实现Redis的读负载均衡：由主节点提供写服务，由一个或多个从节点提供读服务（多个从节点既可以提高数据冗余程度，也可以最大化读负载能力）；在读负载较大的应用场景下，可以大大提高Redis服务器的并发量。下面介绍在使用Redis读写分离时，需要注意的问题。

  • 延迟与不一致问题

前面已经讲到，由于主从复制的命令传播是异步的，延迟与数据的不一致不可避免。如果应用对数据不一致的接受程度程度较低，可能的优化措施包括：优化主从节点之间的网络环境（如在同机房部署）；监控主从节点延迟（通过offset）判断，如果从节点延迟过大，通知应用不再通过该从节点读取数据；使用集群同时扩展写负载和读负载等。

在命令传播阶段以外的其他情况下，从节点的数据不一致可能更加严重，例如连接在数据同步阶段，或从节点失去与主节点的连接时等。从节点的slave-serve-stale-data参数便与此有关：它控制这种情况下从节点的表现；如果为yes（默认值），则从节点仍能够响应客户端的命令，如果为no，则从节点只能响应info、slaveof等少数命令。该参数的设置与应用对数据一致性的要求有关；如果对数据一致性要求很高，则应设置为no。

  • 数据过期问题

在单机版Redis中，存在两种删除策略：

  • 惰性删除：服务器不会主动删除数据，只有当客户端查询某个数据时，服务器判断该数据是否过期，如果过期则删除。
  • 定期删除：服务器执行定时任务删除过期数据，但是考虑到内存和CPU的折中（删除会释放内存，但是频繁的删除操作对CPU不友好），该删除的频率和执行时间都受到了限制。

在主从复制场景下，为了主从节点的数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略，都不能保证主节点及时对过期数据执行删除操作，因此，当客户端通过Redis从节点读取数据时，很容易读取到已经过期的数据。

Redis 3.2中，从节点在读取数据时，增加了对数据是否过期的判断：如果该数据已过期，则不返回给客户端；将Redis升级到3.2可以解决数据过期问题。

  • 故障切换问题

在没有使用哨兵的读写分离场景下，应用针对读和写分别连接不同的Redis节点；当主节点或从节点出现问题而发生更改时，需要及时修改应用程序读写Redis数据的连接；连接的切换可以手动进行，或者自己写监控程序进行切换，但前者响应慢、容易出错，后者实现复杂，成本都不算低。

默认页脚
Copyright © 2025 清峰