redis学习——数据持久化（看这一篇就够了）

分手后的思念是犯贱 2022-09-04 12:42 157阅读 0赞

# 一、概述 #

Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的，然而当Redis重启后，所有存储在内存中的数据将会丢失，在很多情况下是无法容忍这样的事情的。所以，我们需要将内存中的数据持久化！典型的需要持久化数据的场景如下：

*  将Redis作为数据库使用；
 *  将Redis作为缓存服务器使用，但是缓存miss后会对性能造成很大影响，所有缓存同时失效时会造成服务雪崩，无法响应。

本文介绍Redis所支持的两种数据持久化方式。

# 二、Redis 持久化之RDB和AOF #

Redis支持两种数据持久化方式：RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。

# RDB #

## 1、RDB方式 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA5NjM1Mw_size_16_color_FFFFFF_t_70_pic_center]

RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，Redis会在以下几种情况下对数据进行快照：

*  根据配置规则进行自动快照；
 *  用户执行SAVE, BGSAVE命令；
 *  执行FLUSHALL命令；
 *  执行复制（replication）时。

## 2、执行快照的场景： ##

**（1）根据配置自动快照**

Redis允许用户自定义快照条件，当满足条件时自动执行快照。缺省情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb，此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开redis.windows.conf文件之后，我们搜索save，可以看到下面的配置信息：

在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照；

在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照；

在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

每个快照条件独占一行，他们之间是或（||）关系，只要满足任何一个就进行快照。上面配置save后的第一个参数T是时间，单位是秒，第二个参数M是更改的键的个数，含义是：当时间T内被更改的键的个数大于M时，自动进行快照。比如save 900 1的含义是15分钟内(900s)被更改的键的个数大于1时，自动进行快照操作。这点我在 [redis学习——redis.config简单阅读][redis_redis.config] 中详细介绍过。

**（2）执行SAVE或BGSAVE命令**

除了让Redis自动进行快照外，当我们需要重启，迁移，备份Redis时，我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作。

*  SAVE命令：  
    当执行SAVE命令时，Redis同步进行快照操作，期间会阻塞所有来自客户端的请求，所以放数据库数据较多时，应该避免使用该命令；
 *  BGSAVE命令：  
    从命令名字就能看出来，这个命令与SAVE命令的区别就在于该命令的快照操作是在后台异步进行的，进行快照操作的同时还能处理来自客户端的请求。执行BGSAVE命令后Redis会马上返回OK表示开始进行快照操作，如果想知道快照操作是否已经完成，可以使用LASTSAVE命令返回最近一次成功执行快照的时间，返回结果是一个Unix时间戳。

**（3）执行FLUSHALL命令**

当执行FLUSHALL命令时，Redis会清除数据库中的所有数据。需要注意的是：**不论清空数据库的过程是否触发了自动快照的条件，只要自动快照条件不为空，Redis就会执行一次快照操作，当没有定义自动快照条件时，执行FLUSHALL命令不会进行快照操作。**

**（4）执行复制**

当设置了主从模式时，Redis会在复制初始化时进行自动快照。

**快照原理**

Redis默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中，可以通过配置文件中的dir和dbfilename两个参数分别指定快照文件的存储路径和文件名，默认的存储路径和文件名如下图所示：

1.  Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
2.  父进程继续处理来自客户端的请求，子进程开始将内存中的数据写入硬盘中的临时文件；
3.  当子进程写完所有的数据后，用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

需要注意的是：

> **在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻，父进程和子进程共享同一块内存数据，当父进程需要修改其中的某片数据（如执行写命令）时，操作系统会将该片数据复制一份以保证子进程不受影响，所以RDB文件存储的是执行fork操作那一刻的内存数据。所以RDB方式理论上是会存在丢数据的情况的(fork之后修改的的那些没有写进RDB文件)。**

通过上述的介绍可以知道，快照进行时是不会修改RDB文件的，只有完成的时候才会用临时文件替换老的RDB文件，所以就保证任何时候RDB文件的都是完整的。这使得我们可以通过定时备份RDB文件来实现Redis数据的备份。RDB文件是经过压缩处理的二进制文件，所以占用的空间会小于内存中数据的大小，更有利于传输。

Redis启动时会自动读取RDB快照文件，将数据从硬盘载入到内存，根据数量的不同，这个过程持续的时间也不尽相同，通常来讲，一个记录1000万个字符串类型键，大小为1GB的快照文件载入到内存需要20-30秒的时间。

