看完你才知道什么是Redis的持久化机制

关注

原创最新推荐文章于 2026-01-26 18:46:50 发布 158 阅读 AI 写同款· GEO 优化 ›

Redis持久化机制 Redis持久化是一种重要的机制，用于将内存中的数据保存到磁盘上，以防止数据在服务器宕机或重启时丢失。Redis提供了两种主要的持久化方法：RDB（Redis DataBase）和AOF（Append Only File）。下面我将详细介绍这两种方法。RDB持久化会在指定的时间间隔内创建数据集的快照，并将其保存为一个单一的压缩文件。这个过程可以通过配置文件中的save指令来自动触发，也可以通过执行SAVE或BGSAVE命令来手动触发。阅读详情

2022年6月的某一天，办公区的气氛格外的压抑，此时的小编吹着空调双眼微眯的站在同事胖虎身后，看着他满头大汗的将数据库的数据导入到Redis。

经过小编的一番询问才知道，原来是他们生产Redis今天莫名其妙的挂了，而且因为是新项目，一会要给领导演示用，生产环境Redis就只部署了一个节点，这一挂不要紧，缓存进去的数据怎么办...

恰巧这个时候，小编听见老板办公室里传出了一声大喊，“胖虎，来给我演示一下项目”，五分钟后，满脸通红的胖虎从老板办公室里出来了。

这时小编突然想到，Redis不是有持久化机制吗？在和胖虎的交谈中发现，他竟然不知道Redis的持久化机制，小编就默默地装了个13。

Redis持久化

Redis 的持久化机制有两种，一种是快照（RDB），另一种是 AOF 日志。RDB是一次全量备份，AOF 日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。

RDB快照

RDB快照持久化是Redis默认开启的，它会根据配置策略将内存数据保存在一个名为dmp.rdb的二进制文件中。

在redis.conf配置文件中，可以配置RDB的持久化策略，系统默认是有三个保存策略(三个同时生效)，如下：

save 900 1 900秒内有1个键发生改变
save 300 10 30秒内有10个键发生改变
save 60 10000 60秒内有10000个键发生改变

我们也可以根据我们自己生产环境的具体情况进行配置。如果我们要关闭RDB快照，直接将配置文件中上述三个save注释掉即可。

写时复制机制(COW)

Redis提供了save命令进行快照生成，但是save命令要阻塞主进程(执行客户端命令的线程)，当需要生成快照的内存特别大时(几百个G)，需要的时间也会很长，甚至十几秒，所以这个时候如果阻塞主进程，会导致整个服务不可用，就得不偿失了。

针对这种情况，Redis借助操作系统提供的写时复制技术，提供了bgsave命令，basave命令可以在主进程的基础上，fork一个子进程，子进程会共享主进程的代码段和数据段，相当于是在后台生成快照。

在bgsave子进程写入RDB数据时，如果主进程对这些数据也都是读操作，那么，主进程和 bgsave 子进程相互不影响。但是，如果主进程要修改一块数据，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入RDB，而在这个过程中，主进程仍然可以直接修改原来的数据。

演示

bgsave会进行后台操作，不阻塞流程。保存后会生成一个dump.rdb文件。因为二进制文件打开也是乱码，所以我们就不打开了。

优点

Redis宕机后数据恢复快
二进制文件体积小

缺点

持久化策略可能会导致在宕机时数据丢失量较多

AOF(append-only file)

AOF持久化可以通过redis.conf文件中的appendonly参数控制是否开启。

appendonly no 默认情况下是no，将no改为yes即可开启AOF持久化方式，Redis会将修改的每一条指令先记录到系统缓存，默认每隔一秒钟就把缓存刷新到appendonly.aof磁盘文件中当 Redis 重新启动时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。

演示

小编直接修改redis.conf文件中的appendonly参数，然后重启redis，set了几个键值对，等了好几秒，发现当前目录下并没有生成appendonly.aof文件。

后来通过直接在redis-cli执行config set appendonly yes命令，当前目录下才生成appendonly.aof文件。

接下来我们打开appendonly.aof文件就能看到我们之前写入的键值对。

