Redis主从复制

李歘歘

已于 2022-04-08 20:31:50 修改

阅读量1.4k

点赞数 2

分类专栏：好好学习 # 数据库文章标签： redis 数据库缓存

于 2022-02-12 15:38:54 首次发布

本文链接：https://blog.csdn.net/qq_42410605/article/details/122895891

版权

好好学习同时被 2 个专栏收录

56 篇文章 4 订阅

订阅专栏

数据库

23 篇文章 2 订阅

订阅专栏

本文详细介绍了Redis主从复制的原理，包括建立连接、数据同步和命令传播三个阶段。主从复制提供数据冗余、故障恢复、读写分离和负载均衡，确保高可用性。在数据同步过程中，全量复制和部分复制结合使用，通过复制积压缓冲区处理网络中断。此外，文章还讨论了主从复制中的常见问题及解决方案，如主节点重启、网络中断导致的全量复制、资源占用和数据不一致等。

摘要由CSDN通过智能技术生成

博客主页：🏆看看是李XX还是李歘歘 🏆

🌺每天不定期分享一些包括但不限于计算机基础、算法、后端开发相关的知识点，以及职场小菜鸡的生活。🌺

💗点关注不迷路，总有一些📖知识点📖是你想要的💗

本文转载：

作者：原来是咔咔
链接：https://juejin.cn/post/6844904178519654414
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

⛽️今天的内容是 Redis主从复制 ⛽️💻💻💻

什么是Redis主从复制？

主从复制就是将主节点（master）redis的数据同步到其他从节点（slave）redis数据库上。

数据的复制是单向的，只能由主节点到从节点。
Master以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

为什么需要Redis主从复制？

单机状态有两个问题：

服务器宕机，直接导致数据丢失。
内存问题，一台服务器的内存肯定会到达峰值，不可能对一台服务器进行无限升级的。

主从复制可以将数据保存在多个服务器上，并且保证每个服务器的数据是同步的。即使有一个服务器宕机了，也不会影响用户的使用。redis可以继续实现高可用、同时实现数据的冗余备份。

Redis主从复制的作用

数据冗余：实现了数据的热备份，是持久化之外的另一种方式。
故障恢复：当主节点(master)出现问题时，可以由从节点(slave)来提供服务，实现了快速恢复故障，也就是服务冗余。
读写分离：master服务器主要是写，slave主要用来读数据，可以提高服务器的负载能力。同时可以根据需求的变化，添加从节点的数量。
负载均衡：配合读写分离，有主节点提供写服务，从节点提供读服务，分担服务器负载，尤其在写少读多的情况下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量和负载。
高可用的基石：主从复制是哨兵和集群能够实施的基础，因此我们可以说主从复制是高可用的基石。

主从复制工作原理

1. 主从复制的三个阶段

主从复制完整的工作流程分为以下三个阶段。每一段都有自己的内部工作流程，那么我们会对这三个过程进行谈论。

建立连接过程：这个过程就是slave跟master连接的过程
数据同步过程：是master给slave同步数据的过程
命令传播过程：是反复同步数据

2. 第一阶段：建立连接过程

上图是一个完整主从复制建立连接工作流程。然后使用简短的话语来描述上边的工作流程。

设置master的地址和端口，保存master的信息
建立socket连接（这个连接做的事情下文会说）
持续发送ping命令
身份验证
发送slave端口信息

在建立连接的过程中，从节点会保存master的地址和端口、主节点保存slave的端口。

3. 第二阶段：数据同步阶段过程

这张图是详细描述第一次从节点连接主节点时的数据同步过程。

当从节点第一次连接主节点时，先会执行一次全量复制这次的全量复制是无法避免的。

全量复制执行完成后，主节点就会发送复制积压缓冲区的数据，然后从节点就会执行bgrewriteaof恢复数据，这也就是部分复制。

在这个阶段提到了三个新点，全量复制、部分复制、复制缓冲积压区。会在下文的常见问题里详细说明这几个点。

4. 第三阶段：命令传播阶段

当master数据库被修改后，主从服务器的数据不一致后，此时就会让主从数据同步到一致，这个过程称之为命令传播。

master会将接收到的数据变更命令发送给slave，slave接收命令后执行命令，让主从数据达到一致。

命令传播阶段的部分复制

在命令传播阶段出现断网的情况，或者网络抖动时会导致连接断开（connection lost）
这个时候主节点master还是会继续往replbackbuffer（复制缓冲积压区）写数据
从节点会继续尝试连接主机（connect to master）
当从节点把自己的runid和复制偏移量发送给主节点，并且执行pysnc命令同步
如果master判断偏移量是在复制缓冲区范围内，就会返回continue命令。并且发送复制缓冲区的数据给从节点。
从节点接收数据执行bgrewriteaof，恢复数据

详细介绍主从复制原理（全量复制+部分复制）

这个过程就是主从复制最齐全的流程讲解。那么下来我们对每一步进程简单的介绍

