Redis主从同步（复制）

ゝ一纸荒年。 2022-01-23 10:29 299阅读 0赞

# 一、概述 #

在现有企业中80%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。

### 面临问题 ###

1.  机器故障。我们部署到一台 Redis 服务器，当发生机器故障时，需要迁移到另外一台服务器并且要保证数据是同步的。而数据是最重要的，如果你不在乎，基本上也就不会使用 Redis 了。
2.  容量瓶颈。当我们有需求需要扩容 Redis 内存时，从 16G 的内存升到 64G，单机肯定是满足不了。当然，你可以重新买个 128G 的新机器。

### 解决办法 ###

要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。

Redis 为了解决这个单一节点的问题，会把数据复制多个副本部署到其他节点，实现 Redis的高可用和对数据的备份，从而保证数据和服务的高可用。

## 二、什么是主从复制 ##

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)。数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

## 三、主从复制的作用 ##

1.  **数据备份**：主从复制实现了数据的热备份，是持久化之外的另一种数据备份方式。
2.  **故障恢复**：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
3.  **读写分离**：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量；
4.  **负载均衡**：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
5.  **高可用基石**：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

## 四、如何实现主从同步 ##

有两种方式可以用来完成主从Redis服务器的同步设置，都需要针对slave服务器上进行设置，指定slave需要连接的Redis服务器（可能是master，也可能是slave）。

### **在配置文件中设置** ###

在作为slave的Redis服务器的配置文件(/etc/redis/6379.conf)中设置。

slaveof 127.0.0.1 6379 #指定master的ip和端口

很明显，这种设置方式非常简单，但是需要修改配置文件，并且配置文件是在服务器启动时加载的。所以服务器不启动无法修改，操作不灵活。这种配置方式适合于作为部署时的初始配置。

### 通过客户端命令设置 ###

Redis服务器启动后，直接通过客户端执行命令：slaveof，则该Redis实例会成为从节点。

127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
    OK

执行上述命令后，服务器127.0.0.1:12345将成为127.0.0.1:6379的从服务器，而服务器127.0.0.1:6379则会成为127.0.0.1:12345的主服务器。

## 五、主从同步的原理 ##

主从同步分为 2 个步骤**：同步（全量同步）**和**命令传播（增量同步）**

*  同步：将从服务器的数据库状态更新成主服务器当前的数据库状态。
 *  命令传播：当主服务器数据库状态被修改后，导致主从服务器数据库状态不一致，需要让主从数据同步到一致状态。

上面就是主从同步 2 个步骤的作用，下面我打算稍微细说这两个步骤的实现过程。

这里需要提前说明一下：在 Redis 2.8 版本之前，进行主从复制时一定会顺序执行上述两个步骤，而从 2.8 开始则可能只需要执行命令传播即可。在下文也会解释为什么会这样？

### 同步（全量同步） ###

当客户端向从服务器发送SLAVEOF命令，要求从服务器复制主服务器时，从服务器首先需要执行同步操作，将从服务器的数据库状态更新至主服务器当前所处的数据库状态。

从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成，具体步骤如下：

1）从服务器连接主服务器，发送SYNC命令；

2）主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件，并使用缓冲区记录此后执行的所有写命令；

3）主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；

5）主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70][]

### 命令传播（增量同步） ###

在执行完同步操作之后，主从服务器之间数据库状态已经相同了。但这个状态并非一成不变，如果主服务器执行了写操作，那么主服务器的数据库状态就会修改，并导致主从服务器状态不再一致。

所以为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令，也就是造成主从服务器不一致的那条写命令，发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。注：Redis 同步的是指令流。

## 六、优化版同步操作 ##

### 旧版复制功能的缺陷 ###

在Redis中，从服务器对主服务器的复制可以分为以下两种情况：

*  初次复制：从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同；
 *  断线后重复制：处于命令传播阶段的主从服务器因为网络原因而中断了复制，但从服务器通过自动重连接重新连上了主服务器，并继续复制主服务器。

