news 2026/4/17 22:49:22

NoSQL数据库Redis(三):主从复制

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
NoSQL数据库Redis(三):主从复制

Redis 主从复制详解

Redis 主从复制 (Replication) 是 Redis 实现高可用性 (High Availability)、数据冗余备份以及读写分离的核心机制之一。它允许一个 Redis 服务器(称为主节点,Master)将其数据实时或准实时地复制到一个或多个其他 Redis 服务器(称为从节点,Slave 或 Replica)。这种机制极大地增强了 Redis 的健壮性和扩展性。

一、 主从复制的结构

在 Redis 主从复制结构中,存在明确的角色划分:

  1. 主节点 (Master)

    • 唯一可写的节点:所有写操作(如SET,DEL,INCR等)必须发送到主节点执行。
    • 数据变更的源头:主节点负责处理客户端写请求,并将数据变更通过复制机制传播给所有从节点。
    • 可以连接多个从节点:一个主节点可以同时拥有多个从节点。
  2. 从节点 (Replica / Slave)

    • 只读节点(默认):通常情况下,从节点仅处理客户端的读请求(如GET,HGET,LRANGE等)。这是实现读写分离的基础。
    • 数据同步目标:从节点会连接到指定的主节点,并复制主节点的所有数据。
    • 可级联复制:一个从节点自身也可以作为其他从节点的主节点,形成树状或链状的复制结构(但通常不建议层级过深)。
    • 数据备份:从节点持有主节点数据的完整副本,是天然的备份节点。

结构示意图

+-----------------+ +-----------------+ +-----------------+ | | | | | | Client -->| Master Node |<-------| Replica Node 1 |<-------| Replica Node 3 | (Writes) | (Writable) | | (Read-Only) | | (Read-Only) | | |--------| | | | +-----------------+ +-----------------+ +-----------------+ | ^ | | v | +-----------------+ | | | | | Replica Node 2 |-----------+ | (Read-Only) | | | +-----------------+

在这个结构中:

  • 客户端将所有写请求发送到 Master。
  • 客户端可以将读请求分发到 Master 或任意一个 Replica (实现读写分离)。
  • Replica 1 和 Replica 2 直接复制 Master 的数据。
  • Replica 3 复制 Replica 1 的数据(级联复制)。

二、 主从复制的原理

Redis 主从复制的工作过程主要分为两个阶段:初始化同步命令传播

1. 初始化同步 (Initial Synchronization)

当一个新从节点启动或首次连接到主节点时,需要获取主节点数据的完整副本。这个过程称为初始化同步或全量同步。

步骤详解

  1. 从节点连接主节点:从节点通过配置(replicaof <masterip> <masterport>slaveof <masterip> <masterport>)连接到主节点,并发送PSYNC命令请求同步。
  2. 主节点生成 RDB 快照:主节点接收到PSYNC命令后,如果判断需要进行全量复制(例如,从节点是首次连接,或者复制偏移量不匹配),主节点会调用BGSAVE命令在后台生成一个 RDB 文件快照。生成 RDB 期间,主节点继续处理写命令。
  3. 主节点发送 RDB 文件:RDB 文件生成完成后,主节点将其发送给从节点。从节点会清空自己的旧数据,然后加载接收到的 RDB 文件来初始化自己的数据集。
  4. 主节点发送复制缓冲区命令:在生成和发送 RDB 文件期间,主节点处理的所有写命令会被记录在一个内存缓冲区中(称为复制积压缓冲区,Replication Backlog Buffer)。RDB 文件发送完成后,主节点会将这些缓冲区中的写命令发送给从节点执行。这一步确保了从节点在加载完 RDB 后,能追赶上主节点在生成 RDB 期间的最新数据状态。
  5. 进入命令传播阶段:完成上述步骤后,从节点的数据与主节点在开始生成 RDB 那一刻的数据保持一致。之后,主节点进入命令传播阶段,持续将后续接收到的写命令发送给从节点执行。

