原创：享学课堂讲师
转载请声明出处！

RDB

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis重启会通过加载dump.rdb文件恢复数据。

找到配置文件，在配置redis.conf文件里面找下如下的配置

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文件。

(4)子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中。

(5)用新的日志文件替换掉旧的日志文件。

• Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
• RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
• Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
• AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
• Redis 针对AOF文件大的问题，提供重写的瘦身机制。
• 若只打算用Redis做缓存，可以关闭持久化。
• 若打算使用Redis的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

如果喜欢本文，可以关注我们的官方账号，第一时间获取资讯。
你的关注是对我们更新最大的动力哦~

私信回复“java”可以领取java课件和资料。