redis持久化:RDB和AOF

布满荆棘的人生 2024-02-18 13:07 28阅读 0赞

**目录**

RDB 持久化

1、修改配置文件：redis.conf

2、RDB模式自动触发保存快照

3、RDB模式手动触发保存快照

4、RDB的优缺点

AOF持久化

1、AOF持久化工作流程

2、修改配置文件开启AOF

3、AOF优缺点

4、AOF的重写机制原理

RDB+AOF混合模式

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

**redis持久化有两种方式：RDB和AOF**

**RDB** 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。  
**AOF** 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

#### **RDB 持久化** ####

redis关于持久化配置文件的变化：

**redis6.0.16以下**

![00965fcf238f4edf93702ee374e76890.png][]

save 900 1:每隔900s(15min)，如果有超过1个key 发生了变化，就写一份新的RDB文件

save 300 10:每隔300s(5min)，如果有超过10 个key发生了变化，就写一份新的 RDB文件

save 60 10000:每隔60s(1min)，如果有超过10000个key 发生了变化，就写一份新的RDB文件

**redis6.2以上**

![b8524248111f4bb0acf146e7bc651292.png][]

save 3600 1:每隔3600s(1小时)，如果有超过1个key 发生了变化，就写一份新的RDB文件

save 300 10:每隔300s(5min)，如果有超过100个key发生了变化，就写一份新的 RDB文件

save 60 10000:每隔60s(1min)，如果有超过10000个key 发生了变化，就写一份新的RDB文件

**这里使用的是docker容器中安装的redis**

##### **1、修改配置文件：redis.conf** #####

快照文件名，建议加上端口号，多个redis容器好区分

![a1421f18ccc14697a79f75a6c2fe10ea.png][]

##### **2、RDB模式自动触发保存快照** #####

save可以修改保存时间：5秒中2次修改就会触发快照

![d0a1b87abc8c4275b887142047e36203.png][]

重新启动容器

> docker restart redis

进入容器查看是否配置成功

> docker exec -it redis bash \#进入容器  
> redis-cli \#redis客户端

查看快照文件目录：config get dir

/data# redis-cli -a 123456
    Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
    127.0.0.1:6379> config get requirepass
    1) "requirepass"
    2) "123456"
    127.0.0.1:6379> config get dir
    1) "dir"
    2) "/data"

测试：

测试前
    [root@localhost data]# ll
    总用量 4
    -rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb
    
    
    127.0.0.1:6379> set k1 v1
    OK
    127.0.0.1:6379> set k2 v2
    OK
    
    测试后
    [root@localhost data]# ll
    总用量 8
    -rw-------. 1 polkitd input 107 11月 22 21:20 dump3679.rdb
    -rw-------. 1 polkitd input 392 11月 21 21:49 dump.rdb

总结：5秒内修改2次或2次修改大于5秒都会触发，

redis重启就会读取快照恢复，执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义

##### **3、**RDB模式**手动触发保存快照** #####

Redis提供了两个命令来生成RDB文件，分别是save和bgsave

save：在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用  
  
BGSAVE(默认)：Redis会在后台异步进行快照操作，不阻塞快照同时还可以响应客户端请求，触发方式会fork一个子进程由子进程复制持久化过程

![144f42cdb2a54cd19e7bbdc22f1a3d87.png][]

lastsave可以查看最后一次的时间戳  
  
![3abac9833f9d4c018211cb833a870ce0.png][]

##### 4、RDB的优缺点 #####

**RDB的优点**

1、适合大规模的数据恢复

2、按照业务定时备份  
3、对数据完整性和一致性要求不高  
4、RDB 文件在内存中的加载速度要比AOF快得多

**RDB的缺点**

1、在一定间隔时间做一次备份，所以如果redis意外宕机的话,就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失

2、内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能  
3、RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一俯，大致2倍的膨胀性，需要考虑

**修复RDB文件**

> cd /usr/local/bin

进入bin目录找到：redis-check-rdb 命令，指定rdb文件

![1d84f87dc02c43e5a875374713e21029.png][]

> redis-check-rdb /usr/local/redis/data/dump6379.rdb

![eba3709443e0432aa4967e1fd5492717.png][]

禁用RDB快照，把save前面的注释去掉，写个空字符串

![f5b860fbae574b6a97ed6502b9e5785c.png][]

**RDB配置参数，使用默认即可**

![89e0e4277ebc47348cf1b9e112bb4889.png][]

![c3c6a9d7c9544263be7c8ee639373196.png][]

![916b29698e99497aa06799f7fcfd0397.png][] ![bad2b3728f24441ba37ad02caecc0145.png][]

#### **AOF持久化** ####

默认情况下，redis是没有开启AOF(append only file)的。

开启AOF功能需要设置配置: appendonly yes

##### 1、AOF持久化工作流程 #####