从节点发送指令psync ? 1 psync runid offset 找对应的runid索取数据。但是这里可以考虑一下，当从节点第一次连接的时候根本就不知道主节点的runid 和 offset 。所以第一次发送的指令是psync ？ 1意思就是主节点的数据我全要。
主节点开始执行bgsave生成RDB文件，记录当前的复制偏移量offset
主节点这个时候会把自己的runid 和 offset 通过 +FULLRESYNC runid offset 指令通过socket发送RDB文件给从节点。
从节点接收到+FULLRESYNC 保存主节点的runid和offset 然后清空当前所有数据，通过socket接收RDB文件，开始恢复RDB数据。
在全量复制后，从节点已经获取到了主节点的runid和offset，开始发送指令 psync runid offset
主节点接收指令，判断runid是否匹配，判断offset是否在复制缓冲区中。
主节点判断runid和offset有一个不满足，就会在返回到步骤2继续执行全量复制。这里的runid不匹配只有的可能是从节点重启了这个问题后边会解决，offset（偏移量）不匹配就是复制积压缓冲区溢出了。如果runid或offset校验通过，从节点的offset和主节点的offset相同时则忽略。如果runid或offset检验通过，从节点的offset与offset不相同，则会发送 +CONTINUE offset(这个offset为主节点的)，通过socket发送复制缓冲区中从节点offset到主节点offset的数据。
从节点收到+CONTINUE 保存master的offset 通过socket接收到信息后，执行bgrewriteaof，恢复数据。

1-4是全量复制 5-8是部分复制

在主节点的第3步下面主节点在主从复制的期间是一直在接收客户端的数据，主节点的offset是一直变化的。只有有变化就会给每个slave进行发送，这个发送的过程称之为心跳机制

心跳机制

在命令传播阶段，主节点与从节点之间一直都需要进行信息互换，使用心跳机制进行维护，实现主节点和从节点连接保持在线。

master心跳

指令：ping
默认10秒进行一次，是由参数repl-ping-slave-period决定的
主要做的事情就是判断从节点是否在线
可以使用info replication 来查看从节点租后一次连接时间的间隔，lag为0或者为1就是正常状态。

slave心跳任务

指令：replconf ack {offset}
每秒执行一次
主要做的事情是给主节点发送自己的复制偏移量，从主节点获取到最新的数据变更命令，还做一件事情就是判断主节点是否在线。

心跳阶段的注意事项 主节点为保障数据稳定性，当从节点挂掉的数量或者延迟过高时。将会拒绝所有信息同步。

这里有俩个参数可以进行配置调整：

min-slaves-to-write 2

min-slaves-max-lag 8

这俩个参数表示从节点的数量就剩余2个，或者从节点的延迟大于8秒时，主节点就会强制关闭maste功能，停止数据同步。

那么主节点是如何知道从节点挂掉的数量和延迟时间呢！在心跳机制里边slave 会每隔一秒发送perlconf ack 这个指令，这个指令可携带偏移量，也可以携带从节点的延迟时间和从节点的数量。

部分复制的三个核心要素

1. 服务器的运行id （run id）

我们先看一下这个run id是什么，info命令即可看到。在文中我们查看启动日志信息也可以看到。

redis在启动时会自动生成一个随机的id（这里需要注意的是每次启动的id都会不一样），是由40个随机的十六进制字符串组成，用来唯一识别一个redis节点。在主从复制初次启动时，master会把自己的runid发送给slave，slave会保存master的这个id，我们可以使用info命令查看

当断线重连时，slave把这个id发送给master，如果slave保存的runid与master现在的runid相同，master会尝试使用部分复制（这块能否复制成功还有一个因素就是偏移量）。如果slave保存的runid与master现在的runid不同，则会直接进行全量复制。

2. 复制积压缓冲区

复制缓冲积压区是一个先进先出的队列，用户存储master收集数据的命令记录。复制缓冲区的默认存储空间是1M。可以在配置文件修改repl-backlog-size 1mb来控制缓冲区大小，这个比例可以根据自己的服务器内存来修改。

复制缓冲区到底存储的是什么？

当执行一个命令为set name kaka时，我们可以查看持久化文件查看

那么复制积压缓冲区就是存储的aof持久化的数据，并且以字节分开，并且每个字节都有自己的偏移量。这个偏移量也就是复制偏移量（offset）

那为什么会说复制缓冲积压区有可能会导致全量复制呢在命令传播阶段，主节点会把收集的数据存储到复制缓冲区中，然后在发送给从节点。就是这里出现了问题，当主节点数据量在一瞬间特别大的时候，超出了复制缓冲区的内存，就会有一部分数据会被挤出去，从而导致主节点和从节点的数据不一致。从而进行全量复制。如果这个缓冲区大小设置不合理那么很大可能会造成死循环，从节点就会一直全量复制，清空数据，全量复制。

3. 复制偏移量（offset）

主节点复制偏移量是给从节点发送一次记录一次，从节点是接收一次记录一次。用于同步信息，对比主节点和从节点的差异，当slave断联时恢复数据使用。这个值也就是来自己于复制缓冲积压区里边的那个偏移量。