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启动时的数据加载

[外链图片转存失败(img-8fuQiQR2-1563546641258)(http://mseddl.gitee.io/photos/backend/redis/redis-start.png)]

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追加阻塞

例如在AOF的everysec策略中，主线程会对比上次fsync的时间，如果距离上次fsync时间超过两秒，就会造成主线程阻塞（等待同步线程同步完成）。

日常开发可以使用info persistence命令，查看历史发生AOF阻塞的次数；然而需要了解AOF追加阻塞的发生时间则需要查看Redis日志。

发送AOF追加阻塞的时候，日志如下：

Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

优化方法（参考其他方面的优化点）