Redis分布式基石——主从复制技术详述，Java开发者必须收藏的8个开源库

本文主要是介绍Redis分布式基石——主从复制技术详述，Java开发者必须收藏的8个开源库，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

2.2.2 psync如何实现

2.2.3 完整的psync

2.3 版本4.0

1、简介

====

主从复制是Redis分布式的基石，也是Redis高可用的保障。在Redis中，被复制的服务器称为主服务器（Master），对主服务器进行复制的服务器称为从服务器（Slave）。

主从复制的配置非常简单，有三种方式（其中IP-主服务器IP地址/PORT-主服务器Redis服务端口）：

1. 配置文件——redis.conf文件中，配置slaveof ip port

2. 命令——进入Redis客户端执行slaveof ip port

3. 启动参数—— ./redis-server --slaveof ip port

2、主从复制的演进

=========

Redis的主从复制机制，并不是一开始就像6.x版本一样完善，而是一个版本一个版本迭代而来的。它大体上经过三个版本的迭代：

• 2.8以前

• 2.8~4.0

• 4.0以后

随着版本的增长，Redis主从复制机制逐渐完善；但是他们的本质都是围绕同步（sync）和命令传播（command propagate）两个操作展开：

• 同步（sync）：指的是将从服务器的数据状态更新至主服务器当前的数据状态，主要发生在初始化或后续的全量同步。

• 命令传播（command propagate）：当主服务器的数据状态被修改（写/删除等），主从之间的数据状态不一致时，主服务将发生数据改变的命令传播给从服务器，让主从服务器之间的状态重回一致。

2.1 版本2.8以前

2.1.1 同步

2.8以前的版本，从服务器对主服务器的同步需要从服务器向主服务器发生sync命令来完成：

1. 从服务器接收到客户端发送的slaveof ip prot命令，从服务器根据ip:port向主服务器创建套接字连接

2. 套接字成功连接到主服务器后，从服务器会为这个套接字连接关联一个专门用于处理复制工作的文件事件处理器，处理后续的主服务器发送的RDB文件和传播的命令

3. 开始进行复制，从服务器向主服务器发送sync命令

4. 主服务器接收到sync命令后，执行bgsave命令，主服务器主进程fork的子进程会生成一个RDB文件，同时将RDB快照产生后的所有写操作记录在缓冲区中

5. bgsave命令执行完成后，主服务器将生成的RDB文件发送给从服务器，从服务器接收到RDB文件后，首先会清除本身的全部数据，然后载入RDB文件，将自己的数据状态更新成主服务器的RDB文件的数据状态

6. 主服务器将缓冲区的写命令发送给从服务器，从服务器接收命令，并执行。

7. 主从复制同步步骤完成

2.1.2 命令传播

当同步工作完成之后，主从之间需要通过命令传播来维持数据状态的一致性。

如下图，当前主从服务器之间完成同步工作之后，主服务接收客户端的DEL K6指令后删除了K6，此时从服务器仍然存在K6，主从数据状态并不一致。为了维持主从服务器状态一致，主服务器会将导致自己数据状态发生改变的命令传播到从服务器执行，当从服务器也执行了相同的命令之后，主从服务器之间的数据状态将会保持一致。

2.1.3 缺陷

从上面看不出2.8以前版本的主从复制有什么缺陷，这是因为我们还没有考虑网络波动的情况。了解分布式的兄弟们肯定听说过CAP理论，CAP理论是分布式存储系统的基石，在CAP理论中P(partition网络分区)必然存在，Redis主从复制也不例外。当主从服务器之间出现网络故障，导致一段时间内从服务器与主服务器之间无法通信，当从服务器重新连接上主服务器时，如果主服务器在这段时间内数据状态发生了改变，那么主从服务器之间将出现数据状态不一致。

在Redis 2.8以前的主从复制版本中，解决这种数据状态不一致的方式是通过重新发送sync命令来实现。虽然sync能保证主从服务器数据状态一致，但是很明显sync是一个非常消耗资源的操作。

​

sync命令执行，主从服务器需要占用的资源：

• 主服务器执行BGSAVE生成RDB文件，会占用大量CPU、磁盘I/O和内存资源

