Redis主从复制讲解！

发布时间：2025-11-04 12:41:33 来源：技术快报 作者：IT科技类资讯

使用和配置主从复制，主制讲能使得从 Redis 服务器( slave)能精确得复制主 Redis 服务器( master)的从复内容。每次当 slave 和 master 之间的主制讲连接断开时， slave 会自动重连到 master 上，从复并且无论这期间 master 发生了什么，主制讲 slave 都将尝试让自身成为 master 的从复精确副本。

这个系统的运行依靠三个主要的机制：

主从复制的简单性质：

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave服务器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

如果master宕机了，默认情况下不会在slave节点中自动选择一个master(不能进行写操作)，所以有哨兵和集群的概念。

使用Redis主从复制的原因主要是单台Redis节点存在以下的局限性：

从总体上来说，Redis主从复制的策略就是：当主从服务器刚建立连接的时候，进行全量同步;全量复制结束后，进行增量复制。当然，如果有需要，slave 在任何时候都可以发起全量同步。

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份，具体步骤如下：

Redis的增量复制是指在初始化的全量复制并开始正常工作之后，master服务器将发生的写操作同步到slave服务器的过程，

增量复制的过程主要是master服务器每执行一个写命令就会向slave服务器发送相同的写命令，slave服务器接收并执行收到的写命令。

slave与master能够在网络连接断开重连后，只从中断处继续进行复制，而不必重新同步，这就是所谓的断点续传。

断电续传这个新特性使用psync命令，master服务器收到slave发送的psync命令后，会根据自身的情况做出对应的处理，可能是FULLRESYNC runid offset触发全量复制，也可能是CONTINUE触发增量复制

命令格式：psync runid offset

3.2、工作原理：

(1)master服务器在内存缓冲区中给每个slave服务器都维护了一份同步备份日志(in-memory backlog)，缓存最近一段时间的数据，默认大小1m，如果超过这个大小就会清理掉。

(2)同时，master 和 slave 服务器都维护了一个复制偏移量(replication offset)和 master线程ID(master run id)，每个slave服务器在跟master服务器进行同步时都会携带master run id 和 最后一次同步的复制偏移量offset，通过offset可以知道主从之间的数据不一致的情况。

(3)当连接断开时，slave服务器会重新连接上master服务器，然后请求继续复制。假如主从服务器的两个master run id相同，并且指定的偏移量offset在同步备份日志中还有效，复制就会从上次中断的点开始继续。如果其中一个条件不满足，就会进行完全重新同步，因为主运行id不保存在磁盘中，如果从服务器重启的话就只能进行完全同步了。

master服务器维护的offset是存储在backlog中，msater就是根据slave发送的offset来从backlog中获取数据的。

(4)在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

run_id是Redis 服务器的随机标识符，用于 Sentinel 和集群，服务重启后就会改变;

当slave节点复制时发现和之前的 run_id 不同时，将会对数据进行全量同步。

查看runid

通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。

在前面全量复制的过程中，master会将数据保存在磁盘的rdb文件中然后发送给slave服务器，但如果master上的磁盘空间有限或者是使用比较低速的磁盘，这种操作会给master服务器带来较大的压力，那怎么办呢?在Redis2.8之后，可以通过无盘复制来达到目的，由master直接开启一个socket，在内存中创建RDB文件，再将rdb文件发送给slave服务器，不使用磁盘作为中间存储。(无盘复制一般应用在磁盘空间有限但是网络状态良好的情况下)

redis将无法执行写请求，只有slave节点能执行读请求，影响了系统的可用性

方法1：

随机找一个节点，执行slaveof no one，使其成为master节点

然后对其他slave节点执行slaveof newMatserIp newMasterPort

方法2：

马上重启master节点，它将会重新成为master

方法三：哨兵模式

Redis 的过期机制可以限制 key 的生存时间。此功能取决于 Redis 实例计算时间的能力，但是，即使使用 Lua 脚本更改了这些 key，Redis slaves 也能正确地复制具有过期时间的 key。

为了实现这样的功能，Redis 不能依靠主从使用同步时钟，因为这是一个无法解决的并且会导致 race condition 和数据集不一致的问题，所以 Redis 使用三种主要的技术使过期的 key 的复制能够正确工作：

一旦一个 slave 被提升为一个 master ，它将开始独立地过期 key，而不需要任何旧 master 的帮助。

相关文章