对于初次复制来说，旧版复制功能能够很好地完成任务，但对于断线后重复制来说，旧版复制功能虽然也能让主从服务器重新回到一致状态，但效率却非常低。

我们给出一个例子进行说明：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 2][]

从服务器终于重新连接上主服务器，因为这时主从服务器的状态已经不再一致，所以从服务器将向主服务器发送SYNC命令，而主服务器会将包含键k1至键k10089的RDB文件发送给从服务器，从服务器通过接收和载入这个RDB文件来将自己的数据库更新至主服务器数据库当前所处的状态。

上面给出的例子可能有一点理想化，因为在主从服务器断线期间，主服务器执行的写命令可能会有成百上千个之多，而不仅仅是两三个写命令。但总的来说，主从服务器断开的时间越短，主服务器在断线期间执行的写命令就越少，而执行少量写命令所产生的数据量通常比整个数据库的数据量要少得多，在这种情况下，为了让从服务器补足一小部分缺失的数据，却要让主从服务器重新执行一次SYNC命令，这种做法无疑是非常低效的。

### SYNC命令是一个非常耗费资源的操作 ###

SYNC命令是非常消耗资源的，因为每次执行SYNC命令，主从服务器需要执行以下操作：

1.  主服务器需要执行BGSAVE命令来生成RDB文件，**这个生成操作会耗费主服务器大量的CPU、内存和磁盘I/O资源**；
2.  主服务器需要将自己生成的RDB文件发送给从服务器，**这个发送操作会耗费主从服务器大量的网络资源（带宽和流量），并对主服务器响应命令请求的时间产生影响**；
3.  接收到RDB文件的从服务器需要载入主服务器发来的RDB文件，并且在载入期间，**从服务器会因为阻塞而没办法处理命令请求**。

SYNC是一个如此消耗资源的命令，所以Redis最好在真需要的时候才需要执行SYNC命令。

### 新版复制功能的实现 ###

为了解决旧版复制功能在处理断线重复制情况时的低效问题，Redis从2.8版本开始，使用**PSYNC**命令代替SYNC命令来执行复制时的同步操作。

PSYNC命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization）两种模式：

*  完整重同步：用于处理初次复制情况，执行步骤和SYNC命令的执行步骤基本一样，它们都是通过让主服务器创建并发送RDB文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同步；
 *  部分重同步：用于处理断线后重复制情况，当从服务器在断线后重新连接主服务器时，**如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态。**

上面的介绍中，出现了「**如果条件允许**」，那又是鬼什么条件呢？—— 其实就是一个偏移量的比较，具体可以继续往下看。

### **部分重同步的实现** ###

部分重同步功能由以下三个部分构成：

*  主服务器的**复制偏移量**（replication offset）和从服务器的**复制偏移量**；
 *  **主服务器的复制积压缓冲区（replication backlog）**；
 *  **服务器的运行ID**（run ID）。

**复制偏移量**

执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量：

*  主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N；
 *  从服务器每次收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量的值加上N；

通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致状态：

*  如果主从服务器处于一致状态，那么主从服务器两者的偏移量总是相同的；
 *  相反，如果主从服务器两者的偏移量并不相同，那么说明主从服务器并未处于一致状态。

如下面的情况：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 3][]

假设从服务器A在断线之后就立即重新连接主服务器，并且成功，那么接下来，**从服务器将向主服务器发送PSYNC命令，报告从服务器A当前的复制偏移量为10086，**那么这时，主服务器应该对从服务器执行完整重同步还是部分重同步呢？如果执行部分重同步的话，主服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢？以上问题的答案都和复制积压缓冲区有关。

**复制积压缓冲区**

复制积压缓冲区是由主服务器维护的一个固定长度（fixed-size）先进先出（FIFO）队列，默认大小为1MB。

