RDB持久化
RDB是Redis的一种快照持久化方式,它将内存中的数据集都写入磁盘,生成一个RDB文件,RDB文件是一个经过压缩的二进制文件(通常叫做数据快照),可以用于备份、迁移和恢复数据。
RDB的优点是快速、紧凑,适合备份和恢复大量数据,但是它的缺点是数据可能会丢失,因为RDB文件只保存了最后一次快照的数据
执行时机
RDB持久化在以下四种情况下会执行:
1. 执行save命令(Redis持久化命令):
当执行save命令时,Redis会阻塞所有客户端请求,将内存中的数据集快照写入磁盘,生成一个RDB文件。这个过程会阻塞Redis的正常运行(无法响应客户端请求,造成服务中断),保存完成后,Redis会解除阻塞,继续处理客户端请求。
2. 执行bgsave命令(后台持久化命令):
bgsave命令的执行过程中,Redis会先创建一个子进程,然后父进程继续处理客户端请求,而子进程负责将数据集保存到磁盘。这种方式可以保证Redis的正常响应,不会中断服务。 由于bgsave命令是在后台执行的,所以在执行期间无法立即得知保存的进度和结果,可以通过lastsave命令或者检测RDB文件判断保存情况。
3. Redis停机
当Redis服务停机时,无论是正常关闭还是异常退出,都会触发RDB持久化,Redis会执行一次save命令,将数据集快照写入磁盘。
4. 触发RDB条件
用户可以通过设置配置文件(redis.conf)中的save命令来指定触发RDB持久化的条件,
例如:设定在900秒内至少有1个键被修改,就执行一次bgsave命令(如果是save "" 则表示禁用RDB)
# redis.conf文件
save 900 1
执行原理
bgsave开始时会fork主进程得到子进程(和主进程相同),子进程共享主进程的内存数据,负责将内存中的数据集写入磁盘。
fork命令使用了写时复制(Copy-on-Write)的技术:在主进程执行写操作时,才会真正复制父进程的内存页,而在此之前,子进程与父进程共享相同的内存页,这样可以减少内存的复制开销,提高性能。
AOF持久化
在Redis每次写入操作执行完成后,将该操作以文本的形式追加到AOF文件的末尾,AOF文件是一个文本文件,记录了所有写入操作的历史(也就是记录写操作的命令),可以用于数据恢复。
AOF的执行时机是由Redis自动触发的,由刷盘策略决定。
开启AOF方式方法,修改配置文件redis.conf(不需要关闭RDB,二者可以同时使用)
# redis.conf文件
# 是否开启AOF功能,默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
AOF 3种刷盘策略
刷盘策略 | 刷盘时机 | 优点 | 缺点 |
always | 每次写入操作 | 数据安全性最高,几乎不会丢数据 | 性能开销较大 |
everysec | 每秒刷盘 | 数据安全较高,性能相对较好 | 性能适中 |
no | 操作系统决定刷盘时机 | 性能开销最小 | 数据安全性较低 |
文件配置
# redis.conf文件(三个选一个)
appendfsync always
# appendfsync everysec
# appendfsync no
二者对比
- RDB是快照形式的持久化方式,将数据集的快照以二进制形式保存在磁盘上,而AOF是将写入操作以追加的方式记录到文件中。
- RDB持久化生成的文件较小,加载速度较快。AOF持久化生成的文件较大,加载速度较慢,但可以提供更好的数据安全性。
- RDB持久化可以定期或手动触发,而AOF持久化可以根据不同的刷盘策略进行配置
- RDB持久化对Redis的读取性能没有影响,因为数据是从磁盘加载到内存中,而AOF持久化在写入性能上可能会有一定影响,因为每次写入操作都需要追加到文件中。
- RDB持久化在故障恢复时速度较快,因为只需加载最近的RDB文件即可,而AOF持久化在故障恢复时可能需要较长时间,因为需要重新执行AOF文件中的所有写入操作。
总结:RDB适合备份和恢复大量数据,加载速度快;AOF提供更好的数据安全性,但文件较大且加载速度较慢。