## 3、示例： ##

[root@itdragon bin]# vim redis.conf
    save 900 1
    save 120 5
    save 60 10000
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    127.0.0.1:6379> keys *
    (empty list or set)
    127.0.0.1:6379> set key1 value1
    OK
    127.0.0.1:6379> set key2 value2
    OK
    127.0.0.1:6379> set key3 value3
    OK
    127.0.0.1:6379> set key4 value4
    OK
    127.0.0.1:6379> set key5 value5
    OK
    127.0.0.1:6379> set key6 value6
    OK
    127.0.0.1:6379> SHUTDOWN
    not connected> QUIT
    [root@itdragon bin]# cp dump.rdb dump_bk.rdb
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    127.0.0.1:6379> FLUSHALL 
    OK
    127.0.0.1:6379> keys *
    (empty list or set)
    127.0.0.1:6379> SHUTDOWN
    not connected> QUIT
    [root@itdragon bin]# cp dump_bk.rdb dump.rdb
    cp: overwrite `dump.rdb'? y
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    127.0.0.1:6379> keys *
    1) "key5"
    2) "key1"
    3) "key3"
    4) "key4"
    5) "key6"
    6) "key2"

第一步：vim 修改持久化配置时间，120秒内修改5次则持久化一次。  
第二步：重启服务使配置生效。  
第三步：分别set 5个key，过两分钟后，在bin的当前目录下会自动生产一个dump.rdb文件。（set key6 是为了验证shutdown有触发RDB快照的作用）  
第四步：将当前的dump.rdb 备份一份（模拟线上工作）。  
第五步：执行FLUSHALL命令清空数据库数据（模拟数据丢失）。  
第六步：重启Redis服务，恢复数据…咦？？？？( ′◔ ‸◔\`)。数据是空的？？？？这是因为FLUSHALL也有触发RDB快照的功能。  
第七步：将备份的 dump\_bk.rdb 替换 dump.rdb 然后重新Redis。

注意点：SHUTDOWN 和 FLUSHALL 命令都会触发RDB快照，这是一个坑，请大家注意。

其他命令：

*  keys \* 匹配数据库中所有 key
 *  save 阻塞触发RDB快照，使其备份数据
 *  FLUSHALL 清空整个 Redis 服务器的数据(几乎不用)
 *  SHUTDOWN 关机走人（很少用）

## 4、RDB 的优缺点 ##

优点：

1.  适合大规模的数据恢复。
2.  如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：

1.  数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2.  备份时占用内存，因为Redis在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。

所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

注意，使用过后将配置恢复，默认配置能够满足日常使用。

# AOF #

AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个**写操作**，并**追加**到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

## 1、从配置文件了解AOF ##

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容

**1 redis 默认关闭，开启需要手动把no改为yes**

appendonly yes

开启之后，Redis每执行一条写命令就会将该命令写入硬盘中的AOF文件。AOF文件保存路径和RDB文件路径是一致的，都是通过dir参数配置，默认文件名是：appendonly.aof，可以通过配置appendonlyfilename参数修改，例如：  
![在这里插入图片描述][c9d0841faaf44f89b4880e6f422fc617.png_pic_center]

**2 指定本地数据库文件名，默认值为 appendonly.aof**

appendfilename "appendonly.aof"

**3 指定更新日志条件**

# appendfsync always
    appendfsync everysec
    # appendfsync no

解说：

*  第一行表示每次AOF写入一个命令都会执行同步操作，这是最安全也是最慢的方式；
 *  第二行表示每秒钟进行一次同步操作，一般来说使用这种方式已经足够；
 *  第三行表示不主动进行同步操作，这是最不安全的方式。

选项：

1.  appendfsync no  
    当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
2.  appendfsync everysec  
    当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。
3.  appednfsync always  
    当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响。

建议采用 appendfsync everysec（缺省方式）

快照模式可以和AOF模式同时开启，互补影响。

**4 配置重写触发机制**

auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

解说：

*  第一行的意思是，目前的AOF文件的大小超过上一次重写时的AOF文件的百分之多少时再次进行重写，如果之前没有重写过，则以启动时AOF文件大小为依据。
 *  第二行的意思是，当AOF文件的大小大于64MB时才进行重写，因为如果AOF文件本来就很小时，有几个无效的命令也是无伤大雅的事情。  
    这两个配置项通常一起使用。
 *  我们还可以手动执行BGREWRITEAOF命令主动让Redis重写AOF文件

## 2、 触发AOF快照 ##

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

## 3、根据AOF文件恢复数据 ##

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。

## 4、AOF的重写机制 ##

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

[root@itdragon bin]# vim appendonly.aof
    appendonly yes
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    127.0.0.1:6379> keys *
    (empty list or set)
    127.0.0.1:6379> set keyAOf valueAof
    OK
    127.0.0.1:6379> FLUSHALL 
    OK
    127.0.0.1:6379> SHUTDOWN
    not connected> QUIT
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    127.0.0.1:6379> keys *
    1) "keyAOf"
    127.0.0.1:6379> SHUTDOWN
    not connected> QUIT
    [root@itdragon bin]# vim appendonly.aof
    fjewofjwojfoewifjowejfwf
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    Could not connect to Redis at 127.0.0.1:6379: Connection refused
    not connected> QUIT
    [root@itdragon bin]# redis-check-aof --fix appendonly.aof 
    'x 3e: Expected prefix '*', got: '
    AOF analyzed: size=92, ok_up_to=62, diff=30
    This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
    Continue? [y/N]: y
    Successfully truncated AOF
    [root@itdragon bin]# ./redis-server redis.conf
    [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
    127.0.0.1:6379> keys *
    1) "keyAOf"

第一步：修改配置文件，开启AOF持久化配置。  
第二步：重启Redis服务，并进入Redis 自带的客户端中。  
第三步：保存值，然后模拟数据丢失，关闭Redis服务。  
第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。  
第五步：修改appendonly.aof，模拟文件异常情况。  
第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。  
第七步：校验appendonly.aof 文件。重启Redis 服务后正常。

补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？

## 5、AOF 的优缺点 ##

优点：数据的完整性和一致性更高  
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

# 三、二者的区别 #

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA5NjM1Mw_size_16_color_FFFFFF_t_70_pic_center 3]  
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

![在这里插入图片描述][46370e18ed464beabfb9628b8fbab4fc.png_pic_center]

# 四、二者的优缺点 #

**RDB存在哪些优势呢？**

1.  一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2.  对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3.  性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4.  相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

**RDB又存在哪些劣势呢？**

1.  如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2.  由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

**AOF的优势有哪些呢？**

1.  该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2.  由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3.  如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4.  AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

**AOF的劣势有哪些呢？**

1.  对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2.  根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

# 五、常用配置 #

## RDB持久化配置 ##

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
    save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
    save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

## AOF持久化配置 ##

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always     #每次有数据修改发生时都会写入AOF文件。
    appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。
    appendfsync no          #从不同步。高效但是数据不会被持久化。

# 六、扩展 #

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式

*  在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
 *  RDB  
    的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

*  因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1  
    这条规则。
 *  如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
 *  如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据， 启动脚本也要比较两个Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。

--------------------

# 七、参考文章 #

Redis 持久化之RDB和AOF：[https://www.cnblogs.com/itdragon/p/7906481.html][https_www.cnblogs.com_itdragon_p_7906481.html]

redis学习（九）——数据持久化：[https://www.cnblogs.com/xiaoxi/p/7065328.html][https_www.cnblogs.com_xiaoxi_p_7065328.html]

狂神redis笔记。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA5NjM1Mw_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/f97d84c50cf8471187ee95db2d0b5db9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA5NjM1Mw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20220829/3574757dfc334e14ba6df31f5a2ea5a3.png
[redis_redis.config]: https://blog.csdn.net/weixin_44096353/article/details/119684236?spm=1001.2014.3001.5501
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA5NjM1Mw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20220829/0be79e40cd484a1488c1a8c56c8ee88a.png
[c9d0841faaf44f89b4880e6f422fc617.png_pic_center]: /images/20220829/695f671508744cfa884a7abb2a72e520.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDA5NjM1Mw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20220829/aab5f21fbeab4ad4a849a90f76e94086.png
[46370e18ed464beabfb9628b8fbab4fc.png_pic_center]: /images/20220829/3f036002287444ad88305f6eaae2d2fe.png
[https_www.cnblogs.com_itdragon_p_7906481.html]: https://www.cnblogs.com/itdragon/p/7906481.html
[https_www.cnblogs.com_xiaoxi_p_7065328.html]: https://www.cnblogs.com/xiaoxi/p/7065328.html