和普通先进先出队列随着元素的增加和减少而动态调整长度不同，固定长度先进先出队列的长度是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。

当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面，如图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 4][]

因此，主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量，就像下表所示的那样。

![20190604204459400.png][]

当从服务器重新连上主服务器时，从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：

*  如果offset偏移量之后的数据（也即是偏移量offset+1开始的数据）仍然存在于复制积压缓冲区里面，那么主服务器将对从服务器执行部分重同步操作；
 *  相反，如果offset偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。

**服务器运行ID**

除了复制偏移量和复制积压缓冲区之外，实现部分重同步还需要用到服务器运行ID（run ID）：

*  每个Redis服务器，**不论主服务器还是从服务，都会有自己的运行ID**；
 *  运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成，例如53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3；

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来（注意哦，是**从服务器保存了主服务器的ID**）。

当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID：

*  如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以继续尝试执行部分重同步操作；
 *  相反地，如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同，那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步操作。

### PSYNC命令的实现 ###

PSYNC命令的调用方法有两种：

*  如果从服务器以前没有复制过任何主服务器，或者之前执行过SLAVEOF no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令，主动请求主服务器进行完整重同步（因为这时不可能执行部分重同步）；
 *  如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC <runid> <offset>命令：其中runid是上一次复制的主服务器的运行ID，而offset则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。

根据情况，接收到PSYNC命令的主服务器会向从服务器返回以下三种回复的其中一种：

*  如果主服务器返回+FULLRESYNC <runid> <offset>回复，那么表示主服务器将与从服务器执行完整重同步操作：其中runid是这个主服务器的运行ID，从服务器会将这个ID保存起来，在下一次发送PSYNC命令时使用；而offset则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量；
 *  如果主服务器返回+CONTINUE回复，那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了；
 *  如果主服务器返回-ERR回复，那么表示主服务器的版本低于Redis 2.8，它识别不了PSYNC命令，从服务器将向主服务器发送SYNC命令，并与主服务器执行完整同步操作。

## 七、心跳检测 ##

刚才提到，主从同步有同步和命令传播 2 个步骤，当完成了同步之后，主从服务器就会进入命令传播阶段，在命令传播阶段，从服务器默认会以**每秒一次的频率**，向主服务器发送命令：**REPLCONF ACK <replication\_offset>**，其中replication\_offset是从服务器当前的复制偏移量。

发送REPLCONF ACK命令对于主从服务器有三个作用：

*  检测主从服务器的网络连接状态；
 *  辅助实现min-slaves选项；
 *  检测命令丢失。

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

如果主服务器超过一秒钟没有收到从服务器发来的REPLCONF ACK命令，那么主服务器就知道主从服务器之间的连接出现问题了。

通过向主服务器发送**INFO replication命令**，在列出的从服务器列表的lag一栏中，我们可以看到相应从服务器最后一次向主服务器发送REPLCONF ACK命令距离现在过了多少秒：

127.0.0.1:6379> INFO replication  
\# Replication  
role:master  
connected\_slaves:2  
slave0:ip=127.0.0.1,port=12345,state=online,offset=211,**lag=0  **

\#刚刚发送过 REPLCONF ACK命令  
slave1:ip=127.0.0.1,port=56789,state=online,offset=197,**lag=15   **

\#15秒之前发送过REPLCONF ACK命令

*master\_repl\_offset:211  
repl\_backlog\_active:1  
repl\_backlog\_size:1048576  
repl\_backlog\_first\_byte\_offset:2  
repl\_backlog\_histlen:210*

在一般情况下，**lag的值应该在0秒或者1秒之间跳动，**如果超过1秒的话，那么说明主从服务器之间的连接出现了故障。

### **辅助实现min-slaves配置选项** ###

Redis的**min-slaves-to-write**和**min-slaves-max-lag**两个选项可以**防止主服务器在不安全的情况下执行写命令。**

举个例子，如果我们向主服务器提供以下设置：

