【redis持久化】 Redis的两种持久化方式：RDB和AOF

嘚嘚嘚嘚嘚嘚哒

已于 2023-10-06 16:43:32 修改

阅读量161

点赞数 3

于 2023-09-26 17:58:46 首次发布

本文链接：https://blog.csdn.net/qq_47450919/article/details/133207975

版权

数据库专栏收录该内容

7 篇文章 0 订阅

订阅专栏

为什么要持久化

Redis是内存数据库，宕机后数据会消失，Redis重启后快速恢复数据，所以Redis为我们提供了持久化机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

Redis的两种持久化方式：RDB和AOF

Redis持久化不保证数据的完整性，有可能会丢数据。当Redis用作DB时，DB数据要完整，所以一定要有一个完整的数据源（文件、mysql），在系统启动时，从这个完整的数据源中将数据load到Redis中。

AOF：将每一个收到的写命令都通过write函数追加到文件中

RDB(Redis DataBase)

在指定的时间间隔内将内存中的数据集快照写入磁盘，即 Snapshot 快照，恢复时是将快照文件直接读到内存里。
在这里插入图片描述

RDB（Redis DataBase），是redis默认的存储方式，RDB方式是通过快照（ snapshotting ）完成的。它保存的是某一时刻的数据并不关注过程。RDB保存redis某一时刻的数据的快照

触发快照的方式

符合自定义配置的快照规则；
执行save或者bgsave命令；
执行flushall命令；
执行主从复制操作 (第一次)。

RDB持久化触发策略

RDB 持久化提供了两种触发策略：一种是手动触发，另一种是自动触发。

自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中
在这里插入图片描述

上图所示， save m n 的含义是在时间 m 秒内，如果 Redis 数据至少发生了 n 次变化，那么就自动执行BGSAVE命令。配置策略说明如下：
save 900 1 表示在 900 秒内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
save 300 10 表示在 300 秒内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
save 60 10000 表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。

只要上述三个条件任意满足一个，服务器就会自动执行BGSAVE命令。当然也可以根据实际情况自己调整触发策略。

注意：每次创建 RDB 文件之后，Redis
服务器为实现自动持久化而设置的时间计数和次数计数就会被清零，并重新开始计数，因此多个策略的效果不会叠加。

此处redis自动触发策略参考文章Redis RDB持久化详解（原理+配置策略）

配置参数定期执行
在redis.conf中配置：save 多少秒内数据变了多少，可以配置多个条件，漏斗设计满足其中一个条件就会触发生成快照，提搞性能

Redis 会单独创建一个子进程（fork）来进行持久化。

先将数据写入到一个临时文件中，待持久化过程完成后，再将这个临时文件内容覆盖到 dump.rdb。

整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。

RDB 的缺点是最后一次持久化后的数据可能丢失。

注意: redis中的数据有个很重要的注意事项, 就是必须要考虑, 如果redis里面的数据完全丢失了, 程序的行为还能正常与否, 也就是确保redis数据丢失后还能再恢复过来, 此时我们才可以考虑将数据存储到redis中。

Fork

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

配置

dump 文件名字

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

在这里插入图片描述

dump 保存位置

rdb 文件的保存路径可以修改。默认为 Redis /var/lib/redis/

在这里插入图片描述

stop-writes-on-bgsave-error

即当 redis 无法写入磁盘，关闭 redis 的写入操作。

在这里插入图片描述

rdbcompression

持久化的文件是否进行压缩存储。

在这里插入图片描述

rdbchecksum

完整性的检查，即数据是否完整性、准确性。

> !https://selton-1257770752.cos.ap-beijing.myqcloud.com/img/202304030007505.png

优点

适合大规模的数据恢复；
对数据完整性和一致性要求不高更适合使用；
性能好：RDB方式在数据持久化时，将内存中的数据以快照的形式保存到磁盘，写操作不会对磁盘进行频繁的写入，因此性能较高。
数据文件紧凑，节省磁盘空间：RDB文件是二进制文件，非常紧凑，适用于备份和迁移数据。
恢复速度快。

缺点

Fork 的时候，内存中的数据被克隆了一份，极端情况下大致 2 倍的膨胀性需要考虑；
虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；
在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。
不适用于高可用性：由于数据不是实时保存到磁盘，所以不适用于要求高可用性和数据实时性的场景。
父进程在fork子进程的时候如果主进程比较大会阻塞；

AOF(Append Only File)

AOF（append only file）是Redis的另一种持久化方式。以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis 启动之初会读取该文件重新构建数据，换言之，如果 Redis 重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF会记录过程，RDB只管结果

执行流程

客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；
AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 Rewrite 重写，压缩 AOF 文件容量；
Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

AOF 和 RDB 同时开启时，系统默认读取 AOF 的数据（数据丢失可能性非常之低）

AOF 保存模式:

AOF_FSYNC_NO ：不保存。
在这种模式下，每次调用 flushAppendOnlyFile 函数， WRITE 都会被执行，但 SAVE 会被略过。当出现Redis 被关闭、AOF 功能被关闭、系统的写缓存被刷新（可能是缓存已经被写满，或者定期保存操作被执行）中任意一种情况都会触发save执行，并且会Redis 主进程阻塞。
AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。（默认）
在这种模式中， SAVE 原则上每隔一秒钟就会执行一次，因为 SAVE 操作是由后台子线程（fork）调用的，所以它不会引起服务器主进程阻塞。
AOF_FSYNC_ALWAYS ：每执行一个命令保存一次。（不推荐）
在这种模式下，每次执行完一个命令之后， WRITE 和 SAVE 都会被执行。

在这里插入图片描述

配置

AOF 默认不开启

> !https://selton-1257770752.cos.ap-beijing.myqcloud.com/img/202304030007979.png

文件名字

> !https://selton-1257770752.cos.ap-beijing.myqcloud.com/img/202304030007114.png

AOF 同步频率设置

> !https://selton-1257770752.cos.ap-beijing.myqcloud.com/img/202304030008359.png

appendfsync always

始终同步，每次 Redis 的写入都会立刻记入日志；

性能较差但数据完整性比较好。

appendfsync everysec

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

appendfsync no

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