Linux中使用redis（五）持续化

曾经终败给现在 2024-03-22 09:57 11阅读 0赞

**目录**

一、持久化

前言

1、AOF

1）AOF是什么

2） AOF持久化流程

3）特点：

4、 AOF默认不开启

5、 AOF和RDB同时开启，redis听谁的

6、 AOF启动修复恢复

7、 AOF同步频率设置

8、 Rewrite压缩

9、 优势

10、 劣势

11 、总结(Which one)

12、测试

2、RDB

1) RDB是什么

RDB配置

2) 备份是如何进行的

3）fork

4） dump.rdb文件

5） rdb的备份

6） RDB持久化的优势

7） RDB劣势

8）如何停止动态RDB

9) 特点：

10、总结：

11、测试

3、RDB和AOF总结：

4、RDB和AOF的区别

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

## 一、持久化 ##

### 前言 ###

Redis 是**内存数据库**，如果不将[内存][Link 1]中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以 Redis 提供了**持久化功能** !

**RDB和\[AOP\]解决的问题**

**由于redist是内存型数据库**，有时候可能出现redis挂掉而导致缓存丢失的问题，RDB 和 AOF 都是为了解决这个问题，也是redis官方提出的两种数据持久化方案

### 1、AOF ###

**磁盘文件在虚拟机中：/var/lib/redis/6379/appendonlydir目录下，后缀名为.aof的文件，set的数据都在该文件里面**

#### **1）AOF是什么** ####

**以日志的形式来记录每个写操作（增量保存）**，**将Redis执行过的所有写指令记录下来**(**读操作不记录**)， **只许追加文件但不可以改写文件**，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

#### **2） AOF持久化流程** ####

![b4ebba824fa5473b8fd8a1f238b208eb.png][]

**磁盘文件在虚拟机中：/var/lib/redis/6379/appendonlydir目录下，后缀名为.aof的文件**

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略\[always,everysec,no\]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

#### **3）特点：** ####

1、所有的写操作都会记录到磁盘文件中

2、RDB与AOF可以同时开启，但恢复时只会使用AOF

3、AOF体量无限大，因为AOF只会append不会repace,所以恢复就会很慢

解决AOF体量无限大的问题：

1、hdfs:fsimage+edit.log让日志只记录增量合并的过程

2、4.0前：删除抵消的命令，合并重复的命令，最终是一个命令文件

3、4.0后：将老的数据RDB到AOF文件中，将增量的以指令的形式append到AOF

## 1、AOF
    ############################## APPEND ONLY MODE ###############################
    #是否开启aof   
    #appendonly yes
    appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下， rdb完全够用！ 
    # aof文件名字
    appendfilename "appendonly.aof"
    #写操作会触发IO，可以调整配置文件如下三种策略：下面7、aof同步频率设置详细讲解
    # appendfsync always # 每次修改都会 sync。消耗性能 
    # appendfsync no  # 不执行 sync，这个时候操作系统自己同步数据，速度最快！
    appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！ 
    
    
    no-appendfsync-on-rewrite no
    auto-aof-rewrite-percentage 100 #写入百分比
    auto-aof-rewrite-min-size 64mb#写入的文件最大值是多少，一般在实际工作中我们会将其设置为5gb左右！
    aof-load-truncated yes
    12345678910111213141516

#### **4、 AOF默认不开启** ####

可以在redis.conf中配置文件名称， 默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。/var/lib/redis/6379/appendonlydir

#### **5、 AOF和RDB同时开启，redis听谁的** ####

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

#### **6、 AOF启动修复恢复** ####

我们可以使用redis-check-aof文件来进行修复！这个不能恢复全部数据，有毛病的

redis-check-aof --fix appendonly.aof  #修复appendonly.aof文件

1.AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

**2.正常恢复**

1、只需将备份的aof文件放在我们的redis启动目录即可，Redis启动的时候会自动检查appendonly6379.aof.1.incr.aof文件并恢复其中的数据！

2、查找文件位置的命令：

127.0.0.1:6379> config get dir
    1) "dir"
    2) "/usr/local/bin"  # 如果在这个目录下存在 appendonly6379.aof.1.incr.aof 文件，启动就会自动恢复其中的数据，把要恢复的文件复制到给目录下然后重写启动

