redis的持久化缓存机制（复习专用）_redis加载缓存长保存-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_45455503/article/details/123885711

本文深入探讨Redis的持久化机制，包括RDB（快照）和AOF（日志）两种方式。RDB提供数据集的快照，适合大规模数据恢复，但可能丢失最近修改；AOF记录写操作日志，数据丢失少但体积大，恢复速度慢。文章还讨论了AOF重写机制和混合持久化策略，并给出了相关配置选项及触发条件。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

你对redis持久化的理解？

（为什么要对于redis进行持久化？）
redis对于数据的操作是基于内存的，如果出现进程退出或者服务器宕机的情况，redis中的数据会丢失不可恢复，为了不会造成数据的丢失，所以需要对于redis中的数据进行持久化存储。
对于redis持久化的方式有三种：
RDB（全称：Redis Data Base）（默认开启）
AOF (全称：Append Only File ) （默认不开启）
RDB和AOF混合持久化方式（redis4.0以后）

RDB方式：持久化内存数据

快照的方式
(默认的持久化机制)

什么是RDB？

在指定的时间间隔内将内存中的数据集的快照写入磁盘

底层原理：

Redis会单独创建（Fork）一个子进程来进行持久化，先会将数据写入到一个临时文件中，待持久化过程结束后，再用这个临时文件去；替换上次持久化好的dump.rdb文件，这样的话，会保证数据的完整性
缺点：最后一次的持久化数据可能会丢失。

触发机制

触发机制分为手动触发和自动触发
手动触发是通过sava（不推荐，阻塞）和bgsave（推荐，异步）命令进行触发
自动触发是通过shutdown进行自动触发，然后通过bgsave方式进行持久化

如何恢复

redis重启的话，会自动通过读取dump.rdb文件进行恢复数据

优点

适合大规模的数据修复
对于数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快

缺点

Fork 的时候，内存中的数据被克隆了一份，大致2倍的膨胀性要考虑
虽然 Redis 在fok 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修堂

配置文件（陌生点）：

1、当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.

stop-writes-on-bgsave-eror:yes

2、对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis,会采用LZF算法进行压缩。如果你不想消耗CPU来进行压宿的话，可以设置为关闭此功能。推荐yes.

rdbcompression yes

3、rdbchecksum检查完整性，
在存储快照后，还可以让redis,使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
推荐yes.(因为如果数据不完整，则持久化也没必要)

rdbchecksum yes

4、自动配置

save 900 1 # 表示900 秒内如果至少有 1 个 key 的值变化，则触发RDB
save 300 10 # 表示300 秒内如果至少有 10 个 key 的值变化，则触发RDB
save 60 10000 # 表示60 秒内如果至少有 10000 个 key 的值变化，则触发RDB

AOF方式：持久化操作命令

以日志的形式来记录写操作的方式

开启aof持久化机制：（默认不开启）

在配置文件redis.conf中添加以下的命令：

appendonly yes

异常恢复

异常恢复：（aof文件损坏时，通过redis-check-aof进行修复）
修改默认的appendonly no改为yes
如遇到AOF文件损坏，通过

/usr/local/bin/redis-check-aof --fix appendonly.aof

进行修复。
备份被写坏的AOF文件。
恢复：重启redis,然后重新加载

aof持久化流程（底层原理）

(1)客户端的请求写命令会被append追加到AOF缓冲区内;
( 2 )AOF缓冲区根据AOF持久化策略[always,eveilysec,no]将操作sync（同步）到磁盘的AOF文件中;
( 3 )AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量;

优点

备份机制更稳健，丢失数据概率更低
可读的日志文件，通过操作AOF稳健，可以处理误操作

缺点

比起RDB占用更多的磁盘空间（不仅包括数据，还有操作，所以空间多）
恢复备份速度要慢
每次读写都同步的话，有一定的性能压力
存在个别bug，造成恢复不能。

aof重写机制

调用方式：1）手动通过命令调用 2）自动调用（文件大小达到一定条件）
手动调用：通过命令bgrewriteaof进行手动调用进行重写

重写流程

( 1 ) bgrewriteaof触发重写，判断是否当前有bgsave 或 bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。。
( 2 )主进程fork出子进程执行重写操作，保证主进程不会阻塞。
( 3 )子进程遍历redis 内存中数据到临时文件，客户端的写请求同时写入aof_buf 级冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整l以及新AOF文件生成期间的新的数据修改动作不会丢失。·
(4 ) 1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2)主进程把aof_rewrite_buf中的数据写入到新的AOF 文件。·
(5]使用新的AOF文件覆盖|旧的AOF 文件，完成AOF重写。

重写原理：（ redis4.0版本后出现的重写）

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename) ,是指上就是把rdb 的快照，以二级制的形式附在新的 aof 头部.作为已有的历史数据，替换掉原来的流水账操作。

触发机制

当AOF文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
1）当AOF文件大小的增长率大于该配置项时自动开启重写(这里指超过原大小的100%)。
auto-aof-rewrite-percentage 100
（相关理解：假设原来大小为20，如果为100的话，当aof文件大小达到40，则会自动触发aof机制；如果为80的话，当aof文件大小达到20x(1+0.8)=36时，会自动触发aof机制。）
2）当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb
（相关理解：当文件大小为64m时，会自动触发aof机制）

redis4.0后的混合持久化机制

(aof和rdb方式混合使用，主要是采用rbd方式将内存的数据进行全量存储，又为了防止数据，所以采用aof方式将操作的命令进行存储)

问题

1、rdb文件会在哪里生成？

redis客户端在哪里进行启动，就会在哪里进行生成

2、什么时候会生成aof文件

启动redis客户端时就会生成一个aof文件，在哪启动在哪生成

3、什么时候会进行fork一个进程或者什么时候会触发rdb持久化机制

1）shutdown时，如果没有开启aof，会触发配置文件中默认的快照配置
2）执行命令save或者bgsave save是只管保存，其他不管，（在主线程执行）其他操作全部阻塞；bgsave: redis会在后台异步进行快照操作，同时可以响应客户端的请求
3）执行flushall命令（清空数据库中所有数据）但是里面是空的，无意义

4、aof的同步频率设置

在配置文件（redis.conf）中进行配置项

no：（被动的）表示等操作系统进行数据缓存同步到磁盘(快，持久化没保证)
（这个是程序员不可控的，一般不推荐）

always：（始终）同步持久化，每次发生数据变更时，立即记录到磁盘（慢，安全)（性能较差但是数据完整性比较好）
（每次变更就记录，比较消耗性能（因为有时候一次变更的数据多的话，速度就很慢））

everysec:表示每秒同步一次（默认值,很快，（如果宕机）但可能会丢失一秒以内的数据)
（推荐）

5、什么时候会自动触发aof重写机制

aof和rdb同时开启，redist听谁的？

（假设开始的时候rdb开启时会持久化数据，redis开启后会读取dump.rdb文件的数据，但是aof开启后，系统会默认会读取aof文件的数据，然后redis的数据就会为空（aof刚开启，没有读取数据情况下）。）
解答：aof和rdb同时开启，系统会默认读取aof的数据（数据不会存在丢失）
原因：因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整