redis深度系统学习三:主从复制的原理与注意事项

前言

在前面的两篇文章中,分别介绍了Redis的内存模型Redis的持久化

在Redis的持久化中曾提到,Redis高可用的方案包括持久化、主从复制(及读写分离)、哨兵和集群。其中持久化侧重解决的是Redis数据的单机备份问题(从内存到硬盘的备份);而主从复制则侧重解决数据的多机热备。此外,主从复制还可以实现负载均衡和故障恢复。

这篇文章中,将详细介绍Redis主从复制的方方面面,包括:如何使用主从复制、主从复制的原理(重点是全量复制和部分复制、以及心跳机制)、实际应用中需要注意的问题(如数据不一致问题、复制超时问题、复制缓冲区溢出问题)、主从复制相关的配置(重点是repl-timeout、client-output-buffer-limit slave)等。


目录

一、主从复制概述

二、如何使用主从复制

    1.    建立复制

    2.    实例

    3.    断开复制

三、主从复制的实现原理

    1.    连接建立阶段

    2.    数据同步阶段

    3.    命令传播阶段

四、【数据同步阶段】全量复制和部分复制

    1.    全量复制

    2.    部分复制

    3.    psync命令的执行

    4.    部分复制演示

五、【命令传播阶段】心跳机制

    1.    主->从:PING

    2.    从->主:REPLCONF ACK

六、应用中的问题

    1.    读写分离及其中的问题

    2.    复制超时问题

    3.    复制中断问题

    4.    各场景下复制的选择及优化技巧

    5.    复制相关的配置

    6.    单机内存大小限制

    7.    info Replication

七、总结


一、主从复制概述

主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。

默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。

主从复制的作用

主从复制的作用主要包括:

  1. 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
  2. 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
  3. 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
  4. 高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

二、如何使用主从复制

为了更直观的理解主从复制,在介绍其内部原理之前,先说明我们需要如何操作才能开启主从复制。

1. 建立复制

需要注意,主从复制的开启,完全是在从节点发起的;不需要我们在主节点做任何事情。

从节点开启主从复制,有3种方式:

(1)配置文件

在从服务器的配置文件中加入:slaveof <masterip> <masterport>

(2)启动命令

redis-server启动命令后加入 --slaveof <masterip> <masterport>

(3)客户端命令

Redis服务器启动后,直接通过客户端执行命令:slaveof <masterip> <masterport>,则该Redis实例成为从节点。

上述3种方式是等效的,下面以客户端命令的方式为例,看一下当执行了slaveof后,Redis主节点和从节点的变化。

2. 实例

准备工作:启动两个节点

方便起见,实验所使用的主从节点是在一台机器上的不同Redis实例,其中主节点监听6379端口,从节点监听6380端口;从节点监听的端口号可以在配置文件中修改:

启动后可以看到:

两个Redis节点启动后(分别称为6379节点和6380节点),默认都是主节点。

建立复制

此时在6380节点执行slaveof命令,使之变为从节点:

观察效果

下面验证一下,在主从复制建立后,主节点的数据会复制到从节点中。

(1)首先在从节点查询一个不存在的key:

(2)然后在主节点中增加这个key:

(3)此时在从节点中再次查询这个key,会发现主节点的操作已经同步至从节点:

(4)然后在主节点删除这个key:

(5)此时在从节点中再次查询这个key,会发现主节点的操作已经同步至从节点:

3. 断开复制

通过slaveof <masterip> <masterport>命令建立主从复制关系以后,可以通过slaveof no one断开。需要注意的是,从节点断开复制后,不会删除已有的数据,只是不再接受主节点新的数据变化。

从节点执行slaveof no one后,打印日志如下所示;可以看出断开复制后,从节点又变回为主节点。

主节点打印日志如下:

推荐一下自己的linuxC/C++交流群:973961276!整理了一些个人觉得比较好的学习书籍、视频资料以及大厂面经视频,有需要的小伙伴可以进群获取哦! 

三、主从复制的实现原理

上面一节中,介绍了如何操作可以建立主从关系;本小节将介绍主从复制的实现原理。

主从复制过程大体可以分为3个阶段:连接建立阶段(即准备阶段)、数据同步阶段、命令传播阶段;下面分别进行介绍。

1. 连接建立阶段

该阶段的主要作用是在主从节点之间建立连接,为数据同步做好准

