Redis提供了将资料定期自动持久化至硬盘的能力，包括RDB和AOF两种方案，两种方案分别有其长处和短板，可以配合起来同时执行，确保资料的稳定性。

RDB

储存资料快照至一个RDB档案中，用于持久化。RDB操作和Mysql Dump相似。

执行方式

save。同步操作，会阻塞Redis。bgsave。呼叫linux的fork()，然后使用新的执行绪执行复制。但是fork期间也会阻塞Redis，但是阻塞时间通常很短。自动储存。Redis配置档案中设定了自动储存的触发机制，可以自定义修改，执行原理同bgsave。save和bgsave的对比

注意：

如果机器上执行多个Redis，需要配置RDB档名称，否则多个Redis的RDB档案会相互覆盖。除了上述三种执行方式，以下情况也会生成RDB档案：

主从的全量复制时，主机会生成RDB档案。Redis中的debug reload提供debug级别的重启，不清空内存的一种重启，这种方式也会触发RDB档案的生成。执行shutdown时，会触发RDB档案的生成。

RDB的缺点

全量资料储存，耗时。虽然fork()采用copy-on-write策略，但仍消耗内存写RDB档案消耗大量IO效能。

AOF

采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志档案里，AOF操作和Mysql Binlog相似。通过AOF重写机制减少AOF档案的体积，从而减少恢复时间。

执行方式

always。Redis的每条写命令都写入到系统缓冲区，然后每条写命令都使用fsync“写入”硬盘。everysec。过程与always相同，只是fsync的频率为1秒钟一次。这个是Redis预设配置，如果系统宕机，会丢失一秒左右的资料no。由操作系统决定什么时候从系统缓冲区重新整理到硬盘。

AOF重写

为了解决AOF档案体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以建立一个新的AOF档案来替代现有的AOF档案，新旧两个档案所储存的数据库状态是相同的，但是新的AOF档案不会包含任何浪费空间的冗余命令，通常体积会较旧AOF档案小很多。

AOF重写方式

bgrewriteaof（流程与bgsave相似）AOF重写配置（与RDB自动储存相似）AOF重写并不需要对原有AOF档案进行任何的读取，写入，分析等操作，这个功能是通过读取服务器当前的数据库状态来实现的。

RDB vs AOF

Redis启动时的资料载入

Redis启动资料载入流程：

AOF持久化开启且存在AOF档案时，优先载入AOF档案。AOF关闭或者AOF档案不存在时，载入RDB档案。载入AOF/RDB档案成功后，Redis启动成功。AOF/RDB档案存在错误时，Redis启动失败并打印错误资讯。

开发运维中常见的问题

fork操作

fork()的实际开销就是复制父程序的页表以及给子程序建立一个程序描述符，所以速度一般比较快

内存量越大，耗时越长；物理机相对较快，虚拟机器相对较慢。

优化方法

优先使用物理机或者高效支援fork操作的虚拟化技术控制Redis例项最大可用内存maxmemory合理配置Linux内存分配策略：vm.overcommit_memory=1。预设值为0，会使Linux在内存分配时，发现不够内存不足时，不会进行分配，进而造成fork阻塞降低fork频率。例如放宽AOF重写自动触发时机或者减少不必要的主从全量复制程序外开销

CPU。RDB和AOF档案生成，属于CPU密集型。不要将Redis程序系结在某个CPU上,防止单核过载；同时Redis不和CPU密集型应用一起部署。内存。fork内存开销，copy-on-write。硬盘。AOF和RDB档案的写入。可以结合iostat和iotop进行分析。优化方法

不要和高硬盘负载服务部署在一起：储存服务、讯息伫列等配置no-appendfsync-on-rewrite=yes。这样在AOF重写的期间，不要进行AOF追加操作（主执行绪只将资料写入缓冲区），可以减少内存的开销。但如果AOF重写期间，Redis宕机的话，在Linux的系统预设配置下，最多会丢失30s的资料。如果无法忍受资料丢失，no-appendfsync-on-rewrite配置no；如果应用系统无法忍受延迟，而可以容忍少量的资料丢失，则设定为yes。

根据写入量决定磁盘型别：例如ssd单机多例项持久化档案目录可以考虑分盘，或者使用类似cgroups机制进行硬盘资源的合理分配AOF追加阻塞