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同时宕机，会失落十几分钟的数据。