从内存中读取数据确实能提高访问速率，但是当Redis挂了，内存中的数据就会丢失掉，为了防止数据丢失，我们须要将数据持久化到硬盘中。当Redis挂了，数据已经存储到硬盘中了，Redis重启后，硬盘中的数据就会重新加载到内存中。
那么，问题来了。
Redis是如何持久化的？
在Redis中供应了两种不同的持久化办法：RDB和AOF。
RDB持久化办法能够在指定的韶光间隔能对你的数据进行快照存储。AOF持久化办法记录每次对做事器写的操作，当做事看重启的时候会重新实行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末端。Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。当我们同时开启两种持久化办法时，在Redis重启的时候会优先载入AOF文件来恢复原始的数据，由于在常日情形下AOF文件保存的数据集要比RDB文件保存的数据集要完全。我们来看看Redis的配置文件redis.conf，看看有关持久化的配置。
如果我们要启用AOF模式，须要将
appendonly no修正为appendonly yes
这是3个AOF持久化策略配置。
appendfsync everysec：表示每秒实行一次数据同步到硬盘的操作，那么这一秒的间隔内很有可能数据丢失。这个是程序默认的策略。
appendfsync always：表示每次写入都会实行数据同步。
appendfsync no：表示Redis不实行数据同步，由操作系统实行。
我们再来看看RDB形式存储配置。
这里的格式为：
save <韶光间隔（秒）> <写入次数>
从上面的配置我们知道：
save 900 1：900秒内如果至少有一个key的值发生变革，则保存。
save 200 10：300秒内如果至少有10个key值发生变革，则保存。
save 60 10000：规则同上。
如果我们要停用，直接注释即可。
关于RDB我们来看看RDB有什么优缺陷。
RDB的优点RDB是一个非常紧凑的文件，它保存了某个韶光点的数据集，非常适用于数据集的备份，比如你可以在每个小时保存一下过去24小时内的数据，同时每天保存过去30天的数据。这样纵然出了问题你也可以根据需求规复到不同版本的数据集。RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中央，非常适用于灾害规复。RDB在保存RDB文件时父进程唯一须要做的便是fork出一个子进程，接下来的事情全部由子进程来做，父进程不须要再做其他IO操作，以是RDB持久化办法可以最大化redis的性能。与AOF比较，在规复大的数据集的时候，RDB办法会更快一些。RDB的缺陷如果你希望在Redis意外停滞事情（例如电源中断）的情形下丢失的数据最少的话，那么RDB不适宜你。虽然你可以配置不同的save韶光点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要完全的保存全体数据集是一个比较繁重的事情，你常日会每隔5分钟或者更久做一次完全的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据。RDB 须要常常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能相应客户真个要求.如果数据集巨大并且CPU性能不是很好的情形下，这种情形会持续1秒，AOF也须要fork，但是你可以调节重写日志文件的频率来提高数据集的耐久度。从上面我们可以知道，RDB保存的是数据，由于数据的保存是个非常繁重的操作，以是保存的是某个韶光段的数据，因此用RDB规复数据会比较快。但是规复的数据可能会有丢失的。
关于AOFAOF的优点利用AOF 会让Redis更加耐久，我们可以利用不同的fsync策略：无fsync，每秒fsync,每次写的时候fsync。利用默认的每秒fsync策略，Redis的性能依然很好(fsync是由后台线程进行处理的，主线程会尽力处理客户端要求)，一旦涌现故障，你最多丢失1秒的数据。AOF文件是一个只进行追加的日志文件，以是不须要写入seek，纵然由于某些缘故原由(磁盘空间已满，写的过程中宕机等等)未实行完全的写入命令，我们也可利用redis-check-aof工具修复这些问题。Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了规复当前数据集所需的最小命令凑集。 全体重写操作是绝对安全的，由于 Redis 在创建新 AOF 文件的过程中，会连续将命令追加到现有的 AOF 文件里面，纵然重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。AOF 文件有序地保存了对数据库实行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常随意马虎被人读懂， 对文件进行剖析（parse）也很轻松。 导出（export） AOF 文件也非常大略： 举个例子， 如果你欠妥心实行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停滞做事器， 移除 AOF 文件末端的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集规复到 FLUSHALL 实行之前的状态。AOF的缺陷
对付相同的数据集来说，AOF 文件的体积常日要大于 RDB 文件的体积。根据所利用的 fsync 策略，AOF 的速率可能会慢于 RDB 。 在一样平常情形下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速率和 RDB 一样快， 纵然在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以供应更有担保的最大延迟韶光（latency）。从上面我们可以知道，AOF模式保存的是写入命令，由于保存的是操作的命令，以是在保存这一步动作比较轻松，规复起来的数据也会比较全，但是由于保存的是命令，规复时须要实行一次这些命令，会比较耗时。
综上所述，我们可以利用RDB与AOF稠浊模式来进行持久化。未来Redis可能会将RDB与AOF合成单个持久化模型。
参考Redis官网：http://www.redis.cn/topics/persistence.html