关键点

  • 初始化同步期间主节点需要生成 RDB,可能耗费较多 CPU 和 I/O 资源,并占用网络带宽传输 RDB 文件。
  • 复制积压缓冲区 (repl-backlog-size) 的大小配置很重要。如果缓冲区太小,在同步慢或断线重连时,可能因为缓冲区被覆盖而被迫再次进行全量同步。

2. 命令传播 (Command Propagation)

初始化同步完成后,主从节点进入命令传播阶段。在这个阶段,主节点会将其接收到的每一个写命令,以 Redis 协议的形式,异步地发送给所有连接的从节点执行。

  • 异步复制:主节点在自身执行完写命令后,会将该命令放入发送队列,然后立即响应客户端。命令的发送和从节点的执行是异步进行的。这意味着存在一个非常短暂的时间窗口(通常毫秒级),主节点的数据可能比从节点更新。这是 Redis 复制最终一致性的体现。
  • 增量复制:命令传播阶段就是增量复制的过程,每次只同步变更的命令。
  • 复制偏移量 (Replication Offset)
    • 主节点和每个从节点都维护一个复制偏移量。
    • 主节点每发送一个字节的数据(命令)给从节点,主节点的复制偏移量就会增加。
    • 从节点每接收并执行一个字节的数据(命令),从节点的复制偏移量就会增加。
    • 通过比较主从节点的复制偏移量,可以判断它们的数据是否一致。INFO replication命令可以查看偏移量信息。
  • 复制 ID (Replication ID):主节点启动时会生成一个唯一的复制 ID。这个 ID 与复制偏移量一起,用于标识一个特定的数据历史版本。当主节点重启(如故障切换后),复制 ID 会改变。

3. 部分重同步 (Partial Resynchronization)

当网络发生短暂中断或从节点短暂重启后重新连接主节点时,如果条件满足,Redis 会尝试进行部分重同步,避免代价高昂的全量同步。

前提条件

  • 从节点保存了之前连接主节点的复制 ID (master_replid) 和复制偏移量 (master_repl_offset)。
  • 主节点当前的复制 ID 没有改变(即主节点没有发生故障切换)。
  • 从节点断开期间丢失的数据(即从节点记录的master_repl_offset之后的数据)仍然存在于主节点的复制积压缓冲区中。

过程

  1. 从节点重新连接主节点,发送PSYNC <replid> <offset>命令,带上自己记录的复制 ID 和偏移量。
  2. 主节点检查:
    • 收到的复制 ID 是否与自己的当前复制 ID 匹配。
    • 请求的偏移量之后的数据是否还在自己的复制积压缓冲区中。
  3. 如果条件满足,主节点回复CONTINUE,表示可以进行部分重同步。然后主节点将复制积压缓冲区中从请求偏移量开始的所有数据发送给从节点。
  4. 从节点接收并执行这些命令,从而将数据同步到最新状态。
  5. 之后进入正常的命令传播阶段。

如果条件不满足(例如主节点复制 ID 变了,或者请求偏移量之前的数据已被覆盖),则主节点会回复FULLRESYNC <replid> <offset>,触发一次全量同步。

三、 主从复制的配置管理 (OpenEuler)

在 OpenEuler 系统上配置 Redis 主从复制,主要涉及修改 Redis 的配置文件redis.conf。以下列出关键配置项及其含义:

1. 主节点配置 (Master)

