什么是Redis持久化？
Redis是键值对的内存数据库，它将数据存储在内存里。客户端发送命令到服务器，再由服务器到内存里查找数据。
一旦Redis服务器进程退出，存储在内存里的数据就会丢失。
为了解决这个问题，Redis提供了持久化机制，即将数据保存到磁盘里，以便Redis服务器进程初始化或重启后重新加载数据，避免数据丢失。
Redis提供两种持久化方案，分别是RDB（Redis DataBase）和AOF（Append Only File）。
RDB持久化
RDB采用快照的方式来实现持久化，把数据库数据保存到RDB文件里，也可以通过RDB文件还原数据库数据。
开启RDB持久化的方式
RBD是Redis默认的持久化方案，可以通过三种方式来生成RDB文件：SAVE、BGSAVE和自动触发，其中前两种是主动操作，后一种是被动操作，由Redis服务器控制。
SAVE
SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完成，在服务器进程阻塞期间，服务器不能处理任何命令请求。
redis> Save // 等待直到RDB文件创建完成
OK
BGSAVE
和SAVE命令直接阻塞服务器进程不同，BGSAVE命令会fork一个子进程来负责创建RDB文件，服务器进程继续处理命令请求。
redis> BGSAVE // fork子进程，并由子进程创建RDB文件
Background saving started
自动触发
Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。用户可以通过save选项设置多个条件，只要满足其中任意一个条件，服务器就会执行BGSAVE命令。
save 900 1 // 服务器在900秒内，至少1次修改
save 300 10 // 服务器在300秒内，至少10次修改
save 60 10000 // 服务器在60秒内，至少10000次修改
AOF持久化
除了RDB外，Redis还提供了AOF。与RDB通过保存数据库快照不同，AOF是通过保存命令来记录数据库数据的。默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：
# appendonly参数开启AOF持久化
appendonly no
# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./
# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no
# aof重写期间是否同步
no-appendfsync-on-rewrite no
# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 加载aof出错如何处理
aof-load-truncated yes
# 文件重写策略
aof-rewrite-incremental-fsync yes
AOF持久化实现
AOF需要记录Redis的每个命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。
命令追加
当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的 aof_buf 缓冲区的末尾。
文件写入和同步
关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种策略：
appendfsync always：将aof_buf缓冲区中的所有内容写入并同步到AOF文件。appendfsync everysec：将aof_buf缓冲区中的所有内容写入到AOF文件，如果上次同步AOF文件的时间距离现在超过1秒，那么两次对AOF文件进行同步，并且这个同步操作是由一个线程专门负责执行的。appendfsync no：将aof_buf缓冲区中的所有内容写入到AOF文件，但并不对AOF文件进行同步，何时同步由操作系统来决定。
关于AOF的同步策略是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：
为了提高文件写入效率，在现代操作系统中，当用户调用
write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。
这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。
AOF重写
AOF会记录每个Redis命令到AOF文件，随着时间越来越长，AOF文件会变得越来越大。如果不加以控制，会对Redis服务器，甚至对操作系统造成影响，而且AOF文件越大，数据恢复也越慢。
为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写功能来对AOF文件进行“瘦身”。Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。
RDB和AOF对比
关于RDB和AOF的优缺点，官网上面也给了比较详细的说明redis.io/topics/pers…
RDB
优点：
- RDB快照是一个压缩过的非常紧凑的文件，保存着某个时间点的数据集，适合做数据的备份，灾难恢复；
- 可以最大化Redis的的性能，在保存RDb文件，服务器进程只需要fork一个子进程来完成RDB文件的创建，父进程不需要做IO操作；
- 与AOF相比，恢复大数据集的时候会更快；
缺点：
- RDB的数据安全性是不如AOF的，保存整个数据集的过程是比繁重的，根据配置可能要几分钟才快照一次，如果服务器宕机，那么就可能丢失几分钟的数据；
- Redis数据集较大时，fork的子进程要完成快照会比较耗CPU、耗时；
AOF
优点：
- 数据更完整，安全性更高，秒级数据丢失（取决fsync策略，如果是everysec，最多丢失1秒的数据）；
- AOF文件是一个只进行追加的日志文件，且写入操作是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复；
缺点：
- 对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也会比较慢；
- 根据所使用的fsync策略，AOF的速度可能会慢于RDB。 不过在一般情况下，每秒fsync的性能依然非常高；
RDB和AOF如何选择
通常来说，应该同时使用两种持久化方案，以保证数据安全。
- 如果数据不敏感，且可以从其他地方重新生成，可以关闭持久化。
- 如果数据比较重要，且能够承受几分钟的数据丢失，比如缓存等，只需要使用RDB即可。
- 如果是用做内存数据，要使用Redis的持久化，建议是RDB和AOF都开启。
当RDB与AOF两种方式都开启时，Redis会优先使用AOF恢复数据，因为AOF保存的文件比RDB文件更完整。