• 主服务器将生成的RDB文件发送给从服务器，会占用大量网络带宽，

• 从服务器接收RDB文件并载入，会导致从服务器阻塞，无法提供服务

从上面三点可以看出，sync命令不仅会导致主服务器的响应能力下降，也会导致从服务器在此期间拒绝对外提供服务。

2.2 版本2.8-4.0

2.2.1 改进点

针对2.8以前的版本，Redis在2.8之后对从服务器重连后的数据状态同步进行了改进。改进的方向是减少全量同步（full resynchronizaztion）的发生，尽可能使用增量同步（partial resynchronization）。在2.8版本之后使用psync命令代替了sync命令来执行同步操作，psync命令同时具备全量同步和增量同步的功能：

• 全量同步与上一版本（sync）一致

• 增量同步中对于断线重连后的复制，会根据情况采取不同措施；如果条件允许，仍然只发送从服务缺失的部分数据。

2.2.2 psync如何实现

Redis为了实现从服务器断线重连后的增量同步，增加了三个辅助参数：

• 复制偏移量（replication offset）

• 积压缓冲区（replication backlog）

• 服务器运行id（run id）

2.2.2.1 复制偏移量

在主服务器和从服务器内都会维护一个复制偏移量

• 主服务器向从服务发送数据，传播N个字节的数据，主服务的复制偏移量增加N

• 从服务器接收主服务器发送的数据，接收N个字节的数据，从服务器的复制偏移量增加N

正常同步的情况如下：

通过对比主从服务器之间的复制偏移量是否相等，能够得知主从服务器之间的数据状态是否保持一致。

假设此时A/B正常传播，C从服务器断线，那么将出现如下情况：

很明显有了复制偏移量之后，从服务器C断线重连后，主服务器只需要发送从服务器缺少的100字节数据即可。**但是主服务器又

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

是如何知道从服务器缺少的是那些数据呢？**

​

2.2.2.2 复制积压缓冲区

复制积压缓冲区是一个固定长度的队列，默认为1MB大小。当主服务器数据状态发生改变，主服务器将数据同步给从服务器的同时会另存一份到复制积压缓冲区中。

复制积压缓冲区为了能和偏移量进行匹配，它不仅存储了数据内容，还记录了每个字节对应的偏移量：

当从服务器断线重连后，从服务器通过psync命令将自己的复制偏移量（offset）发送给主服务器，主服务器便可通过这个偏移量来判断进行增量传播还是全量同步。

• 如果偏移量offset+1的数据仍然在复制积压缓冲区中，那么进行增量同步操作

• 反之进行全量同步操作，与sync一致

Redis的复制积压缓冲区的大小默认为1MB，如果需要自定义应该如何设置呢？

很明显，我们希望能尽可能的使用增量同步，但是又不希望缓冲区占用过多的内存空间。那么我们可以通过预估Redis从服务断线后重连的时间T，Redis主服务器每秒接收的写命令的内存大小M，来设置复制积压缓冲区的大小S。

S = 2 * M * T

注意这里扩大2倍是为了留有一定的余地，保证绝大部分的断线重连都能采用增量同步。

​

2.2.2.3 服务器运行 ID

看到这里是不是再想上面已经可以实现断线重连的增量同步了，还要运行ID干嘛？其实还有一种情况没考虑，就是当主服务器宕机后，某台从服务器被选举成为新的主服务器，这种情况我们就通过比较运行ID来区分。

• 运行ID（run id）是服务器启动时自动生成的40个随机的十六进制字符串，主服务和从服务器均会生成运行ID

• 当从服务器首次同步主服务器的数据时，主服务器会发送自己的运行ID给从服务器，从服务器会保存在RDB文件中

• 当从服务器断线重连后，从服务器会向主服务器发送之前保存的主服务器运行ID，如果服务器运行ID匹配，则证明主服务器未发生更改，可以尝试进行增量同步

• 如果服务器运行ID不匹配，则进行全量同步

2.2.3 完整的psync

完整的psync过程非常的复杂，在2.8-4.0的主从复制版本中已经做到了非常完善。psync命令发送的参数如下：

这篇关于Redis分布式基石——主从复制技术详述，Java开发者必须收藏的8个开源库的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！