主节点的配置通常相对简单,主要是确保其可以接受连接并设置密码(如果需要认证)。关键配置项:

  • bind 0.0.0.0bind <specific_ip>:指定 Redis 监听的网络接口。0.0.0.0表示监听所有接口(生产环境建议绑定具体 IP)。
  • port 6379:监听端口,默认 6379。
  • requirepass <password>:设置主节点的访问密码。强烈建议设置强密码。从节点连接时需要用到这个密码。
  • masterauth <password>如果主节点自身也是另一个主节点的从节点(级联复制),则需要设置此项为它的主节点的密码。在纯主节点角色下,此项不需要配置。
  • maxmemory <bytes>:设置最大内存限制,根据服务器内存情况配置,避免 OOM。
  • repl-backlog-size <size>:设置复制积压缓冲区大小。默认1mb。在断线重连频繁或网络不稳定的场景下,建议增大此值(例如128mb256mb),以减少全量同步的概率。值越大,占用的内存越多。
  • repl-backlog-ttl <seconds>:设置复制积压缓冲区在没有从节点连接时的存活时间。默认3600秒(1小时)。超过此时间且无从节点连接,缓冲区会被释放。
  • repl-diskless-sync <yes|no>:是否使用无盘同步。默认no。设置为yes时,主节点在初始化同步时直接将 RDB 内容通过 Socket 发送给从节点,而先将 RDB 写入磁盘。这可以节省 I/O 和磁盘空间,但会消耗更多网络带宽。仅在网络速度非常快且磁盘 I/O 是瓶颈时才考虑启用
  • repl-diskless-sync-delay <seconds>:无盘同步时,等待更多从节点加入一起同步的延迟时间(秒)。默认5。可以分摊主节点生成 RDB 的负载。

2. 从节点配置 (Replica)

从节点需要明确指定其主节点。关键配置项:

  • replicaof <masterip> <masterport>slaveof <masterip> <masterport>:指定主节点的 IP 地址和端口。例如replicaof 192.168.1.100 6379。这是配置从节点的核心指令
  • masterauth <password>:设置用于连接主节点所需的密码。这个密码必须和主节点requirepass设置的密码一致。
  • replica-read-only yes:设置从节点是否为只读模式。默认yes强烈建议保持只读,除非有特殊需求。
  • repl-diskless-load <disabled|swapdb|on-start>:从节点在加载初始化同步的 RDB 时使用的策略。默认disabled(使用磁盘加载)。swapdb在加载时保持旧数据库可用(需要额外内存),on-start尝试从 Socket 直接加载(需要repl-diskless-sync yes且主节点支持)。一般保持默认disabled即可
  • 其他配置如bind,port,requirepass(用于保护从节点自身连接)等也需要根据实际情况配置。

配置生效:修改配置文件后,需要重启 Redis 服务使配置生效。OpenEuler 上通常使用systemctl

sudo systemctl restart redis # 或者指定配置文件路径,如果使用了非默认路径 sudo redis-server /path/to/redis.conf

查看复制状态:使用redis-cli连接 Redis 实例,执行INFO replication命令可以获取详细的复制信息,包括角色、连接状态、复制 ID、偏移量、从节点列表等。

四、 部署 Redis 主从复制实例 (OpenEuler)

假设我们有 3 台 OpenEuler 服务器:

  • master-node(IP: 192.168.1.100) - 主节点
  • replica-node1(IP: 192.168.1.101) - 从节点 1
  • replica-node2(IP: 192.168.1.102) - 从节点 2

步骤 1:安装 Redis

在所有三台服务器上安装 Redis。OpenEuler 通常可以通过dnf安装:

sudo dnf install redis -y

安装完成后,默认配置文件位于/etc/redis.conf

步骤 2:配置主节点 (master-node)

编辑/etc/redis.conf

sudo vim /etc/redis.conf

找到并修改以下配置项:

# 绑定地址 (根据实际情况修改) bind 0.0.0.0 # 或 bind 192.168.1.100 port 6379 # 设置密码 (替换 your_strong_password) requirepass your_strong_password # 可选:增大复制积压缓冲区 repl-backlog-size 128mb # 可选:禁用保护模式 (如果 bind 0.0.0.0 且不设密码,生产环境不建议) # protected-mode no # 仅在测试或安全网络环境中谨慎使用 # 确保 daemonize yes (后台运行) daemonize yes # 设置日志文件 logfile /var/log/redis/redis.log # 设置数据目录 dir /var/lib/redis

保存并退出。

创建日志和数据目录(如果不存在):

sudo mkdir -p /var/log/redis /var/lib/redis sudo chown redis:redis /var/log/redis /var/lib/redis # 确保 Redis 用户有权限

