【Redis】009-Redis持久化：RDB操作、AOF操作

目录

​​一、RDB操作​​

​​1、概述​​

​​2、什么是RDB（Redis Database）​​

​​3、测试RDB​​

​​第一步：修改配置文件，每60秒修改5次就进行持久化操作​​

​​第二步：删除原始的dump.rdb文件​​

​​第三步：启动Redis服务器和客户端，并修改五次数据​​

​​第四步：退出客户端、服务器，并查看​​

​​第五步：重新启动Redis服务器和客户端，进行数据获取​​

​​第六步：使用flushdb（或者flushall）快速产生rdb文件​​

​​4、RDB规则触发机制​​

​​5、如何恢复RDB文件​​

​​6、RDB优缺点​​

​​优点：​​

​​缺点：​​

​​二、AOF操作​​

​​1、概述​​

​​2、什么是AOF​​

​​3、AOF配置​​

​​默认不开启：​​

​​生成文件的名字：​​

​​策略配置：​​

​​重写规则：​​

​​4、测试AOF​​

​​第一步：将appendonly no改为yes​​

​​第二步：启动Redis服务器和客户端，并存一些数据进去​​

​​第三步：关闭客户端和服务器​​

​​第四步：重启服务器和客户端​​

​​第五步：恢复数据​​

​​5、AOF的优缺点​​

​​优点：​​

​​缺点：​​

​​6、Rewrite​​

​​是什么：​​

​​重写原理：​​

​​触发机制：​​

​​三、RDB和AOF的选择​​

​​1、比较​​

​​2、如何选择​​

一、RDB操作

1、概述

Redis是内存数据库，如果不将内存数据库中的数据库保存到磁盘，那么服务器一关机数据就会消失，所以Redis提供了持久化的功能；

2、什么是RDB（Redis Database）

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

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

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

rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的！

3、测试RDB

第一步：修改配置文件，每60秒修改5次就进行持久化操作

第二步：删除原始的dump.rdb文件

第三步：启动Redis服务器和客户端，并修改五次数据

第四步：退出客户端、服务器，并查看

第五步：重新启动Redis服务器和客户端，进行数据获取

第六步：使用flushdb（或者flushall）快速产生rdb文件

4、RDB规则触发机制

①save的规则满足的情况下，会自动触发rdb规则；

②执行 flushall 命令，也会触发我们的rdb规则；

③退出redis，也会产生 rdb 文件；

5、如何恢复RDB文件

①只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb 恢复其中的数据；

②查看需要存在的位置：

127.0.0.1:6379> config get dir
1) "dir"
2) "D:\\MySoft\\Redis-x64-3.2.100" # redis启动的时候会自动检查dump.rdb 恢复其中的数据

几乎就它自己默认的配置就够用了，但是我们还是需要去学习！

6、RDB优缺点

优点：

适合大规模的数据恢复；

对数据的完整性要求不高；

缺点：

需要一定的时间间隔，进行操作（可在配置文件自定义规则）；

fork进程的时候会占用一定的内存空间；

二、AOF操作

1、概述

AOF，Append Only File，将所有命令都记录下来，相当于一个history，恢复的时候将这个文件内保存的命令全部执行一遍；

2、什么是AOF

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

Aof保存的是 appendonly.aof 文件；

3、AOF配置

默认不开启：

生成文件的名字：

策略配置：

重写规则：

其他省略，一般情况下将appendonly no改为yes，其他保持默认就可以了！

4、测试AOF

第一步：将appendonly no改为yes

如果未能生成aof文件，可以在客户端进行操作：

（我的学习环境的Windows，狂神的教学环境是Linux）

config set appendonly yes

第二步：启动Redis服务器和客户端，并存一些数据进去

第三步：关闭客户端和服务器

第四步：重启服务器和客户端

第五步：恢复数据

尴尬了！无法执行！不知道为什么Windows上的exe程序无法直接运行，在Linux上直接运行下面的命令即可：

redis-check-aof --fix appendonly.aof

5、AOF的优缺点

优点：

每一次修改都同步，文件的完整会更加好；

每秒同步一次，可能会丢失一秒的数据；

从不同步，效率最高的；

缺点：

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

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

6、Rewrite

是什么：

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

重写原理：

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似；

触发机制：

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发；

三、RDB和AOF的选择

1、比较

绝大多数情况下使用RDB即可！

在主从复制中，RDB就是备用的，备份在从机上面，AOF不使用。。。哈哈哈！

2、如何选择

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。