求。具体操作是 Redis 进程执行 fork 操作创建子进程（copy-on-write），RDB 持久化过程由子进程负责，完成后自动结束。它不会记录 fork 之后后续的命令。阻塞只发生在 fork 阶段，一般时间很短。用 lastsave 命令可以查看最近一次成功生成快照的时间。

使用 shutdown 持久化

我们先在 Redis 库中设置如下几个值

set k1 1set k2 2set k3 3set k4 4set k5 5

操作完成上面的步骤之后我们停止服务器，触发 RDB 的自动保存 save

shutdown

然后再次启动 Redis 服务

redis-server redis.conf

启动完成，查看

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

我们那些刚刚保存的数据是否被持久化了 keys *

执行完上面的步骤之后，我们可以看到我们的数据都在，就说明我们的触发备份是成功的。

使用 flushall 模拟数据丢失

该操作有一定的风险性，如果是演示练习按照操作来基本不会出现问题，但是生产上慎重操作。我们做该操作之前，一定要注意先备份 RDB 对应的持久化问题 dump.rdb

先备份 dump.rdb

cp dump.rdb dump.rdb.bak

备份完成之后我们确定备份成功在进行下一步操作---清空库

flushall

清空之后我们停止服务器

shutdown

再次启动服务器，查看之前存储的 kye

keys *

再次启动查看的时候，我们发现我们的数据丢失了

恢复丢失的数据

停服务器

shutdown

删除我们现有 dump.rdb

rm -rf ./dump.rdb

删除成功之后，将我们的备份的 dump.rdb.bak 重新命名成为 dump.rdb

mv dump.rdb.bak dump.rdb

确定之后我们再次启动 redis 服务

redis-server redis.conf

检查我们之前丢失的数据是否存在

keys *

完成之后我们查看的数据就出现啦！

AOF [Append Only File]

AOF：Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改 Redis 数据的命令时，就会把命令写入到 AOF 文件中。Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。

该方式默认关闭，需要使用我们需要修改如下配置

开关 Redis 默认只开启 RDB 持久化，开启 AOF 需要修改为 yes

appendonly no

文件名 路径也是通过 dir 参数配置 config get dir

appendfilename "appendonly.aof"

数据都是实时持久化到磁盘吗？

由于操作系统的缓存机制，AOF 数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到 AOF 文件？

AOF 的保存规则有三种

AOF 持久化策略（硬盘缓存到磁盘），默认 everysec

• no 表示不执行 fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；

• always 表示每次写入都执行 fsync，以保证数据同步到磁盘，效率很低；

• everysec 表示每秒执行一次 fsync，可能会导致丢失这 1s 数据。通常选择 everysec ，兼顾安全性和效率。

文件越来越大，怎么办？

由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。可以使用命令 bgrewriteaof 来重写。AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

AOF 指定大小开始重写

• auto-aof-rewrite-percentage:默认值为 100。aof 自动重写配置，当目前 aof 文件大小超过上一次重写的 aof 文件大小的百分之多少进行重写，即当 aof 文件增长到一定大小的时候，Redis 能够调用 bgrewriteaof 对日志文件进行重写。当前 AOF 文件大小是上次日志重写得到 AOF 文件大小的二倍（设置为 100）时，自动启动新的日志重写过程。

• auto-aof-rewrite-min-size:默认 64M。设置允许重写的最小 aof 文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。

• AOF 方式的优点

• AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。

• AOF 方式的缺点

• 对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大（RDB 存的是数据快照）。

• 虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。

两种方案比较

那么对于 AOF 和 RDB 两种持久化方式，我们应该如何选择呢？如果可以忍受一小段时间内数据的丢失，毫无疑问使用 RDB 是最好的，定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。否则就使用 AOF 重写。但是一般情况下建议不要单独使用某一种持久化机制，而是应该两种一起用，在这种情况下,当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。