Redis持久化就是将内存中的数据存储到硬盘中。

持久化的目的就是为了保障数据不丢失，因为内存只要一断电就会清空数据。

Redis官方提供了两种持久化机制：

当Snapshot和AOF同时开启时，Redis会采用AOF持久化方案。

该种方式是Redis中默认的持久化方式。

在拍摄快照时将当时Redis中的数据状态记录下来，构建成 dump.rdb 快照文件存储在硬盘中。在数据恢复时执行 dump.rdb ，就可以将当时Redis中的所有数据重新装载入Redis。

BGSAVE和SAVE指令都可以生成快照，但二者有所不同。

官方推荐使用BGSAVE指令生成快照。

使用BGSAVE生成快照时，Redis不会阻塞。因为Redis是用主进程来处理客户端请求的，当客户端使用BGSAVE指令让Redis生成快照时，Redis会调用fork创建一个子进程，然后子进程负责将快照写入磁盘中，主进程则继续处理客户端的命令请求。

fork是类Unix系统上创建进程的函数。

当一个进程使用fork创建子进程的时候，底层的操作系统会创建该进程的一个副本，在类Unix系统中创建子进程的操作会进行优化。在刚开始的时候，父子进程共享相同内存，直到父进程或子进程对内存进行了写操作之后，对被写入的内存的共享才会结束服务。

使用fork的好处在于：因为使用fork创建的子进程会和主进程共享内存，所以当Redis使用fork创建子进程去生成快照时，主进程只要接收的都是读操作（Redis绝大部分操作都是读操作），那么父子进程就会持续共享内存，大大提高了子进程生成快照的速度。

使用SAVE生成快照，Redis会阻塞。Redis服务在快照创建完毕之前，不再响应任何其他命令，因为Redis会直接使用主进程来生成快照。

如果用户在 redis.conf 中设置了save配置选项，Redis会在save选项条件满足之后自动触发一次BGSAVE命令。如果设置多个save配置选项，当任意一个save配置选项条件满足，Redis也会触发一次BGSAVE命令。

Redis默认配置了3个save配置选项

save配置选项的格式为：

例如：

如上命令表示，如果900s以内，只要有一个Key发生改变，就自动触发BGSAVE指令。

当Redis服务接收到客户端的shutdown指令关闭服务时，也会自动生成快照。该生成快照底层使用的是SAVE指令，因此会阻塞Redis服务，不再执行客户端发送的任何命令，在SAVE指令执行完毕之后关闭服务器。

之所以这样设计，是因为shutdown就是明确让Redis服务关闭了，此时Redis服务就应该处于阻塞状态，不再处理任何请求了。

CTRL + C底层调用的就是shutdown指令。

dump.rdb 中持久化的数据都是以二进制的格式保存，不会显示明文内容。

dump.rdb 名称可以在 redis.conf 中修改，但是后缀必须是 .rdb 。

dump.rdb 生成位置也可以在 redis.conf 中修改，但是必须指定一个绝对或者相对路径，不能是个文件名。

默认生成位置是 redis-server 脚本启动的当前目录。

当Redis刚生成了快照之后，紧接着又响应了若干次写操作修改了部分数据，但是该写操作并没有达到触发自动生成快照的条件。如果在此时Redis忽然断电，那么此时的 dump.rdb 并没有保存由于执行了若干次写操作更新的数据，因此Redis会丢失不定量的数据，恢复也只能恢复在执行写操作之前的数据。

AOF持久化机制是通过将被执行的所有写命令追加到AOF文件的末尾，以此来记录全部数据生成的过程和发生的变化。在数据恢复时让Redis从头到尾执行一次AOF中记录的所有写命令，就可以恢复原来的数据。

AOF默认是没有开启，需要在 redis.conf 中进行配置。

AOF文件默认名称为 appendonly.aof，存储位置和 dump.rdb 一致。

appendonly.aof中不仅仅记录所有写命令，其实还会在写命令之间添加一些特殊符号，例如 "$" 、"*"。实际上这些符号的作用是为了充实写命令的内容，比如将该数据恢复到哪一个库中等。但是appendonly.aof中的主体还是所有写命令。

AOF提供了三种日志追加频率

默认是everysec，也就是说，每过一秒都会将前一秒的写命令追加进到 appendonly.aof 中。

假设该一秒中有1000个客户端执行了写操作，那么在该秒结束后，Redis会将这1000条指令一次性追加到 appendonly.aof 中。

日志追加频率可以在 redis.conf 中进行配置

不建议配置always，因为always的同步策略会严重降低Redis的速度。

如果用户使用了always选项，那么每个Redis写命令都会被实时写入硬盘，虽然可以将发生系统崩溃时出现的数据丢失减到最少，但是这种同步策略需要对硬盘进行大量的写入操作，会导致Redis处理命令的速度受到硬盘性能的限制。

这里涉及到 "写入放大" 的知识，就是如果在某一时刻，往硬盘中不断写入小文件，会极大影响硬盘的处理速度，并且会严重影响磁盘寿命。

如果电脑使用的是磁盘当作硬盘，磁盘一般可以追加200个命令/s，如果设置了always，而每秒持续追加的命令多达200+，那么长时间硬盘就会积累越来越多的命令无法处理，最终就会将硬盘拖垮，而导致Redis服务阻塞。

如果电脑使用的是SSD当作硬盘，固态硬盘可以追加几百万个命令/s，但是也慎用always，因为 "写入放大" 的问题也会严重减少SSD的寿命。

为了兼顾数据安全和写入性能，推荐用户配置everysec，让Redis每秒一次的频率对AOF文件进行同步。

Redis每秒同步一次AOF文件时，性能和不使用任何持久化特性时的性能相差无几。而通过每秒同步一次AOF文件，Redis可以保证，即使系统崩溃，Redis也最多丢失一秒之内产生的数据。

no不是不同步，只是将同步的权限由Redis交给了操作系统，同样不推荐使用。

no有两个明显弊端，都是由于操作系统控制同步导致的。一个是当服务器崩溃时，会丢失不等量的数据，甚至全部数据。另一个就是因为如果Redis积攒了很长时间的写命令在操作系统的控制下进行一次性同步，此时如果硬盘处理速度还不过快，缓冲区就会被等待写入的数据填满，Redis就会处于阻塞状态。

AOF会使持久化文件会变的越来越大。

例如我们调用 incr test 命令100次，AOF文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实只需要保存一条 set test 100 就够了。

为了压缩AOF的持久化文件，Redis提供了AOF重写机制。

AOF重写机制的作用就是一定程度上减小AOF文件的体积。

必须开启AOF持久化方案，且 appendonly.aof 文件已经生成。

BGREWRITEAOF指令执行不会阻塞Redis，类似于BGSAVE指令。

自动触发的底层调用的也是BGREWRITEAOF指令。

在 redis.conf 中进行配置。

表示当AOF文件的体积比原体积或上一次重写后的体积原来大了100%（1倍）时，触发重写。

表示当AOF文件体积大于64mb时，触发重写。

这两个配置结合，当AOF文件越小，重写的次数越频繁，最终会让AOF文件始终保持一个比较小的状态。

重写并不是对原AOF文件进行压缩，而是生成一个体积更小的AOF文件对原AOF文件进行替换。

具体流程如下：

如果原AOF文件过于庞大，那么在删除原AOF文件时，也会占用系统资源，极端情况下也可能会导致Redis阻塞。