深入理解Redis

持久化策略一 RDB快照

持久化策略二 AOF日志

和其他数据库比较

1.持久化策略一 RDB快照

Redis支持将当前数据的快照存成一个数据文件的持久化机制。

不足: 每次快照持久化都是将内存数据完整写入到磁盘一次，如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘I/O操作，可能会严重影响性能。

由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果某些业务可以忍受这些不足,推荐使用RDB快照,因为开启RDB代价不高。

如果应用要求不能丢失任何修改的话，可以采用AOF日志持久化方式。

2. 持久化策略二 AOF日志

AOF日志的全称是Append Only File，从名字上我们就能看出来，它是一个追加写入的日志文件。与一般数据库不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。

你可以会想，每一条写命令都生成一条日志，那么AOF文件是不是会很大？答案是肯定的，AOF文件会越来越大，所以Redis又提供了一个功能，叫做AOF rewrite。

其功能就是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。

具体过程如下：

redis调用fork ，现在有父子两个进程

子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令

父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。

当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。

现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

3.和其他数据库比较

1.在数据安全方面,

在Redis开启AOF的情况下，其单机数据安全性并不比那些成熟的SQL数据库弱。

2.在数据导入方面的比较

这些持久化的数据有什么用，当然是用于重启后的数据恢复。Redis是一个内存数据库，无论是RDB还是AOF，都只是其保证数据恢复的措施。所以 Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。相对于MySQL等数据库的启动时间来说，会长很多，因为MySQL本来是不需要将数据加载到内存中的。

但是相对来说，MySQL启动后提供服务时，其被访问的热数据也会慢慢加载到内存中，通常我们称之为预热，而在预热完成前，其性能都不会太高。而Redis的好处是一次性将数据加载到内存中，一次性预热。这样只要Redis启动完成，那么其提供服务的速度都是非常快的。

而在利用RDB和利用AOF启动上，其启动时间有一些差别。RDB的启动时间会更短。

原因有两个：一是RDB文件中每一条数据只有一条记录，不会像 AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作。在CPU消耗上要远小于AOF日志的加载。

参考Redis作者的博文：Redis persistence demystified