<think> 嗯,用户想了解Redis主从架构的原理,这个问题其实是在分布式系统中很基础但重要的知识点。从引用内容看,用户提供的参考资料已经涵盖了主从架构的核心概念、配置步骤和工作流程,我需要把这些信息整合成清晰的解释。 用户可能是个后端开发工程师,正在搭建Redis高可用环境。ta特意提到“原理”而非配置,说明需要理论层面的理解。要注意区分主从复制和哨兵/集群的区别,避免概念混淆。 主从架构的核心在于数据同步机制。根据引用[3],主节点处理写请求,从节点只读,这种读写分离对电商类场景特别有用。引用[4]提到的replicaof配置指令和只读设置是关键实现细节。数据同步过程需要分阶段说明:连接建立、全量同步、增量同步——这部分引用资料没展开,但属于原理的核心。 突然想到用户可能混淆了“主从”和“集群”的概念,应该在优缺点里明确主从的单点故障问题。引用[1][2]提到的高可用设计正好作为引子,带出主从架构的局限性,为后续介绍哨兵机制埋个伏笔。 配置步骤虽然引用[4][5]提了,但用户当前问的是原理而非实操,这部分只需概括。重点突出6379主节点和6380从节点的端口示例,帮助建立具象认知。数据同步的流程图解很重要,考虑用纯文字描述PSYNC流程时模拟时序逻辑。 要不要讲异步复制的数据丢失风险呢?用户没问但属于重要原理。根据经验,很多开发者会踩这个坑,还是加上,放在工作原理阶段说明时提一句。引用[3]的“写请求少读请求多”场景可以转化为QPS优势的量化说明,比如10万+并发这个数据就很直观。 最后考虑用户可能的延伸问题:主从延迟怎么监控?故障切换如何实现?这些在相关问题里列出来,方便ta后续深度了解。毕竟主从只是基础,生产环境必然要结合哨兵或集群。 </think> Redis主从架构的核心原理是通过**主节点(Master)和从节点(Slave)之间的数据复制**实现高可用和读写分离。以下是其核心工作原理的分步说明: --- ### **1. 角色分工** - **主节点(Master)**: 唯一处理写操作(如 `SET`、`DEL`),并将写命令同步给所有从节点。**不直接处理读请求**。 - **从节点(Slave)**: 通过复制主节点数据保持一致性,**只处理读请求(如 `GET`)**,默认不可写(`replica-read-only yes`)。 --- ### **2. 数据同步流程** #### **阶段1:连接建立** 1. 从节点启动时,通过配置 `replicaof <master-ip> <master-port>` 连接主节点。 2. 主节点验证连接后,创建**复制缓冲区**记录后续写命令。 #### **阶段2:全量同步(首次连接)** 1. 主节点执行 `BGSAVE` 生成 **RDB 快照文件**。 2. 将快照发送给从节点,从节点清空旧数据并加载快照。 3. 主节点将复制缓冲区中**快照生成期间的写命令**发送给从节点,保证数据一致性。 > ✅ 适用场景:从节点首次同步或主从数据差异过大时。 #### **阶段3:增量同步(正常运行)** 1. 主节点每处理一个写命令,会将其存入**复制缓冲区**(内存队列)。 2. 从节点持续接收并执行主节点发送的缓冲区的写命令,实现实时同步。 3. 主从节点通过 **`PSYNC` 命令**传递复制偏移量(offset),确保命令不丢失。 > ⚡ 优势:避免全量同步的资源开销,仅传输增量数据。 --- ### **3. 断线重连机制** - 若网络中断后恢复: 从节点发送 `PSYNC <runid> <offset>` 给主节点(`runid` 是主节点唯一ID,`offset` 是复制进度)。 - 主节点检查 `offset`: - 若 `offset` 仍在复制缓冲区内 → **增量同步**。 - 若 `offset` 已溢出缓冲区 → **触发全量同步**。 --- ### **4. 核心配置参数** | **参数** | **作用** | |------------------------|--------------------------------------------------------------------------| | `replicaof` | 从节点配置:指定主节点的 IP 和端口(Redis 5.0+ 替代 `slaveof`) | | `replica-read-only yes`| 从节点只读(默认开启) | | `repl-backlog-size` | 复制缓冲区大小(影响增量同步能力) | | `min-replicas-to-write`| 主节点要求的最小从节点数(保证数据安全) | --- ### **5. 主从架构的优缺点** | **优点** | **缺点** | |-----------------------------------|---------------------------------------| | **读写分离**:大幅提升读并发能力(QPS可达10W+) | **主节点单点故障**:需配合哨兵(Sentinel)实现自动故障转移 | | **数据冗余**:从节点提供数据备份 | **复制延迟**:异步复制可能导致从节点数据短暂滞后 | | **高可用基础**:哨兵/集群方案结合 | **主节点写压力**:所有写操作集中在单点 | --- ### **6. 典型应用场景** - **读多写少场景**:如商品详情页、新闻资讯等高频查询业务。 - **数据备份**:从节点作为灾备副本。 - **横向扩展**:通过增加从节点提升系统读吞吐量。 > 📌 **注意事项**: > - 主从复制是**异步过程**,极端情况下可能丢失少量数据(需强一致性可开启 `WAIT` 命令)。 > - 生产环境需部署**哨兵集群**监控主节点状态,实现自动故障切换[^1][^3][^4]。 --- ### **配置示例(从节点)** ```bash # redis.conf (从节点配置) port 6380 daemonize yes pidfile /var/run/redis_6380.pid logfile "6380.log" dir /data/redis/6380 replicaof 192.168.0.60 6379 # 指向主节点IP和端口 replica-read-only yes # 从节点只读 ``` ---
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值