min-slaves-to-write 3
    min-slaves-max-lag 10

那么在**从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10秒时**，主服务器将拒绝执行写命令，这里的延迟值就是上面提到的INFO replication命令的lag值。

### **检测命令丢失** ###

我们从命令：REPLCONF ACK <replication\_offset>就可以知道，每发送一次这个命令从服务器都会向主服务器报告一次自己的复制偏移量。那此时尽管主服务器发送给从服务器的SET key value丢失了。也无所谓，主服务器马上就知道了。

## 八、主从同步具体过程 ##

### **步骤1：设置主服务器的地址和端口** ###

当客户端向从服务器发送以下命令时：

127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
    OK

从服务器首先要做的就是将客户端给定的主服务器IP地址127.0.0.1以及端口6379保存到服务器状态的masterhost属性和masterport属性里面：

struct redisServer {
        // ...
        // 主服务器的地址
        char *masterhost;
        // 主服务器的端口
        int masterport;
        // ...
    };

SLAVEOF命令是一个异步命令，在完成masterhost属性和masterport属性的设置工作之后，**从服务器将向发送SLAVEOF命令的客户端返回OK，表示复制指令已经被接收，而实际的复制工作将在OK返回之后才真正开始执行。**

### **步骤2：建立套接字连接** ###

在SLAVEOF命令执行之后，从服务器将根据命令所设置的IP地址和端口，创建连向主服务器的套接字连接，如图15-14所示。

![20190604205112977.png][]

如果从服务器创建的套接字能成功连接（connect）到主服务器，那么从服务器将为这个套接字关联一个专门用于处理复制工作的文件事件处理器，这个处理器将负责执行后续的复制工作，比如接收RDB文件，以及接收主服务器传播来的写命令，诸如此类。

而主服务器在接受（accept）从服务器的套接字连接之后，将为该套接字创建相应的客户端状态，并将从服务器看作是一个连接到主服务器的客户端来对待，这时从服务器将同时具有服务器（server）和客户端（client）两个身份：从服务器可以向主服务器发送命令请求，而主服务器则会向从服务器返回命令回复。

### **步骤3：发送PING命令** ###

从服务器成为主服务器的客户端之后，做的第一件事就是向主服务器发送一个PING命令。

这个PING命令主要是为了：

*  通过发送PING命令检查套接字的读写状态；
 *  通过PING命令可以检查主服务器能否正常处理命令。

从服务器在发送PING命令之后可能遇到以下三种情况：

*  主服务器向从服务器返回了一个命令回复，但从服务器却不能在规定的时限内读取命令回复的内容(timeout)，说明网络连接状态不佳，从服务器将断开并重新创建连向主服务器的套接字；
 *  如果主服务器返回一个错误，那么表示主服务器暂时没有办法处理从服务器的命令请求，，从服务器也将断开并重新创建连向主服务器的套接字；
 *  如果从服务器读取到"PONG"回复，那么表示主从服务器之间的网络连接状态正常，那就继续执行下面的复制步骤。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 5][]

### **步骤4：身份验证** ###

从服务器在收到主服务器返回的"PONG"回复之后，下一步要做的就是决定是否进行身份验证：

*  如果从服务器**设置了masterauth选项**，那么进行身份验证。否则不进行身份认证；

在需要进行身份验证的情况下，从服务器将向主服务器发送一条**AUTH命令，命令的参数为从服务器masterauth选项的值**。

从服务器在身份验证阶段可能遇到的情况有以下几种：

*  主服务器没有设置requirepass选项，从服务器没有设置masterauth，那么就继续后面的复制工作；
 *  如果从服务器的通过AUTH命令发送的密码和主服务器requirepass选项所设置的密码相同，那么也继续后面的工作，否则返回错误invaild password;
 *  如果主服务器设置了requireoass选项，但从服务器没有设置masterauth选项，那么服务器将返回NOAUTH错误。反过来如果主服务器没有设置requirepass选项，但是从服务器却设置了materauth选项，那么主服务器返回no password is set错误；

