Redis 的持久化

最新推荐文章于 2024-01-05 11:02:23 发布

Ai_Ying_Java

最新推荐文章于 2024-01-05 11:02:23 发布

阅读量214

点赞数

本文链接：https://blog.csdn.net/Ai_Ting_Java/article/details/104702791

版权

Redis提供了两种不同的持久化方式，分别为 RDB(Redis DataBase) 和 AOF(Append of file)。

RDB存储的是数据，而AOF存储的是指令。

一、RDB方式

1.简介：

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。(使用快照恢复数据是非常迅速的，快照上保存的就是当前的所有数据)

2.备份是如何执行的

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

3.关于fork

在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，linux中引入了"写时复制技术"(写时复制技术即：只有当子进程需要工作的时候才会从父进程中复制，不需要工作时是不影响父进程的，不会占用内存)，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

4.RDB保存文件的路径

首先需要在redis.conf中配置文件名称，默认为dump.rdb。

dump.rdb文件的保持路径默认为Redis启动时命令行所在的目录下（如下图所示），但一般都会进行修改为指定的目录下，便于查找。修改也是在redis.conf文件中进行修改。

5.RDB的保存策略

Redis默认提供了三种保存策略，如下图所示（redis.conf文件中）

其中的900，300，60表示时间，单位秒，而1，10，10000表示次数。以save 900 1 为例，意思是在900秒内若数据更新了1次则进行持久化保存操作。save 300 10 表示在300秒内若redis数据库发生了10次变化久进行持久化操作。

6.触发RDB持久化保存的条件

满足我们设置保存的一种或多种保存策略(eg:save 900 1)，
以正常关闭的形式退出redis，例如使用 shutdown 命令。
手动使用持久化保存命令：save vs bgsave。（不建议使用此种方式，因为此种方式是绝对阻塞的，即此时整个redis只能用于持久化保存数据，但能进行读写操作）

鉴于以上的的触发条件，所以当redis非正常关闭时且又不满足持久化策略时我们在此段时间做的数据操作将不会被持久化，则有可能就会造成数据丢失。

7.RDB的其他配置

当Redis无法写入磁盘的话，直接关掉Redis写的操作。将stop-writes-onbgsave-error 改为 yes

stop-writes-onbgsave-error  yes

经RDB持久化保存时，将持久化文件进行压缩。rdbcompression 改为 yes。强烈建议要修改此配置文件。

rdbcompression  yes

在存储快照后，还可以让Redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗。如果希望性能获得最大的提升，建议关闭该功能。

rdbchecksum  yes

8.RDB的备份和恢复

备份：首先通过 config get dir 指令查出rdb文件的目录，在将持久化文价拷贝出来放在你想放在的任何地方进行备份，还可以重命名加以区分不同时期的持久化问价。

恢复：首先关闭redis，再将备份的文件拷贝到工作目录下，启动redis，备份数据会直接加载。

9.RDB的优点与缺点

优点：节省磁盘空间(相对于AOF而言)；恢复速度块。

缺点：

虽然redis在fork时采用的是写时拷贝技术，但数据如果庞大还是比较会消耗性能。
当redis非正常关闭时，很有可能会丢失最后一次操作的数据。

二、AOF方式

1.简介：

以日志的形式来记录每个写操作，将Redis执行过的所有写指令全部记录下来，读操作不做记录。只许追加文件但不许更改文件内容。Redis启动之初会读取该文件重新构建数据。也就是说，Redis重启的话就根据日志文件的内容将记录的写指令从头至尾执行一遍来完成数据的恢复。因此当数据足够大的时候，恢复数据的工作是很慢的。

2.AOF的配置

AOF默认不开启，需要手动在配置文件中手动更改配置。如下图所示，需要将 appendonly no 手动更改为yes。

AOF保存的文件名称默认为 appendonly.aof ；如下图所示

AOF默认的保存路径与RDB是一致的，即RDB保存在哪里，AOF就保存在哪里，即便更改了保存路径，他两的保存位置依然会是一致的。

注意：AOF与RDB同时开启，Redis默认以AOF为准。

3.AOF的备份与恢复

AOF文件故障备份：

AOF的备份机制和性能虽然与RDB不同，但备份和恢复的操作与RDB是一样的，都是拷贝备份文件到另一个目录中进行备份，需要恢复时再将拷贝出去的文件再拷贝回Redis工作目录下，启动系统即加载。

AOF文件故障恢复：

AOF文件的保存路径与RDB是一致的，若AOF文件损坏，可通过以下命令尝试进行恢复。（在实际工作中这个命令其实没什么卵用）例如：flushdb，清空当前库的指令也是属于写操作的。

redis-check-aof --fix appendonly.aof

4.AOF的同步频率设置

AOF的同步频率设置有一下三种方式：

始终同步，每一次进行redis的写操作时都会立刻记录到日志文件中(appendonly.aof ) -- 对性能的消耗较大
每秒同步，每秒记录日志一次，如果宕机，本秒的数据可能丢失。-- 若最后一秒进行写入的数据较大，如果丢失了，损失也大
把不主动进行同步，把同步时机交给操作系统。

5.AOF的Rewrite操作 -- 重写操作（此项操作十分有用）

AOF采用文件追加方式来记录的写入操作指令，日积月累下，记录的文件会越来越大。为了避免出现此种情况，新增了重写机制，当AOF文件的大小超过某个所设定的阈值的时候，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用以下命令：bgrewriteaof。

所谓最小可恢复的指令集，举个例子，若我们同时对某个key进行了数次以上的操作

set a 1
set a 2
set a 123

那么最小指令值即只保存 set a 123这一次的操作，因为前两次操作的值已经被第三次操作的值所覆盖了。

而AOF之所以采用重写形式对文件内容进行压缩，而不像RDB那样对数据进行压缩，正是因为AOF保存的是指令，而RDB保存的是数据，数据的大小可以进行压缩，而指令却不能进行压缩，压缩后的指令难以识别，很有可能出错，因为只能对AOF的文件内容进行删减来压缩文件的大小。

6.AOF如何实现重写的

AOF文件会因为写入操作的增加而持续增长，逐渐变得所占内存过大，此时，redis会fork出一条新进程来将文件重写，也是先记录在一个临时文件中，然后通过rename操作覆原文件。但需要注意的是，在此项重写操作中，并不是去读取旧的aof文件，而是将整个内存中的Redis数据库的数据用命令的方式重写了一份aof文件用来覆盖旧的，这点和快照类似。

7.AOF何时进行重写

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