在Redis的持久化中，常使用的两个手段便是AOF和RDB进行持久化。
RDB（Redis DataBase）是Redis的持久化方式之一，在配置文件中，我们可以找到
对Redis进行持久化配置，而RDB在持久化时是怎么样进行工作的呢？
手动启动Redis-cli，并输入命令save
这样便可以进行一次持久化，而开启这样的save，会导致有一定的影响问题。因为save命令是在主线程运行的，因为Redis在执行命令上是单线程的，所以会阻塞，影响客户端的访问。因此，我们通常会使用bgsave的命令解决这样的问题
启动这样的一次bgsave命令，就可以解决这样的问题。它是从Redis的主线程中通过Linux命令fork一个子线程来进行持久化，这样就不会出现Redis阻塞的问题。
自动配置中：在Redis.conf文件中查看save的配置
这里配置的save命令其实是代表RDB会在900秒内，发生1次key的变化就持久化一次，依次类推后面的，并且这个是不会影响的，只要满足了条件，就可以发生持久化。在自动化的配置中，采用的就是bgsave命令，只是以save的形式展示在配置文件中。
讲到这里还没说到它是如何持久化的
配置文件的save的最开头就会看到snapshot这个单词，其实也就是“快照”的意思，以二进制的形式写入磁盘，保证Redis宕机后，数据没有持久化的问题。
AOF（Append Only File）以文本的形式进行记录用户的新增操作和删除操作，不会记录用户的查询操作。
当将上述命令打开后，就会开启AOF持久化 ，它记录下来的命令，我们在Redis宕机后，重启Redis是可以恢复之前的数据的，而这样是RDB无法做到的，因为RDB是定时去进行持久化的，很有可能是没有及时存储到数据的。
但是由于AOF文件会越来越大，所以需要定期对AOF进行文件压缩的处理，以免占用太多内存。
综上所述：
RDB是基于时段来进行持久化的，而AOF是发生数据的改动就会持久化。而RDB由于有时间空隙的问题，数据安全性自然是不如AOF的。AOF恢复数据的速度慢，并且运行效率也也没有RDB的高，而且AOF的文件通常是比RDB的文件大的。不过AOF的rewrite机制可以定期对AOF文件进行重写，以达到压缩的目的。