所有错误只有一个结果：中止目前的复制工作，并从创建套接字开始重新执行复制，直到身份验证通过，或者从服务器放弃执行复制为止。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 6][]

### **步骤5：发送端口信息** ###

身份验证步骤之后，从服务器将执行命令**REPLCONF listening-port <port-number>**，向主服务器发送从服务器的监听端口号。

主服务器在接收到这个命令之后，会将端口号记录在从服务器所对应的客户端状态的slave\_listening\_port属性中：

typedef struct redisClient {
        // ...
        // 从服务器的监听端口号
        int slave_listening_port;
        // ...
    
    ｝redisClient;

slave\_listening\_port属性目前唯一的作用就是在主服务器执行INFO replication命令时打印出从服务器的端口号。

### **步骤6：同步** ###

在这一步，从服务器将向主服务器发送PSYNC命令，执行同步操作，并将自己的数据库更新至主服务器数据库当前所处的状态。

需要注意的是在执行同步操作前，只有从服务器是主服务器的客户端。但是执行同步操作之后，主服务器也会称为从服务器的客户端：

*  如果PSYNC命令执行的是完整同步操作，那么主服务器只有成为了从服务器的客户端才能将保存在**缓冲区中的写命令**发送给从服务器执行；
 *  如果PSYNC命令执行的是部分同步操作，那么主服务器只有成为了从服务器的客户端才能将保存在**复制积压缓冲区中的写命令**发送给从服务器执行；

### **步骤7：命令传播** ###

当完成了同步之后，主从服务器就会进入命令传播阶段，这时主服务器只要一直将自己执行的写命令发送给从服务器，而从服务器只要一直接收并执行主服务器发来的写命令，就可以保证主从服务器一直保持一致了。

参考：

[https://www.cnblogs.com/lukexwang/p/4711977.html][https_www.cnblogs.com_lukexwang_p_4711977.html]

[https://blog.csdn.net/weixin\_42711549/article/details/83061052][https_blog.csdn.net_weixin_42711549_article_details_83061052]

[https://www.jianshu.com/p/9b3136a1d021][https_www.jianshu.com_p_9b3136a1d021]

[https://mp.weixin.qq.com/s/8jmPwEZ7CPg0pVd79in\_Tg][https_mp.weixin.qq.com_s_8jmPwEZ7CPg0pVd79in_Tg]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70]: /images/20220123/330561bbe19a436c94b0a330ac552818.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 1]: /images/20220123/71c00708aa52426f97e9a5b78291ff49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 2]: /images/20220123/e230598cd8d241f4b0653e88d578ed27.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 3]: /images/20220123/de41ef1bba7a4e9b8f72ae8e158f7803.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 4]: /images/20220123/2ad3a5d71599499f9685d6f60405a5c5.png
[20190604204459400.png]: /images/20220123/18404bb568304839a00faf2a7841fb2c.png
[20190604205112977.png]: /images/20220123/54d26ef6770c4ccdaeda6fcb8e9b9ff3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 5]: /images/20220123/d45511406ec3404597afb9553dcb225e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rpd2Vpa2FuZw_size_16_color_FFFFFF_t_70 6]: /images/20220123/06eeceee14bb4561b70688eb32c733d2.png
[https_www.cnblogs.com_lukexwang_p_4711977.html]: https://www.cnblogs.com/lukexwang/p/4711977.html
[https_blog.csdn.net_weixin_42711549_article_details_83061052]: https://blog.csdn.net/weixin_42711549/article/details/83061052
[https_www.jianshu.com_p_9b3136a1d021]: https://www.jianshu.com/p/9b3136a1d021
[https_mp.weixin.qq.com_s_8jmPwEZ7CPg0pVd79in_Tg]: https://mp.weixin.qq.com/s/8jmPwEZ7CPg0pVd79in_Tg