启动 Redis 服务:

sudo systemctl enable redis --now sudo systemctl status redis # 检查状态是否 active (running)

步骤 3:配置从节点 (replica-node1replica-node2)

分别在两台从节点服务器上编辑/etc/redis.conf

vim /etc/redis.conf

修改以下配置项:

bind 0.0.0.0 # 或绑定具体 IP port 6379 # 指定主节点和密码 (替换 master_ip, master_port, master_password) replicaof 192.168.1.100 6379 masterauth your_strong_password # 必须与主节点的 requirepass 一致 # 保持只读 replica-read-only yes # 设置从节点自身密码 (可选,保护从节点连接) requirepass replica_strong_password # 如果设置,客户端连接从节点时需要此密码 # 同样配置日志、数据目录等 daemonize yes logfile /var/log/redis/redis.log dir /var/lib/redis

保存并退出。

创建目录并设置权限:

sudo mkdir -p /var/log/redis /var/lib/redis sudo chown redis:redis /var/log/redis /var/lib/redis

启动 Redis 服务:

sudo systemctl enable redis --now sudo systemctl status redis

步骤 4:验证主从复制

  1. 连接主节点:在master-node或任何能访问主节点的机器上使用redis-cli

    redis-cli -h 192.168.1.100 -a your_strong_password

    执行命令:

    INFO replication

    查看输出:

    • role:master确认角色。
    • connected_slaves:2应该显示已连接的从节点数量。
    • slave0slave1部分,可以看到从节点的 IP、端口、状态 (online)、复制偏移量等信息。
  2. 连接从节点:连接其中一个从节点:

    redis-cli -h 192.168.1.101 -a your_strong_password # 或用从节点自身密码

    执行:

    INFO replication

    查看输出:

    • role:slave确认角色。
    • master_host:192.168.1.100,master_port:6379确认连接的主节点。
    • master_link_status:up表示连接正常。
    • master_last_io_seconds_ago值很小(通常 0 或 1)表示最近有通信。
    • master_sync_in_progress:0表示当前没有在进行全量同步。
    • 比较master_repl_offset和主节点上看到的对应从节点的slave_repl_offset,它们应该非常接近(最终一致)。
  3. 测试数据同步

    • 在主节点上写入数据:
      SET master_key "Hello from Master"
    • 在任意从节点上读取该数据:
      GET master_key # 应返回 "Hello from Master"
    • 尝试在从节点上写入:
      SET slave_key "Try write" # 应该会报错:(error) READONLY You can't write against a read only replica.
      验证了从节点的只读属性。

步骤 5:模拟故障转移 (高级)

  1. 主节点宕机:手动停止主节点的 Redis 服务 (master-node):
    sudo systemctl stop redis
  2. 观察从节点:连接一个从节点,执行INFO replication
    • master_link_status:down表示连接断开。
    • 客户端对从节点的读请求可能还能成功(取决于数据是否最新),但无法写入
  3. 手动切换主节点:选择一个从节点(如replica-node1)提升为新的主节点:
    • 连接到该从节点:
      redis-cli -h 192.168.1.101 -a your_strong_password
    • 执行命令使其停止复制并成为主节点:
      REPLICAOF NO ONE # 或 SLAVEOF NO ONE
    • 验证:
      INFO replication # role 应变为 master
  4. 重新配置其他从节点:将另一个从节点 (replica-node2) 指向新的主节点 (192.168.1.101):
    • 连接到replica-node2
      redis-cli -h 192.168.1.102 -a your_strong_password
    • 执行:
      REPLICAOF 192.168.1.101 6379
    • 验证INFO replication显示新的主节点信息且状态up
  5. 恢复原主节点:如果原主节点恢复,可以将其配置为当前新主节点 (192.168.1.101) 的从节点,或者根据需要进行其他处理。

注意:上述步骤 5 是手动故障转移。在生产环境中,通常使用Redis SentinelRedis Cluster来实现自动化的高可用和故障转移,避免人工干预。

五、 总结与注意事项

