Redis是如何将数据存储到硬盘里面，使得数据在Redis重启之后仍然存在的?

持久化选项

redis提供了两种不同的持久化方法来将数据存储到硬盘里面。
    一种方法叫快照(snapshotting),它可以将存在于某一时刻的所有数据都写入硬盘里面。
    另一种方法叫只追加文件(append-only file,AOF),它会在执行写命令时，将被执行的写命令复制到硬盘里面。这两种持久化方法既可以同时使用(同时存在，先找aof)，又可以单独使用。
将内存中的数据存储到硬盘的一个主要原因是为了在之后重用数据，或者是为防止系统故障而将数据备份到一个远程位置。
复制代码

快照持久化

 redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
整个过程中，主进程是不进行任何IO操作的，这确保了极高的性能。
如果需要进行大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那快照(snapshotting)方式要比AOF方式更加的高效，快照(snapshotting)的缺点是最后一个持久化后的数据可能丢失。

 快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序，而不能接受这种数据损失的应用程序则可以考虑AOF。
复制代码

快照持久化的场景

AOF(Apeend Only File)

     以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)
只允许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据。
换言之，redis重启的话，就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
复制代码

####AOF持久化策略(默认每秒)：

    appendfsync  always  每个redis写命令都要同步写入硬盘，这样做会严重降低redis的速度  
    appendfsync  everysec  每秒执行一次同步，显示地将多个写命令同步到硬盘。
    appendfsync  no 让操作系统来决定应该何时进行同步。
    为了兼顾数据安全和写入性能，用户可以考虑使用appendfsync everysec,让redis以每秒一次的频率对AOF文件进行同步。
复制代码

####AOF总结 AOF文件是一个只进行追加的日志文件 redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写 AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以redis协议的格式保存，因此AOF文件的内容非常容易被人读懂

    对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
    根据所使用的fsync策略，AOF的速度可能会慢于RDB


RDB持久化方式能够在指定的时间间隔对数据进行快照存储
            save 900 1    ---> 900秒写一次
            save 300 10   ---> 300秒写10次
            save 60 10000 ---> 60秒写10000次

AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。
redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

只做缓存: 如果只希望数据在服务器运行的时候存在，也可以不使用任何持久化方式。

性能建议
     因为RDB文件只用做后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save900 1这条规则。
     如果Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本简单只load自己的AOF文件就可以。
     代价 一是带来了持续的IO， 二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免 的。只要硬盘许可，应该尽量减少AOFrewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
     
     如果不Enbable AOF,仅靠Master-Slave Replication 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动，代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据。
复制代码