修改默认的appendonly no，改为yes

将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

恢复：重启redis然后重新加载

**3.异常恢复**

修改默认的appendonly no，改为yes

如遇到**AOF文件损坏**，通过/usr/local/bin/**redis-check-aof–fix appendonly.aof**进行恢复

备份被写坏的AOF文件

恢复：重启redis，然后重新加载

#### **7、 AOF同步频率设置** ####

**appendfsync always**

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好 *每次修改都会 sync。消耗性能*

**appendfsync everysec**

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

\*每秒执行一次 sync，可能会丢失这1s的数据！ \# appendfsync no

**appendfsync no**

redis不主动进行同步，把同步时机交给操作系统。

不执行 sync，这个时候操作系统自己同步数据，速度最快！\*

#### **8、 Rewrite压缩** ####

**1 压缩是什么：**

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

**2 重写原理，如何实现重写**

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

如果Redis的AOF当前大小>= base\_size +base\_size\*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

#### **9、 优势** ####

备份机制更稳健，丢失数据概率更低。

可读的日志文本，通过操作AOF稳健，可以处理误操作。

1、每一次修改都同步，文件的完整性会更加好！

2、每秒同步一次，最多会丢失一秒的数据！

3、从不同步，效率最高的

#### **10、 劣势** ####

比起RDB占用更多的磁盘空间。

恢复备份速度要慢。

每次读写都同步的话，有一定的性能压力。

存在个别Bug，造成恢复不能。

1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢！

2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化！

#### **11 、总结(Which one)** ####

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

#### 12、测试 ####

①Redis默认使用的是RDB模式，所以需要手动开启AOF模式！ ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyOTQ0Mw_size_16_color_FFFFFF_t_70] 十分简单！将no改为yes即可！

重启服务器！ ![在这里插入图片描述][20210126104004148.png] 发现新文件appendonly.aof！ ![在这里插入图片描述][20210126104025417.png]

②aof文件内容： 先进行一些添加的操作： ![在这里插入图片描述][20210126104237643.png]

然后我们可以vim打开appendonly.aof文件看看里面是什么？

![在这里插入图片描述][20210126104248767.png]

有木有发现，里面存储的就是我们先前操作的命令！

### 2、RDB ###

#### **1) RDB是什么** ####

RDB持久化 按指定的时间间隔 执行数据集的时间点快照。 将rdb文件存储在配置文件中指定的文件目录，若存在直接加载rdb文件中的数据,若不存在则创建一个新的,也是redis配置文件中默认开启的。 rdb是Redis DataBase缩写 RDB功能核心函数rdbSave(生成RDB文件)和rdbLoad(从文件加载内存)

#### **RDB配置** ####

路径：/opt/enviroment/redis-7.0.10/redis.conf

save 900 1
    save 300 10
    save 60 10000
    # save: 设置快照的触发条件，格式为：save <seconds> <changes>
    # 其中seconds表示指定时间间隔内的秒数，changes表示指定修改数量内的次数。
    # 当满足其中一个条件时，Redis 就会进行快照。
    
    
    stop-writes-on-bgsave-error yes # 在RDB执行时如果出现错误，是否停止写入。默认是yes。
    rdbcompression yes   # 是否压缩 RDB 文件。默认是yes。
    rdbchecksum yes  #是否对 RDB 文件进行校验和。默认是yes。
    dbfilename dump_6379.rdb  # 设置 RDB 文件名，默认是dump.rdb。
    dir /var/lib/redis/6379  # 设置 RDB 存储的路径，默认是Redis启动目录（./当前文件夹下的dump.rdb文件），一般需要指定其他路径
    rdb-del-sync-files no
    
    # rdb-del-sync-files是Redis的一个高级配置选项，在默认情况下不开启。
    # 当开启后，Redis在执行RDB持久化期间，将首先创建一个新的RDB文件，如果保存成功，则删除上一个RDB文件，并将新RDB文件重命名为原来的RDB文件名。具体来说，当开启rdb-del-sync-files选项时，Redis会在将新的RDB文件重命名为旧的RDB文件的同时将旧的RDB文件删除，这个动作是同步执行的，因此相当于在RDB文件的写入和删除之间插入了一个同步点。
    # 开启rdb-del-sync-files，可以将RDB生成和删除的CPU负载分散在时间上，从而减少对Redis操作的影响。但是需要注意的是，由于同时进行写入和删除的操作，所以会消耗更多的磁盘IO，因此在I/O繁忙的系统上，这个选项可能会影响Redis的性能表现。
    123456789101112131415161718

#### **2) 备份是如何进行的** ####

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。**RDB缺点是最后一次持久化后的数据可能丢失**

#### **3）fork** ####

1.Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程 2.在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了写时复制 3.一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

#### **4） dump.rdb文件** ####

在redis.conf中配置文件名称，默认为dump.rdb

#### **5） rdb的备份** ####

1、只需将备份的rdb文件放在我们的redis启动目录即可，Redis启动的时候会自动检查dump.rdb文件并恢复其中的数据！ 2、查找文件位置的命令：

127.0.0.1:6379> config get dir
    1) "dir"
    2) "/usr/local/bin"  # 如果在这个目录下存在 dump.rdb 文件，启动就会自动恢复其中的数据，把要恢复的文件复制到给目录下

rdb的恢复

1.  关闭Redis 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
2.  启动Redis, 备份数据会直接加载

#### **6） RDB持久化的优势** ####

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

2.对数据完整性和一致性要求不高更适合使用

3.节省磁盘空间

4.恢复速度快

#### **7） RDB劣势** ####

1.Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

2.虽然Redis在fork时使用了**写时拷贝技术**,但是如果数据庞大时还是比较消耗性能。

3.在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。 4、不支持拉链（只有一个dump.rdb）

################################ SNAPSHOTTING快照  ################################
    # 如果至少有一个键更改，则在900秒(15分钟)后
    save 900 1
    # 如果至少有10个键更改，则在300秒(5分钟)后
    save 300 10
    # 如果至少10000个键更改，则在60秒后
    save 60 10000
    # 持久化文件名
    dbfilename dump.rdb
    # rdb文件保存路径
    dir /data

#### **8）如何停止动态RDB** ####

动态停止RDB：redis-cli config set save “”\#save后给空值，表示禁用保存策略

#### **9) 特点：** ####

1、类似java中序列化，恢复速度很快 2、时点性： 2.1）阻塞式：save命令使用阻塞式，redis不对外提供服务，只持久化 2.2）非阻塞式：bgsave命令使用非阻塞式 采用fork+cow的方式，创建一个子进程，复制一份此刻内存中数据的指针（速度非常快）然后子进程进行持久化，主进程依然对外提供服务，再发生数据的修改是创建心得指针将原来得换掉而不影响子进程数指针。

#### 10、总结： ####

Redis会单独创建（fork）一个**子进程**来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是**不进行任何IO操作**的。 这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置！

**在生产环境我们会将这个文件进行备份！**

#### 11、测试 ####

①首先我们进入服务器找到[dump][].rdb文件： /opt/enviroment/redis-7.0.10

可以在 /opt/enviroment/redis-7.0.10/redis.conf中设置dir路径，可以看上面第1条rdb配置，我没有配置默认是当前文件下就是

/opt/enviroment/redis-7.0.10

![在这里插入图片描述][20210126100842863.png] ②测试触发rdb操作：[vim][]打开redis.conf配置文件 /opt/enviroment/redis-7.0.10/redis.conf ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyOTQ0Mw_size_16_color_FFFFFF_t_70 1] 为了方便测试，我们将其改为 ：

save 60 5  #意思是在60秒内进行了5次操作，即写入rdb文件中进行持久化保存

如下图所示：

![在这里插入图片描述][20210126101402476.png]

③触发机制： 1、save的规则满足的情况下，会自动触发rdb规则,测试如下： 先手动删除dump.rdb文件，实验触发规则！ ![在这里插入图片描述][20210126101910784.png] 在Redis中操作5次命令！ ![在这里插入图片描述][2021012610201838.png]

查看是否生成dump.rdb文件! ![在这里插入图片描述][20210126102109611.png] 成功！

2、执行flushall命令，也会触发rdb规则 再次删除dump.rdb文件！ ![在这里插入图片描述][20210126102154282.png] 执行flushall操作命令！

![在这里插入图片描述][20210126102240697.png]

正常生成成功！ ![在这里插入图片描述][20210126102228945.png]

3、退出Redis，也会触发rdb规则

删除： ![在这里插入图片描述][20210126102322872.png] 退出：

![在这里插入图片描述][20210126102413886.png]

生成成功！ ![在这里插入图片描述][20210126102401338.png]

### **3、RDB和AOF总结**： ###

**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文件，载入较新的那个，微博就是这种架构。

### **4、RDB和AOF的区别** ###

1.  保存机制不同:
    
    \-RDB 是通过快照的方式保存数据,它会定期将内存中的数据集写入磁盘,保存文件的格式是紧凑的。 - AOF 是通过写入文件的方式保存数据,它会记录服务器执行的所有写命令,并在服务器启动时,通过重新执行这些命令来还原数据集
2.  恢复速度不同:
    
    \-RDB 文件恢复速度快,启动只需要载入 RDB 文件即可。 - AOF 文件需要重新执行文件中的所有写命令来恢复数据,速度较慢。
3.  数据安全性不同:
    
    \-RDB 数据容易丢失,每次保存之间的数据都可能丢失。 - AOF 数据较为安全,因为每执行一个写命令就会记录, practicall 可以避免数据丢失。
4.  磁盘占用不同:
    
    \-RDB 文件通常要小于 AOF 文件,因为 RDB 只保存数据集的快照。 - AOF 保存的都是写命令,文件会越来越大。
5.  性能不同:
    
    \-RDB 的性能较好,因为不需要频繁的磁盘 I/O 操作。 - AOF 的性能较差,每次写操作都需要记录日志,频繁的磁盘写操作会影响性能。
6.  总之,RDB 适合做数据备份,AOF 适合数据的持久化保存。一般来说,生产环境会同时开启这两种持久化方式,并通过 appendonly no 配置项控制 AOF 文件大小,既可以享受 AOF 带来的数据安全性,又可以控制磁盘空间占用。

[Link 1]: https://so.csdn.net/so/search?q=%E5%86%85%E5%AD%98&spm=1001.2101.3001.7020
[b4ebba824fa5473b8fd8a1f238b208eb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f1873b777c9c427e91059c196c67b0e6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyOTQ0Mw_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f50917274ef545c596f82823e167f33d.png
[20210126104004148.png]: https://img-blog.csdnimg.cn/20210126104004148.png
[20210126104025417.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/80b1cc32786a4a29a7aba554e85e9cd1.png
[20210126104237643.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d84427ae9b2c426fa41b736a95aa15c8.png
[20210126104248767.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/2013ae7f73864b68958bae1ec47e7a11.png
[dump]: https://so.csdn.net/so/search?q=dump&spm=1001.2101.3001.7020
[20210126100842863.png]: https://img-blog.csdnimg.cn/20210126100842863.png
[vim]: https://so.csdn.net/so/search?q=vim&spm=1001.2101.3001.7020
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyOTQ0Mw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20210126101300315.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgyOTQ0Mw==,size_16,color_FFFFFF,t_70
[20210126101402476.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/13443586d7fb464fa2693ce1ce35778e.png
[20210126101910784.png]: https://img-blog.csdnimg.cn/20210126101910784.png
[2021012610201838.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/e35506eea94348ad9a66098272af0a0c.png
[20210126102109611.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f11146bb023d4f118b22663dd486127b.png
[20210126102154282.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/1c8acd0a103f4b11b5594bf0988f4ba2.png
[20210126102240697.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/ffc6bdb316634fdd8666a93457f099fc.png
[20210126102228945.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/212df1acf81a4c81ba088d7f054443ba.png
[20210126102322872.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/9e0ded3f6a914dad934959d42d0512a9.png
[20210126102413886.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/98e239fb0d4a421887aeed2062a1fe6d.png
[20210126102401338.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/12ad5c411400408e963e242e7f26f703.png