Redis持久化策略RDB和AOF

Kris_zwl

已于 2024-06-09 19:58:36 修改

阅读量836

点赞数 13

分类专栏：数据库文章标签： redis 数据库

于 2024-06-09 15:42:45 首次发布

本文链接：https://blog.csdn.net/Kris_zwl/article/details/139562039

版权

数据库专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Redis 提供了两种不同的持久化方式：RDB（Redis DataBase）和AOF（Append Only File）。

RDB：

描述：

RDB文件是一个经过压缩的二进制文件，它将Redis在内存中的数据写入到硬盘中，生成一个快照文件。这个快照文件包含了Redis在某个时间点内的所有数据。

执行流程：

触发RDB生成：RDB持久化可以通过手动或自动两种方式触发。

手动触发：通过执行save或bgsave命令。
- save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。
- bgsave命令会fork一个子进程（注意是子进程，不是子线程）在后台生成快照文件，不会阻塞Redis服务器，服务器进程（父进程）可以继续处理命令请求。
自动触发：自动方式则是在配置文件中设置，满足条件时自动触发。例如，我们可以在Redis的配置文件中设置以下条件：
```
save 900 1
save 300 10
save 60 10000
```
这意味着，如果在900秒内有1个键被修改，或者在300秒内有10个键被修改，或者在60秒内有10000个键被修改，那么Redis就会自动触发bgsave命令

创建子进程：当执行bgsave命令时，Redis主进程（父进程）会执行fork操作来创建一个子进程。这是一个昂贵的操作，尤其当数据集很大时。但好处是，一旦fork完成，父进程可以立即返回处理其他客户端请求，而不需要等待RDB的生成过程。
子进程生成RDB文件：子进程将开始遍历整个数据集，将所有的数据写入一个新的临时RDB文件。这是一个纯I/O操作，并且是线性的，所以非常快。子进程不需要处理任何客户端请求，只专注于写RDB文件，所以效率很高。
RDB文件替换：一旦子进程完成了新的RDB文件的写入，它会替换掉旧的RDB文件，并发送一个信号通知父进程任务完成。然后子进程退出。
完成持久化：当替换完成后，Redis完成了一次RDB持久化。这个过程是非常快速的，因为Redis只需将内存中的数据写入硬盘。

优点：

1. 高效的数据备份和恢复：
RDB是一个紧凑压缩的二进制文件，代表数据在某一个时间点的快照。非常适合备份，全景复制。
2. 快速的数据恢复：
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
3. 最大化性能：
对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作123。

缺点：

1.数据可能会丢失：
如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当Redis故障时，仍然会有近5分钟的数据丢失123。
2.可能会导致服务暂停：
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF：

描述：

AOF则是以追加的方式记录Redis执行的每一条写命令。当Redis重启的时候会优先载入AOF文件来恢复原始的数据。

执行流程

开启AOF：Redis中默认不开启AOF，可以通过在配置文件中设置appendonly yes来开启。
命令写入：所有写入命令会追加到AOF缓冲区（aof_buf）中。
文件同步：AOF缓冲区，根据策略向硬盘做同步。这是由参数appendfsync控制，常规使用everysec选项：
- always：每次有数据修改发生时都会写入磁盘，保证了最高的数据安全性，但效率较低。命令写入aof_buf后，直接调用系统的fsync操作同步到AOF文件。
- everysec：每秒同步一次，兼顾了数据安全性和效率。命令写入aof_buf后，调用系统的write操作，write操作完成后线程返回。fsync同步文件操作由专门线程每秒调用一次。
- no：完全依赖操作系统，数据同步的频率和时间由操作系统来决定。命令写入aof_buf后调用系统的write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。
文件重写：随着AOF文件越来越大，需要定期对AOF文件进行重写，只保留恢复当前数据集所需的最小命令集，达到压缩的目的。把Redis进程内的数据转化为写命令同步到新AOF文件的过程。AOF重写过程分为手动触发和自动触发：
- 手动触发：直接调用bgrewriteaof。
- 自动触发：根据auto-aof-rewrite-min-size（默认64M）和auto-aof-rewrite-percentage参数确定自动触发时机。
重启加载：当Redis服务器重启时，可以加载AOF文件进行数据恢复。

优点：

1. 数据安全性高：
AOF可以提供更高的数据安全性。Redis提供了三种同步策略，即每秒同步、每修改同步和不同步。一般来说，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。
2. 日志清晰：
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。
3. 自动重写：
如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。

缺点：

1. 文件体积大：
对于同一份数据来说，AOF文件通常要大于RDB文件的体积。
2. 恢复速度慢：
对于相同数据量大小的恢复数据操作，建议使用RDB恢复，因相同数据大小情况下，RDB恢复速度比AOF恢复更快。
3. 运行效率可能较低：
根据所使用的fsync策略，AOF在运行效率上往往会慢于RDB。