登录RDB持久化、AOF持久化
更新: 2025/2/24 字数: 0 字 时长: 0 分钟
Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能，主要分为两种：RDB持久化、AOF持久化。
RDB持久化
RDB（Redis DataBase）持久化，在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话将的Snapshot快照，它恢复时是将快照文件直接读到内存里。一般情况下默认的就是RDB持久化模式，不需要修改
RDB持久化细节如下：Redis单独创建一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
生成文件
RDB持久化会生成名称为 dump.rdb 的文件，其名称是可以在配置文件中的快照部分进行配置的：
?> 提示：有时候在生产环境我们会将这个文件进行备份。
触发机制
生成 dump.rdb 文件触发机制有如下三种：
触发方式一：符合配置文件中保存快照的条件。
# 快照配置
save 900 1 # 900秒内，至少有一个key修改就进行持久化操作
save 300 10 # 300秒内，至少有十个key修改就进行持久化操作
save 60 10000 # 60秒内，至少有一万个key修改就进行持久化操作触发方式二：执行flushall命令。
触发方式三：重启Redis。
恢复数据
使用 dump.rdb 文件恢复数据很简单，只需要将该文件放在我们Redis启动目录，Redis启动的时候会自动检查 dump.rdb 文件恢复其中的数据。
?> 提示：使用Redis默认配置就够用了。
使用特点
优点：如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式比AOF方式更加高效；
缺点：保存数据需要一定的时间间隔，如果Redis意外宕机，最后一次持久化后的数据可能丢失；fork进程会占用一定的内存空间。
AOF持久化
**AOF（Append Only File）持久化，将我们所有的命令都记录下来，恢复的时候就把这个文件全部再执行一遍。**详细如下，将Redis执行过的每个写的操作以日志的形式记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
开启AOF
在默认的配置中AOF持久化模式，默认是关闭的，如果要开启需要将配置文件中的 appendonly no 改为 appendonly yes 值：
生成文件
AOF持久化会生成名称为 appendonly.aof 的文件，其名称是可以在配置文件中的快照部分进行配置的：
触发机制
生成 appendonly.aof 文件触发机制有如下三种：
触发方式一：符合配置文件中保存快照的条件。
appendfsync always # 每次修改都会同步，消耗性能
appendfsync everysec # 每秒执行一次同步，可能会丢失这1s的数据
appendfsync no # 不执行同步，这个时候操作系统自己同步数据，速度最快！触发方式二：重启Redis。
修复AOF文件
AOF文件本质就是日志文件，我们可以通过vim去编辑它，但当AOF被错误编辑时，重启Redis就会错误，这时我们就可以使用Redis文件夹里面的一个名称叫 redis-check-aof 的工具去修复AOF文件，修复命令如下：
redis-check-aof --fix appendonly.aof
修复AOF文件后，就可以正常启动Redis了，同时也恢复了Redis中的数据。
使用特点
优点：可以设置同步的规则，数据完整性有保障；
缺点：相对于数据文件来说，aof文件远远大于rdb文件，运行效率、修复速度也比rdb慢。
拓展认识
aof文件默认就是文件的无限追加，文件会越来越大。当aof文件大于64MB，就会fork一个新的进程来将我们的文件进行重写：
综合考虑
1、Redis只做缓存的话，也就是如果希望数据在服务器运行的时候存在，你也可以不使用任何持久化；
2、RDB持久化和AOF持久化是可以同时开启的，在这种情况下，Redis重启时会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据要比RDB文件保存的数据集要完整；如果AOF文件存在Bug，那么RDB文件可以当作备份；
3、因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留 save 900 1 这条规则。