除了我们在配置文件中配置自动生成快照文件之外，Redis 本身提供了相关的命令可以让我们手动生成快照文件，分别是 SAVE 和 BGSAVE ，这两个命令功能相同但是方式和效果不一样，SAVE 命令执行完后阻塞服务器进程，阻塞过后服务器就不能处理任何请求，所以在生产上不能用，和SAVE 命令直接阻塞服务器进程的做法不同，BGSAVE 命令是生成一个子进程，通过子进程来创建 RDB 文件，主进程依旧可以处理接受到的命令，从而不会阻塞服务器，在生产上可以使用。
阿粉在这里测试一下自动生成快照，我们修改一下快照的生成策略为save 10 2，然后在本地启动Redis 服务，并用 redis-cli 链接进入，依次步骤如下
- 修改配置，如下
启动 Redis 服务，我们可以从启动日志中看到，默认是会先读取 RDB 文件进行恢复的
链接 Redis 服务，并在 10s 内设置 3 个 key
这个时候我们会看到 Redis 的日志里面会输出下面内容，因为触发了规则，所以开启子进程进行数据备份，同时在对应的文件路径下面，我们也看到了 rdb 文件。
从上面可以看出，我们配置的规则生效了，也成功的生成了 RDB 文件， 后续在服务器出现异常的情况，只要重新启动就会读取对应的 RDB 文件进行数据备份。
AOF
AOF 是一种追加执行命令的形式，它跟 RDB 的区别是，AOF 并不是把数据保存下来，而是保存执行的动作。在开启 AOF 功能的时候，客户端连接后执行的每一条命令都会被记录下来。这其实让阿粉想起来的 MySQL 的 binlog 日志，也是记录操作的命令，后续可以根据文件去恢复数据。
AOF 是追加命令格式的文件，同样的我们可以定义多长时间把数据同步一次，Redis 本身提供了三种策略来实现命令的同步，分别是不进行同步，每秒同步一次，以及当有查询的时候同步一次。默认的策略也是使用最多的策略就是每秒同步一次，这样我们可以知道，丢失的数据最多也就只有一秒钟的数据。有了这种机制，AOF 会比 RDB 可靠很多，但是因为文件里面存在的是执行的命令，所以AOF 的文件一般也会比 RDB 的文件大点。
