Redis（2）持久化基本原理优缺点在合适的场景下，选择相应的策略进行数据备份到磁盘

本文深入解析Redis的两种持久化机制：RDB与AOF。RDB通过快照定期保存内存状态，而AOF则记录所有写操作指令，用于数据恢复。文章探讨了各自的优缺点，如RDB的性能损耗与数据丢失风险，AOF的高数据一致性和性能开销。同时，介绍了如何在两者间做出选择，以及Redis如何结合使用以达到最佳效果。

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

Redis持久化 RDB && AOF

RDB持久化

RDB（Redis DataBase：在不同的时间点将redis的内存数据转化为二进制生成一份副本并存储在磁盘上）：内存到磁盘的快照，定期更新。当redis重启时，并且持久化为开启时，redis会读取RDB的持久化生成的（默认dump.rdb,可以通过设置dbfilename修改），

（1）手动执行持久化

save ，salve，bgsave

（2）配置文件方式

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照

关于持久化的信息可以通过 info Persistence查看

缺点：颗粒度大，耗时，耗性能（fork + IO 操作），易丢失数据（在save等操作之前就crash了，中间的操作就无法保存）

AOF持久化

AOF（Append Only File 将所有的redis所执行过的指令都记录下来，在下次redis重启时，只需要执行指令就可以了）

底层实现：把写操作指令，持续的写到一个类型日志文件里。(类型于从postgresql等数据库导出sql一样，只记录写操作)

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。

区别

一个利用持续的用日志记录写操作，crash后利用日志回复，

一个是平时写操作时，不触发，只有手动的save，命令，或者关闭命令的时候，，才触发备份文件操作

如何选择

牺牲性能--> 换取更高的缓存一致性（AOF）

写操作频繁时换取性能->不启动备份文件，等到需要备份的时候，再手动备份。

其他

bgsave 做镜像全量持久化，aof做增量持久化。因为bgsave会消耗较长的时间，不够实用，在crash时，会导致大量的数据丢失，需要AOF来配合。在redis实例重启是，优先使用aof来恢复内存的状态，如果没有aof日志，就会使用rdb的文件来恢复。redis会定期做aof重写，压缩aof文件日志大小。redis4.0以后，有了混合持久化的功能，将bgsave的全量和aof增量做了融合处理，这样既保证了恢复的效率和数据的安全性

bgsave原理：fork和cow ，fork是指redis通过创建自进程进行bgsave操作，而不阻塞主进程，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写操作服务，写脏的页面数据会逐渐和字进程分离开来

参考：https://www.cnblogs.com/shizhengwen/p/9283973.html