深入理解redis——Redis的持久化机制RDB/AOF

1.Redis的持久化机制之RDB

2.Redis的持久化机制之AOF

3.总结

4.使用建议

1.Redis的持久化机制之RDB

我们都知道，Redis的所有数据都保存在内存里，但是redis的数据肯定要进行持久化，不然当redis宕机的时候，数据就恢复不回来了。

RDB是什么：
RDB是在指定的时间间隔内将内存中的数据集快照写入磁盘。

运行原理：
Redis会单独创建（fork）一个子线程来进行持久化，会将数据写入到一个临时文件中，等待将数据及快照写入都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果要进行大规模的数据恢复，且对数据恢复的完整性不是很敏感（可以丢失一部分数据），那RDB方式比AOF（下文会解释）方式更加高效，RDB的缺点就是最后一次持久化的数据可能会丢失。

配置位置：

save 秒钟 写操作次数
默认值：
save 60 10000 是1分钟内改了1万次，
save 300 10 是5分钟内改了10次，
save 900 1 是15分钟内改了1次。

如何触发rdb持久化：

我们可以等待它到点触发，也可以使用save或者bgsave主动触发。保存的文件位置，默认是和redis一起的。

不过生产上的备份文件，一般都会在另外一台机器上备份，如果备份文件也在redis服务器，就达不到容灾的目的了。

优点	缺点
适合大规模的数据恢复	会丢失最后一次的修改
对数据完整性和一致性不高	fork的时候，内存中的数据要被克隆一倍，大致2倍的膨胀性需要思考

2.Redis的持久化机制之AOF

Redis的AOF是以日志的形式来记录每个写操作（RDB只记录各个键值对的最终值），将Redis执行过程中的所有写操作指令记下来（读操作不记录）。在文件的尾部增加内容，redis重启后根据日志文件的内容将写指令从头到尾执行一次完成恢复工作。

如果aof的文件越写越大怎么办？

AOF的重写机制：
在备份文件越写越大的时候，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。

AOF的重写原理：
AOF文件持续增长而过大时，会fork出一条新线程来将文件重写，遍历新进程的内存中的数据，每条记录有一条set语句。

重写aof的操作，并不会读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和rdb有点类似。

优点	缺点
实时性高	aof文件大，同步速率慢

3.总结

1）RDB持久化方式能够在指定的时间间隔对你的数据进行持久化。

2）AOF持久化方式记录每次对服务器的写操作，当服务器重启的时候就会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加每次保存的写操作到文件末尾，Redis还可以对大的aof文件进行压缩重写。

3）我们可以同时开启两种持久化方式，在这种情况下，redis会优先载入aof来恢复数据，因为aof比rdb的文件数据集要完整。

4.使用建议
RDB文件只用作后备用途，建议只在slave上持久化rdb文件，且只要15分钟备份一次就可以，保留save 900 1.

如果我们开启了aof，好处就是在最恶劣的情况下也只丢失不超过两秒的数据，启动脚本较简单。代价就是带来了持续的IO，而是AOF压缩aof文件的时候，造成的阻塞时不可避免的，应该尽量减少aof的频率，AOF重写的基础大小默认值64m太小了，应该设置到5G以上，默认超过原大小的100%大小时就可以重写到适当的数值。

如果不开启aof，仅仅依靠正从复制也可以，就节省了很多IO，代价丢失master/slave同时宕机，会丢失十几分钟的数据。