RDB快照（snapshot） 在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。 你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次 数据集。 比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 数据集：
# save 60 1000
关闭RDB只需要将所有的save保存策略注释掉即可
还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件， 每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。 save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork（fork()是linux函数）出一个子进程 专门用来生成rdb快照文件 save与bgsave对比：
AOF（append-only file） 快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失 近写入、且仍未保存到快照中的那些数据。从 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文件 例如，执行了如下几条命令：
如下两个配置可以控制AOF自动重写频率 # auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本 来就很快，重写的意义不大 # auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重 写 当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF 注意，AOF重写redis会fork出一个子进程去做，不会对redis正常命令处理有太多影响
RDB 和 AOF ，我应该用哪一个？
redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一 点。