5分钟理解Redis持久化上一篇我们学习了Redis的核心数据结构

上一篇我们学习了Redis的核心数据结构以及应用场景，本篇来学习一下Redis持久化。
一、RDB快照（snapshot）RDB是一种快照存储持久化方式，具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb ，而在Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。
默认情况下，Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。你可以对 Redis 进行设置，让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时，自动保存一次数据集。
比如说，以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时，自动保存一次数据集：
# save 60 1000关闭RDB只需要将所有的save保存策略注释掉即可。
还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。
【5分钟理解Redis持久化】save是同步命令， bgsave是异步命令， bgsave会从redis主进程fork（fork()是linux函数）出一个子进程专门用来生成rdb快照文件。
save与bgsave对比：
文章插图
配置自动生成rdb文件后台使用的是bgsave方式。
快照功能并不是非常耐久（durable）：如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
二、AOF（append-only file）从 1.1 版本开始，Redis 增加了一种完全耐久的持久化方式： AOF 持久化，将修改的每一条指令记录进文件appendonly.aof中。
你可以通过修改配置文件来打开 AOF 功能：
# appendonly yes从现在开始，每当 Redis 执行一个改变数据集的命令时（比如 SET），这个命令就会被追加到 AOF 文件的末尾。
这样的话，当 Redis 重新启动时，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。有三个选项：
# appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync，非常慢，也非常安全。 appendfsync everysec：每秒 fsync 一次，足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。 # appendfsync no：从不 fsync，将数据交给操作系统来处理。更快，也更不安全的选择。 推荐（并且也是默认）的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。
AOF重写AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件例如，执行了如下几条命令：
1 127.0.0.1:6379> incr readcount2 (integer) 13 127.0.0.1:6379> incr readcount4 (integer) 25 127.0.0.1:6379> incr readcount6 (integer) 37 127.0.0.1:6379> incr readcount8 (integer) 49 127.0.0.1:6379> incr readcount10 (integer) 5重写后AOF文件里变成
1 *32 $33 SET4 $25 readcount6 $17 5如下两个配置可以控制AOF自动重写频率
# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大。 # auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写。 当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF 。
注意， AOF重写redis会fork出一个子进程去做，不会对redis正常命令处理有太多影响。