概述:

　　Redis是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘；当下次Redis重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。

　　Redis持久化分为RDB持久化和AOF持久化：前者将当前数据保存到硬盘，后者则是将每次执行的写命令保存到硬盘 ; 由于AOF持久化的实时性更好，即当进程意外退出时丢失的数据更少，因此AOF是目前主流的持久化方式，不过RDB持久化仍然有其用武之地。

　　下面依次介绍RDB持久化和AOF持久化:

一. RDB持久化

　　RDB持久化是将当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化)，保存的文件后缀是rdb；当Redis重新启动时，可以读取快照文件恢复数据。

如果手动删除 dump.rdb 文件后,重启服务器后数据会全部丢失

1. 触发条件

　　1) 手动触发

　　save命令和bgsave命令都可以生成RDB文件。

　　save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。

　　

 　　而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

　　

　　此时 redis 服务器执行日志如下：

 　　

 　　bgsave命令执行过程中，只有在执行fork操作创建子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用；此外，在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化；

　　2) 自动触发

　　save m n

　　自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

　　例如，查看redis的默认配置文件(Linux下为redis根目录下的redis.conf)，可以看到如下配置信息：

　　

 　　其中save 900 1的含义是：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave；save 300 10和save 60 10000同理。当三个save条件满足任意一个时，都会引起bgsave的调用。

关闭自动触发 ,就删除上述三个条件,添加一个  save " " 

 

　　3) 其他自动触发机制

• 执行shutdown命令时，自动执行rdb持久化 
• 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点

2. RDB文件

1) 存储路径

　　RDB文件是经过压缩的二进制文件,RDB文件的存储路径既可以在启动前配置，也可以通过命令动态设定。

　　通过命令动态设定：dir配置指定目录，dbfilename指定文件名。默认是Redis根目录下的dump.rdb文件。如下所示(Windows环境)：

　　

 

　　进入到对应的目录中可找到该文件(修改在服务器重启后失效):

 　　

 

　　启动前配置:修改配置文件来修改存储rdb文件的位置(修改长期有效):

　　

注 :  dir ./：RDB文件和AOF文件所在目录

 2) 加载时机

　　RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

　　Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

 

---

二. AOF持久化:

　　RDB持久化是将进程数据写入文件，而AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中；当Redis重启时再次执行AOF文件中的命令来恢复数据。

　　与RDB相比，AOF的实时性更好，因此已成为主流的持久化方案。

1. 开启AOF

　　Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：appendonly yes

2. 执行流程

　　由于需要记录Redis的每条写命令，因此AOF不需要触发.

　　AOF的执行流程包括：

• 命令追加(append)：将Redis的写命令追加到缓冲区aof_buf；
• 文件写入(write)和文件同步(sync)：根据不同的同步策略将aof_buf中的内容同步到硬盘；
• 文件重写(rewrite)：定期重写AOF文件，达到压缩的目的。

1) 命令追加(append)

　　Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

2) 文件写入(write)和文件同步(sync)

　　Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：

　　为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

　　AOF缓存区的同步文件策略由参数 appendfsync 控制，各个值的含义如下：

• always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
• no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
• everysec：命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

　　配置文件如下图:

　　

3) 文件重写(rewrite)

　　随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。

文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作!

关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些实现中，会关闭自动的文件重写，然后通过定时任务在每天的某一时刻定时执行。

　　文件重写之所以能够压缩AOF文件，原因在于：

• 过期的数据不再写入文件
• 无效的命令不再写入文件 : 如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(sadd myset v1, del myset)等等
• 多条命令可以合并为一个 : 如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。

文件重写的触发

　　文件重写的触发，分为手动触发和自动触发：

　　手动触发：直接调用 bgrewriteaof 命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。默认在redis根目录下生成 appendonly.aof 文件

　　

 

　　 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数，以及aof_current_size和aof_base_size状态确定触发时机。

 　　

• auto-aof-rewrite-min-size：执行AOF重写时，文件的最小体积，默认值为 67108864 字节 (64MB)。
• auto-aof-rewrite-percentage：执行AOF重写时，当前AOF大小(aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。

　　状态可以通过info persistence查看 , 注意只有在开启 AOF持久化时才能查看到这两个属性

　　

 　　只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作.