redis 主从复制详解

本文主要是介绍redis 主从复制详解，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

引言

我们之前操作 Redis 都是单机版，但是实际应用中没人使用单机版，都是搭建集群的方式。这篇文章要介绍的主从复制，是指将一台 Redis 服务器的数据，复制到其他 Redis 服务器，我们将前者称为主节点 master，将后者称为从节点 slave（replica）。在这个过程中，数据的复制是单向的，即只能从主节点到从节点。并且从节点只能读数据，不能写数据，实现读写分离。

• 一个主节点可以有多个从节点，一个从节点只能有一个主节点。所有的服务器默认都是主节点。
• 从节点下面还可以有从节点，形成一个图的结构

主从复制的优点

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

开启主从复制

主从复制的前提就是多个 Redis 服务器，因此要多个配置文件。

开启主从复制的方式有两种：

• 配置配置文件

  从服务器配置master节点

  # 主节点ip port
  # replicaof <masterip> <masterport>
  # 主节点的认证密码(可选)
  # masterauth <master-password>
  

• 显示命令开启

  客户端使用该命令slaveof [ip] [port]

  INFO REPLLICATION命令可查看节点信息

  

  

主从复制的具体实现

主从复制的实现可以分为三个阶段：建立连接、数据同步、命令传播

1. 建立连接

• 发送 slaveof 异步命令

• 建立 socket 连接

  

  连接成功后从节点会为该 socket 建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收 RDB 文件、接收命令传播等；

• 发送 ping 命令

  从节点成为主节点的客户端之后，发送 ping 命令进行首次请求，目的是检查 socket 连接是否可用，以及主节点当前是否能够处理请求。

• 身份验证

  取决于从节点是否设置 masterauth 选项，而这个又取决于主节点是否设置 requirepass

• 发送从节点端口信息

2. 数据同步

连接建立完成后，要进行主从数据库的数据同步，这一步也可以看作从节点中数据的初始化。数据同步有旧版和新版两种。我们先来看看旧版 Redis 怎么实现数据同步的

旧版同步

旧版同步使用的命令是 sync，同步方式是全量复制。以下是sync命令的执行步骤：

• 从服务器向主服务器发送 sync 命令
• 主服务器收到后执行 BGSAVE 的rgb持久化命令，生成一个RDB文件。并用一个缓冲区记录生成rgb文件期间执行的所有写命令。
• 主服务器将 rgb 文件发送给从服务器，从服务器载入整个 rgb 文件，同步数据库状态至执行 BGSAVE 时主服务的状态
• 主服务器将记录在缓冲区的写命令发送给从服务器。至此从服务和主服务数据库状态达到一致。

旧版同步功能的缺陷：

• 断线后重连需要再次发送 sync 同步命令，主服务再次生成 rgb 文件，从服务器载入恢复数据库状态。简单来说就是断线后又要全量复制，但其实没有必要，我们只需要同步断线后到重新连接期间主服务器变化的数据即可。

  并且，sync是一个非常耗费资源的操作，因此旧版同步是非常低效的。

新版同步

新版同步使用的命令是 psync ，同步方式是增量复制

psync 有完成重同步和部分重同步两种模式。完整重同步其实就是sync，主要用于处理初次服务的情况。部分重同步主要用于处理断线后重连的情况。部分重同步不需要重新生成、传送和载入整个rdb文件，只需要将从服务器缺少的写命令发送给从服务器执行即可。完美的解决了旧版同步效率低下的问题。

下面我们就来看看他是如何实现的？首先要了解几个概念

• 主节点和从节点的复制偏移量

  主节点和从节点会各自维护一个复制偏移量 ( offset )，代表的是主节点向从节点传递的字节数。主节点每次向从节点传播 N 个字节数据时，主节点的 offset 增加 N；同理，当从节点每次收到主节点传来的 N 个字节数据时，从节点的 offset 增加 N。通过比较主节点和从节点的 offset 可以判断数据库状态是否一致，如果两者的 offset 相同，则一致，否则不一致；也可以根据两者的 offset 找出从节点缺少的数据。

  

• 主节点的复制积压缓冲区

  主节点维护的一个固定长度的先进先出 ( FIFO) 队列，默认大小是 1MB。当主节点开始有从节点时，主节点创建复制积压缓冲区，其作用是备份主节点最近发送给从节点的数据。保存的数据有两方面：

  • 最近传播的写命令。为什么最近呢？因为队列长度固定，老的命令会被新的取代
  • 队列中每个字节对应的复制偏移量

  当从服务器重新连接上主机时，会通过 psync 命令把自己的offset发给主节点

  • 如果offset之后的数据全部在队列中，执行部分重同步（增量复制）
  • 如果offset之后的数据不全在队列中，执行完整重同步（全量复制）

• 服务器的运行ID

  每个redis服务器都有自己的运行ID，在启动时自动生成，由40个随机的十六进制字符组成

  当从节点对主节点进行初次复制时，主节点会把自己的运行ID发给从节点，从节点保存并在断线重连上主节点时把次ID发送给主节点：

  • 如果此ID和主节点当前连接的ID一致，说明是同一个状态，可以进行增量复制
  • 如果不同，只能进行全量复制

总结：psync的执行流程：

命令传播

数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。

这个阶段没啥可说的，就是把主节点执行的写命令发给从节点，让它们也执行一次，保证主从一致性

心跳检测

在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送replconf ACK <replication_offset>,其中replication_offset是它当前的复制偏移量。心跳检测的目的有以下三个：

• 检测主从服务器的网络连接状态

  如果主服务器超过一秒没有收到从服务的该命令，那么主服务器就知道主从连接出现问题了

  

• 辅助实现min-slaves

  主服务我们可以配置以下两个参数来防止不安全写命令传播，如果从节点小于3或者lag大于10，主服务器都会拒绝执行写命令

  # 从节点的最小个数
  # min-replicas-to-write 3
  # 从节点lag的最大值
  # min-replicas-max-lag 10
  

• 检测命令丢失

  上面说过心跳检测命令还发送了从节点自身保存的offset。主节点会与自己的 offset 进行对比，如果从节点数据缺失（如网络丢包），主节点会找到缺失的数据，并把这些数据重新推送给服务器（这里也会利用复制积压缓冲区）。

  参考

  • Redis设计与实现

  • Redis 进阶篇三——主从复制

  • Redis 主从复制

这篇关于redis 主从复制详解的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！