一文深度剖析Redis6的持久化机制（简洁易懂）

最新推荐文章于 2025-08-17 13:02:36 发布

原创最新推荐文章于 2025-08-17 13:02:36 发布 · 279 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#bootstrap #前端 #javascript

程序员专栏收录该内容

451 篇文章

订阅专栏

本文详细介绍了Redis在无自动快照规则和手动操作时生成RDB快照的过程，比较了RDB和AOF的数据持久化优缺点，并讨论了AOF的fsync同步机制和文件过大时的重写策略。

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

这里只需要了解当执行复制操作时，即时没有定义自动快照规则，并且没有手动执行过快照操作，它仍然会生成RDB快照文件。

RDB数据恢复演示

准备初始数据

redis> set k1 1

redis> set k2 2

redis> set k3 3

redis> set k4 4

redis> set k5 5

通过shutdown命令关闭触发save

redis> shutdown

备份dump.rdb文件(用来后续恢复)

cp dump.rdb dump.rdb.bak

接着再启动redis-server(systemctl restart redis_6379)，通过keys命令查看，发现数据还在

keys *

模拟数据丢失

执行flushall

redis> flushall

shutdown(重新生成没有数据的快照，用来模拟后续的数据恢复)

redis> shutdown

再次启动redis, 通过keys 命令查看，此时rdb中没有任何数据。
恢复之前备份的rdb文件（之前保存了数据的rdb快照）

mv dump.rdb.bak dump.rdb

再次重启redis，可以看到之前快照保存的数据

keys *

文件的优势和劣势

一、优势

1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集，这种文件非常适合用于进行备份和灾难恢复。

2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

3.RDB 在恢复大数据集时的速度比AOF的恢复速度要快。

二、劣势

1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，频繁执行成本过高
2、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。

如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化。

AOF模式

=====

AOF(Append Only File)：Redis 默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis数据的命令时，就会把命令写入到AOF文件中。

Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。

AOF配置开关

开关

appendonly no /yes

文件名

appendfilename “appendonly.aof”

通过修改redis.conf重启redis之后：systemctl restart redis_6379。

再次运行redis的相关操作命令，会发现在指定的dir目录下生成appendonly.aof文件，通过vim查看该文件内容如下

SELECT

set

name

mic

set

name

123

AOF配置相关问题解答

问题1：数据都是实时持久化到磁盘吗？

虽然每次执行更改Redis数据库内容的操作时，AOF都会将命令记录在AOF文件中，但是事实上，由于操作系统的缓存机制，数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作。以便将硬盘缓存中的内容真正地写入硬盘。

在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来说能够启用AOF的前提是业务场景不能容忍这样的数据损失，这个时候就需要Redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在redis.conf中通过如下配置来设置同步机制。

| 参数 | 说明 |

| — | — |

| appendfsync everysec | AOF持久化策略（硬盘缓存到磁盘），默认everysec

1 no 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；

2 always 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；

3 everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。 |

问题2：文件越来越大，怎么办？

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的运行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

例如set gupao 666，执行1000次，结果都是gupao=666。

为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

可以使用命令下面这个命令主动触发重写

redis> bgrewriteaof

AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

重写触发机制如下

| 参数 | 说明 |
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

我的面试宝典：一线互联网大厂Java核心面试题库

以下是我个人的一些做法，希望可以给各位提供一些帮助：

整理了很长一段时间，拿来复习面试刷题非常合适，其中包括了Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等，且还会持续的更新…可star一下！

283页的Java进阶核心pdf文档

Java部分：Java基础，集合，并发，多线程，JVM，设计模式

数据结构算法：Java算法，数据结构

开源框架部分：Spring，MyBatis，MVC，netty，tomcat

分布式部分：架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡等

微服务部分：SpringBoot，SpringCloud，Dubbo，Docker