【漫画】谈谈Redis持久化，一线互联网大厂中高级Java面试真题收录

save 60 1000

这个配置指的是,每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting快照。

当然你也可以手动调用save或者bgsave命令，同步或异步执行rdb快照生成，同时save可以设置多个，就是多个snapshotting检查点，每到一个检查点，就会去check一下，是否有指定的key数量发生了变更，如果有，就生成一个新的dump.rdb文件。

上面画了个简单的图，描绘的是RDB持久化机制的工作流程，具体来看可以有如下几个步骤：

（1）redis根据配置自己尝试去生成rdb快照文件

（2）fork一个子进程出来

（3）子进程尝试将数据dump到临时的rdb快照文件中

（4）完成rdb快照文件的生成之后就替换之前的旧的快照文件dump.rdb，每次生成一个新的快照，都会覆盖之前的老快照

AOF

AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

找到配置文件后，你需要修改的第一个配置为：

appendonly yes

以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的，除非你说随便丢个几分钟的数据也无所谓。

打开AOF持久化机制之后，redis每次接收到一条写命令，就会写入日志文件中，当然是先写入oscache的，然后每隔一定时间再fsync一下磁盘文件。

除开appendonly的这个配置项，关于AOF还有一个非常有意思的配置:

appendfsync everysec

这个appendfsync 默认值是everysec，除开这个以外，总共有3个取值的可能：

always: 每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了。

everysec:每秒将oscache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的。

no:仅仅redis负责将数据写入oscache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了。

可见默认值就是最好的选项了

（1）redisfork一个子进程。

（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志。

（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件。
临时的AOF文件中写入日志。

（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件。