1、Client作为命令的来源，会有多个源头以及源源不断的请求命令。  
2、在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。  
3、AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。  
4、随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。

AOF缓冲区三种写回策略

Always：同步写回，每个写命令执行完立刻同步地将日志写回磁盘。

everysec：每秒写回，每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘。

no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

##### 2、修改配置文件开启AOF #####

开启AOF：appendonly改为yes

![48de01e5e70a4b07adcb52ce19a90b80.png][]

策略为默认

![3f96354b977d41ce877429db54668a8a.png][]

**文件保存路径**

redis6：AOF保存文件的位置和RDB保存文件的位置一样，都是通过redis.conf配置文件的dir配置

redis7：相对于redis6会多建一个appendonlydir文件路径

![87e9ca70903a46b9a9ffdcae83fc62e3.png][]  
  
**文件名称**

redis6只有一个文件

redis7由Multi Part AOF的设计变成3个文件：base基本文件，incr增量文件，manifest清单文件

示例：开启AOF，写入数据

![afbfdea48d7740afa0b80449a20c2771.png][]

发现多一个文件夹

![4e14f555b2d94790ab29359ad0a513bf.png][]

![3f57e8348e924f299c993e3766ca9dda.png][]

**AOF异常文件修复**

进入bin目录：cd /usr/local/bin

![bd2a0eed7fd549d2aa9a02ea5c6e0901.png][]

然后进入持久化文件，输入命令

> redis-check-aof --fix appendonly.aof.1.incr.aof

![2c73f3048c1548618b8333c10ea80d2c.png][]

"AOF is valid" 表明 AOF 文件是有效的，没有发现任何问题。

##### **3、AOF优缺点** #####

**AOF优点：**更好的保护数据不丢失、性能高、可做紧急恢复。

**AOF缺点：**相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdbaof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同。

由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

##### **4、AOF的重写机制原理** #####

1、在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

2、与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

3、当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

4、当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中。

5、重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

#### **RDB+AOF混合模式** ####

当RDB，AOF都存在时，redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文供保存的数据集要完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。

**那么只使用AOF呢?**  
建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。

开启混合模式：在redis.conf中redis默认开启

![4b145e566ecb410dbb2ea9ed23f21d76.png][]

[00965fcf238f4edf93702ee374e76890.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/8f52c3c055434c05992722fd3de1ada4.png
[b8524248111f4bb0acf146e7bc651292.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/22914529f5d648629fb2061de1d6dd6c.png
[a1421f18ccc14697a79f75a6c2fe10ea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/1d7bc486a14f4220b7ba251098c47409.png
[d0a1b87abc8c4275b887142047e36203.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/767fce3ca5a8427293834840f5ccba89.png
[144f42cdb2a54cd19e7bbdc22f1a3d87.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/f6ebadbb25c6464dbfea5e14fb54a5ee.png
[3abac9833f9d4c018211cb833a870ce0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/9921985a3d31459282b1bc27eadd69c5.png
[1d84f87dc02c43e5a875374713e21029.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/6a764ff908074b7eb0ab571521a00737.png
[eba3709443e0432aa4967e1fd5492717.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/040304b454b14e18ba6b866cfca9e538.png
[f5b860fbae574b6a97ed6502b9e5785c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/6c1e5e9215b449008fa46623f0469a6f.png
[89e0e4277ebc47348cf1b9e112bb4889.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/abc806c72c1d444c87a74e857f6e194e.png
[c3c6a9d7c9544263be7c8ee639373196.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/7b51f5cf6748438b85d3c753aa940459.png
[916b29698e99497aa06799f7fcfd0397.png]: https://img-blog.csdnimg.cn/916b29698e99497aa06799f7fcfd0397.png
[bad2b3728f24441ba37ad02caecc0145.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/b050a80d1dd04947ae75882c6798c0f5.png
[48de01e5e70a4b07adcb52ce19a90b80.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/3de688a0f60048dfb60285a0b17b24b7.png
[3f96354b977d41ce877429db54668a8a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/a396a2303b78419eb52625caa93f450b.png
[87e9ca70903a46b9a9ffdcae83fc62e3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/45989941f43843ccae6b772fd2ce524c.png
[afbfdea48d7740afa0b80449a20c2771.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/dd833f5aed934602a31ecd340e32791a.png
[4e14f555b2d94790ab29359ad0a513bf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/444156512f90454aa1318b9f4fc86e19.png
[3f57e8348e924f299c993e3766ca9dda.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/fdbd01707f1c47f18e5c4a022bfc320e.png
[bd2a0eed7fd549d2aa9a02ea5c6e0901.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/28f41fec703943fc8214369fa665d2c4.png
[2c73f3048c1548618b8333c10ea80d2c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/5f99ed17fbe64457bbdc8b6541b42bdb.png
[4b145e566ecb410dbb2ea9ed23f21d76.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/18/5b47b748602340aba77dc80ac5237943.png