Redis篇章-Redis 主从复制：从“为什么需要“到全量 / 部分 / 实时三种复制

一文吃透 Redis 主从复制从为什么需要到全量 / 部分 / 实时三种复制含完整流程图前面我们聊过 Redis 持久化RDB 快照与 AOF 日志持久化解决的是单机断电数据不丢的问题。但如果这台机器本身宕机了呢这就是本文要讲的主从复制Replication——它是 Redis 高可用的基石哨兵Sentinel和集群Cluster都是构建在复制的基础之上的。一、为什么要主从复制1.1 单机 Redis 的两大痛点一台单独的 Redis 服务器存在典型的单点问题痛点说明① 可用性不高只有一台机器它一旦宕机整个缓存服务就瘫痪了业务直接受损② 性能有限所有的读请求 写请求都压在一台机器上CPU、内存、网络都有上限扛不住高并发1.2 主从复制的解决思路Redis 提供了复制功能实现相同数据的多个 Redis 副本Replica数据多副本 → 故障恢复主节点挂了从节点上还有一份完整数据可以顶上提供服务配合哨兵可以自动完成故障转移读写分离 → 分摊压力主节点负责写从节点负责读读压力被分摊到多台从节点上降低主节点的访问压力。1.3 主从复制的三个基本特点参与复制的实例分为主节点master和从节点slave每个从节点只能有一个主节点而一个主节点可以同时有多个从节点复制的数据流是单向的——只能由主节点流向从节点从节点上的修改主节点无法感知。二、主从复制的详细操作2.1 如何建立复制三种配置方式主节点的配置不需要任何改动只需要在从节点上指明我的主节点是谁三种方式任选# 方式 1配置文件中加入随 Redis 启动生效slaveof{masterHost}{masterPort}# 方式 2redis-server 启动命令时加入redis-server /etc/redis/redis-slave.conf--port6380--slaveof127.0.0.16379# 方式 3运行时直接使用 redis 命令127.0.0.1:6380slaveof127.0.0.16379验证是否生效在主从节点分别执行127.0.0.1:6379info replication# 主节点看到 role:master, connected_slaves:N127.0.0.1:6380info replication# 从节点看到 role:slave, master_link_status:up补充两个相关操作断开复制从节点执行slaveof no one断开后从节点晋升为主节点原有数据不会丢弃只是不再同步主节点的新变化切主操作执行slaveof {newMasterIp} {newMasterPort}流程为断开旧主 → 连接新主 →删除自身全部数据→ 从新主重新复制。2.2 建立复制的完整流程六个步骤在从节点上执行slaveof之后内部会依次经历六个步骤保存主节点信息从节点记录主节点的 ip / port此时master_link_status还是down主从建立网络连接从节点内部每秒运行的定时任务发现新主节点后尝试建立 TCP 连接连不上会无限重试直到成功或手动停止复制发送 ping 命令确认主节点在应用层上工作正常若 pong 超时断开连接等下轮重连权限验证主节点设置了requirepass时从节点需要通过masterauth配置一致的密码验证失败则复制停止同步数据集把主节点当前持有的所有数据全部发给从节点这是最耗时的一步分为全量同步和部分同步两种情况见第三节命令持续复制数据同步完成后主节点会把后续的每一条写命令持续发送给从节点保证主从数据一致。关键概念runid复制 id offset偏移量共同标识了一份数据集——如果两个节点的 runid 和 offset 都相同它们持有的数据就一定相同。这个概念是理解全量 / 部分复制的钥匙。三、三种复制方式重点Redis 使用psync命令完成主从数据同步语法PSYNC replicationid offsetreplid为?且offset为-1→ 尝试进行全量复制第一次复制时从节点啥也不知道只能这么发replid和offset为具体数值 → 尝试进行部分复制从节点之前复制过记得自己的学习进度。三种复制方式全量复制、部分复制、实时复制。下面逐一拆解。3.1 全量复制 —— 首次复制必须经历全量复制是主从第一次建立复制时必须经历的阶段主节点把全部数据一次性以 RDB 的形式发给从节点。流程详解对应图中 ①-⑨从节点发送psync ? -1第一次复制没有主节点的 runid 和 offset主节点解析出要做全量复制回复FULLRESYNC {runid} {offset}从节点接收并保存主节点的 runid 和 offset主节点执行bgsave生成 RDB 文件主节点把 RDB 文件发送给从节点从节点保存到本地硬盘从 Redis 2.8.18 开始支持无盘复制diskless主节点生成 RDB 时不落磁盘直接通过网络发给从节点省去写硬盘 读硬盘的开销生成 RDB 期间主节点仍在响应写命令这些新写命令暂存到缓冲区等从节点保存完 RDB 后再补发过去仍按 RDB 二进制格式追加写入保证一致性从节点清空自身原有旧数据从节点加载 RDB得到与主节点一致的数据如果从节点开启了 AOF再执行bgrewriteaof得到最近的 AOF 文件。⚠️全量复制成本非常高主节点 bgsave 的时间 RDB 网络传输的时间 从节点清空旧数据的时间 加载 RDB 的时间。数据量越大代价越大所以应尽量避免对已有大量数据集的 Redis 进行全量复制——这正是部分复制存在的意义。3.2 部分复制 —— 网络闪断后的断点续传部分复制是针对全量复制过高开销做出的优化措施从节点复制期间如果出现网络闪断、命令丢失等异常重新连上后只补发缺失的那一小段数据开销极小。流程详解对应图中 ①-⑥主从之间网络中断超过repl-timeout时间后主节点认为从节点故障断开复制连接中断期间主节点依然响应命令但这些复制命令无法及时发给从节点于是**暂时滞留在「复制积压缓冲区」**中网络恢复后从节点重新连上主节点从节点把之前保存的replid offset作为参数发送psync {replid} {offset}请求部分复制主节点校验后根据 offset 去复制积压缓冲区查找数据回复CONTINUE主节点把缺失的那部分数据补发给从节点主从重新一致。核心复制积压缓冲区repl-backlog-buffer保存在主节点上的一个固定长度队列默认 1MB主节点有从节点连接时创建主节点响应写命令时不但发给从节点还会同时写入这个缓冲区本质是先进先出的环形队列相当于数组实现的环形缓冲区只保存最近已复制的数据可用偏移量范围 [repl_backlog_first_byte_offset, first_byte_offset repl_backlog_histlen]可用info replication查看。⚠️如果从节点需要的 offset 已经超出缓冲区范围断线太久、被环形队列覆盖了缓冲区里已经没有它要的数据 →无法部分复制只能退化成全量复制。写量大的场景可以调大repl-backlog-size来降低这种退化概率。3.3 实时复制 —— 长连接 心跳保活全量/部分复制完成后主从进入命令实时复制阶段主节点把自己收到的每一条修改操作通过 TCP 长连接源源不断传给从节点从节点执行相同命令实时修改自身数据与主节点保持一致。这条长连接依靠应用层实现的心跳机制来维护不是 TCP 自带的心跳角色心跳行为默认频率主节点 → 从节点发送ping判断从节点存活性和连接状态每10 秒从节点 → 主节点发送replconf ack {offset}上报当前复制偏移量每1 秒如果主节点发现从节点通信延迟超过repl-timeout默认 60 秒则判定从节点下线断开复制连接从节点恢复后心跳机制继续进行。3.4 三种方式的关系一句话总结先全量第一次后实时日常出故障再部分复制补齐。维度全量复制部分复制实时复制触发时机首次建立复制 / offset 超出缓冲区范围网络闪断恢复后offset 仍在缓冲区内数据同步完成之后持续进行psync 参数psync ? -1psync {replid} {offset}—主节点响应FULLRESYNCCONTINUE持续推送写命令传输内容完整 RDB 快照缓冲区中缺失的那段命令后续每一条写命令开销极高bgsave 传输 清空 加载很小只补缺失部分平稳逐条增量四、主从复制的拓扑结构复制的拓扑可以单层也可以多层常见的有三种拓扑结构适用场景注意点一主一从最简单1 个主 1 个从主节点宕机时从节点提供故障转移支持可只在从节点开 AOF避免持久化干扰主节点性能主节点关闭持久化时宕机后要避免自动重启一主多从星形1 个主 N 个从读并发量大读命令负载均衡到多个从节点耗时读命令可指定专用从节点写并发量大时写命令要发给每个从节点反而加重主节点负载树形主从分层从节点还可以作为下层节点的主节点继续向下复制主节点需要挂载多个从节点时避免性能干扰引入复制中间层有效降低主节点负载和传送的数据量五、其他实用配置安全性主节点设置requirepass后从节点必须配置相同的masterauth否则无法通过权限验证发起复制只读模式从节点默认slave-read-onlyyes。因为复制是单向的从节点上的修改主节点感知不到会造成主从数据不一致线上不建议关闭传输延迟repl-disable-tcp-nodelay默认no开启 TCP_NODELAY命令小包及时发送延迟小但占带宽适合同机房设为yes则合并小包节省带宽约 40ms 间隔延迟变大适合跨机房。六、总结与重点回顾主从复制解决的是单点问题单节点可用性不高、性能有限通过数据多副本实现故障恢复通过读写分离分摊压力配置很简单主节点不动从节点加slaveof {masterHost} {masterPort}即可数据流永远单向主 → 从建立复制六步走保存主节点信息 → 建立连接 → ping → 权限验证 → 同步数据集 → 命令持续复制三种复制方式全量复制psync ? -1→FULLRESYNC首次复制必须经历bgsave 生成 RDB 全量传输成本极高部分复制psync {replid} {offset}→CONTINUE靠复制积压缓冲区默认 1MB 环形队列补发断线期间的数据offset 超出缓冲区范围则退化为全量实时复制TCP 长连接持续推送写命令主 10 秒 ping 一次、从 1 秒上报一次 offset 的心跳机制保活核心概念replid offset共同标识一份数据集相当于主从之间对齐学习进度哨兵和集群都是在主从复制的基础上构建的——理解了复制后面学高可用架构就顺理成章了。如果本文对你有帮助欢迎点赞、收藏、评论交流