Redis 主从复制是构建高可用 Redis 架构的基础。在 OpenEuler 系统上部署时,需注意:

  1. 安全性:务必为主节点和从节点设置强密码 (requirepass),并在从节点配置masterauth。避免使用protected-mode no暴露无密码实例到公网。
  2. 配置优化:根据网络和负载情况调整repl-backlog-size。谨慎使用无盘复制 (repl-diskless-sync)。
  3. 监控:定期使用INFO replication监控主从状态、偏移量差异和连接健康状况。
  4. 只读从节点:保持replica-read-only yes是标准做法,除非有特殊需求。
  5. 高可用:主从复制本身不提供自动故障转移。对于生产环境,强烈建议结合 Redis Sentinel 或 Redis Cluster来实现主节点故障时的自动切换,保证服务连续性。
  6. 持久化:主从复制不是备份的替代品。仍然需要在主节点(或从节点)配置适当的 RDB 或 AOF 持久化策略,防止数据丢失。
  7. 网络:确保主节点和从节点之间的网络通信畅通且延迟低,以保证复制的实时性。
版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/17 22:47:18

JS垃圾回收机制

内存回收 内存回收:全局变量在关闭页面之前一般不会回收,局部变量会在使用完毕之后自动回收,若本该回收的变量无法回收或未回收叫内存泄露 内存泄漏:内存泄漏有多种情况非严格模式下变量忘记加var/let/const,导致隐式创建全局变量,挂载在window上,因为全局对象是根,不会被回收,…

作者头像 李华
网站建设 2026/4/17 22:47:03

告别C1083编译噩梦:从环境变量INCLUDE/LIB配置根治pip安装头文件缺失

1. 为什么pip安装时总报C1083头文件缺失错误&#xff1f; 每次用pip安装需要编译的Python包时&#xff0c;最怕看到的就是满屏红色报错&#xff0c;特别是那个经典的"C1083: 无法打开包括文件"。我刚开始接触Python开发时&#xff0c;为了装个pybullet库折腾了整整两…

作者头像 李华
网站建设 2026/4/17 22:45:19

【推荐算法】保序回归校准:从理论到广告混竞场景的平滑实践

1. 广告系统中的预估偏差问题 在广告推荐系统中&#xff0c;CTR&#xff08;点击率&#xff09;预估模型就像一位经验丰富的导购员&#xff0c;它能预测用户对每个广告的点击概率。但这位导购员有个小毛病&#xff1a;它给出的预估数字经常和实际情况有出入。比如它说"这个…

作者头像 李华
网站建设 2026/4/17 22:43:11

5分钟快速上手:开源视频智能分析工具的完整指南

5分钟快速上手&#xff1a;开源视频智能分析工具的完整指南 【免费下载链接】video-analyzer Analyze videos using LLMs, Computer Vision and Automatic Speech Recognition 项目地址: https://gitcode.com/gh_mirrors/vi/video-analyzer 在当今视频内容爆炸式增长的时…

作者头像 李华
网站建设 2026/4/17 22:42:32

深入解析RX/TX:通信世界的收发核心

目录 引言 RX/TX的基本概念与原理 定义与功能 信号转换原理 RX/TX在不同通信场景中的应用 有线通信 无线通信 卫星通信 RX/TX技术的发展趋势 高速化 集成化 智能化 结论 引言 在当今高度数字化、信息化的时代&#xff0c;通信技术如同神经脉络&#xff0c;将世界的各个角落…

作者头像 李华
网站建设 2026/4/17 22:41:37

Midscene.js(5):零基础上手 Android AI 自动化(YAML 版)「喂饭教程」

Midscene.js(5):零基础上手 Android AI 自动化(YAML 版)「喂饭教程」 引言 一、什么是 Midscene.js? 二、环境准备 2.1 系统要求 2.2 安装 Node.js 2.3 配置 ADB 2.3 开启手机 USB 调试模式 2.4 安装 Midscene CLI 三、配置 AI 模型 3.1 创建项目目录 3.2 配置环境变量 四…

作者头像 李华