*2 $6 SELECT $1 0 *3 $3 SET $1 1 $1 2 *3 $3 SET $4 key1 $4 val1 *3 $3 SET $4 3124 $3 124 *3 $3 SET $5 key14 $4 key2 复制代码

这是一种resp协议格式数据，星号后面的数字代表命令有多少个参数，$号后面的数字代表这个参数有几个字符。

AOF持久化策略

appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全，不建议用，本身Redis就是借助的内存快的优势，要是每次操作都访问磁盘这个优势就没了。
appendfsync everysec：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据，AOF默认会走在这个配置。
appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择，发生宕机时，丢失的数据最多。

AOF重写

假设我们执行了两个命令 set key1 1 与 set key1 2，在开启AOF持久化的情况下，这两个命令都会被记录到AOF文件中，但是我们在宕机后重启恢复数据的时候是不是就只需要执行set key1 2就可以了，之前的set key1 1在恢复数据的时候忽略掉也没有任何影响，并且因为AOF文件随着时间的推移，体积会越来越大，重写AOF就显得尤为重要。

手动触发后台重写，redis客户端执行命令：bgrewriteaof

Redis提供了两个配置参数控制AOF自动重写频率(redis.conf)。

auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快
auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写

触发重写时 Redis 会通过fork主进程，生成一个子进程去做，这么做的原因是因为重写一般意味着要有大量的I/O操作，非常耗时，如果用主进程去重写会导致主进程长时间的阻塞，影响Redis执行客户端命令，甚至导致服务长时间不可用，但是子进程去重写就意味着主进程仍然可以接收、处理客户端指令，就会导致重写后的AOF文件和服务器当前的数据库状态不一致。

例如：子进程fork主进程时，内存中只有key1这个键，但是当开始重写后，客户端又多set了key2、key3,这就导致了重写的AOF文件和数据库不一致。

所以Redis在AOF重写时加了一个AOF重写缓冲区，当有新命令执行的时候，Redis会将命令发送到AOF缓冲区和AOF重写缓冲区。

执行完重写任务后，子进程会向主进程发送一个信号，主进程收到信号后会执行下面两个操作(以下两个操作会阻塞主进程)：

将 AOF 重写缓冲区中的所有内容写入到新的 AOF 文件中，保证新 AOF 文件保存的数据库状态和服务器当前状态一致。
对新的 AOF 文件进行改名，原子的覆盖现有 AOF 文件，完成新旧文件的替换

虽然只有上面两个操作会阻塞Redis主进程，但是很显然它已经将重写对性能的影响降到了最低。但是如果你想再对其进行优化，这里有两个解决方案。

服务低峰期定时重写
使用ssd，提升持久化效率

注意：AOF在重写时，为了避免执行命令时造成的客户端缓冲区溢出，重写程序在处理列表、哈希表、集合、有序集合这四种可能会有多个元素的键时，会先检查键所包含的元素数量，如果元素的数量超过了redis.h/REDIS_AOF_REWRITe_ITeMS_PER_CMD常量的值(默认64个元素),那么重写程序将会使用多条命令来记录键的值，而不是单单只用一条命令。

优点

数据完整性要高于RDB，默认情况下，最多丢失1秒钟的数据。

缺点

Redis宕机后数据恢复慢
文件体积大

混合持久化(sence redis4.0)

Redis宕机恢复时，为了提高数据的完整程度，我们通常使用 AOF 日志进行恢复，但是使用 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis4.0 为了解决这个问题，推出了混合持久化，说白了，混合持久化就是结合了RDB与AOF两种持久化方式的优势。

启混合模式后，AOF在重写时会将AOF文件中的数据以RDB文件的二进制格式写入当前AOF文件中，之后的新的写操作继续以AOF文件的格式进行追加。当redis宕机重启的时候，加载 AOF 文件进行恢复数据：先加载 RDB 的部分再加载剩余的 AOF内容，因此重启效率大幅得到提升。

通过修改redis.conf文件中的以下配置开启混合持久化(必须先开启AOF持久化)：