Redis 除了将数据存储到内存上外，还支持持久化操作，有效地避免因进程退出造成数据丢失问题， 当下次重启时利用之前持久化的文件即可实现数据恢复。
redis 支持 RDB 和 AOF 两种持久化机制。
1，RDB机制
RDB 持久化是定期把 Redis 内存数据写入硬盘，生成一个 "快照"（"快照"是将当前数据存储到生成的RDB文件中），后续 Redis 一旦重启了，就可以根据 "快照" 把内存中的数据恢复过来。
RDB触发方式有两种：手动触发 和自动触发。
手动触发：通过 redis 客户端，执行 save（阻塞）或 bgsave（后台异步）触发。save 指令是阻塞指令，一般不怎么使用；bgsave 是非阻塞指令，底层使用的是多进程方式完成并发编程。Redis 生成快照，本质上是在硬盘中单独存储一份数据，多进程保证数据安全，资源独立，不涉及多线程安全，更适合作为底层机制。
自动触发：在 Redis 配置文件（redis.conf）中设置，让 Redis 每隔一段时间后就触发。
当生成 rdb 镜像操作时，此时会把将要生成的快照数据先保存到一个临时文件中，当这个快照生成完毕（临时文件写入完成），再删除之前的 rdb 文件，将临时文件重命名为配置中指定的名称（配置文件中 dbfilename 字段）。
redis生成的rdb文件存放在配置文件下的 dir 设置的目录里。后续 redis 重启就会加载这个 rdb文件。若系统加载时，rdb 文件遭到破坏，那么此时 redis 服务器就无法启动。
自动触发是在配置文件中设置 save 字段。save 字段用于定义触发快照的条件，即当满足 "指定时间内发生指定数量的写操作" 时，Redis 自动执行 bgsave，将内存中的数据以二进制形式写入磁盘。
save <seconds> <changes>
<seconds>：时间窗口（单位：秒）；<changes>：该时间窗口内的写操作（增 / 删 / 改）数量阈值；- 可以配置多个
save规则，满足任意一个即触发 RDB 快照。例如：save 900 1 表示：900秒（15分钟）内至少1个键被修改，即当900秒后系统检测到至少有一个键被修改了，就会触发 bgsave。
注意：若写成 save "" ，表示关闭自动生成快照
2，AOF机制
AOF说明
AOF是 Redis 另一种核心持久化机制，与 RDB（快照式）不同，AOF 通过记录所有修改数据的命令（以文本协议格式）来实现数据持久化。AFO 以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。相比 RDB 机制，AOF 是目前主流的方式。
Redis 执行完写命令（如 SET/HSET/INCR 等）后，将命令以 Redis 通信协议（RESP）格式追加到内存中的 AOF 缓冲区（避免直接写磁盘导致频繁 I/O）；然后根据 redis 配置的刷新策略，将缓冲区内容写入 AOF 文件，重启时重新执行这些命令即可恢复数据。
AOF的使用
开启 AOF 功能需要设置配置文件：appendonly yes。默认情况下是不开启的。AOF 文件名通过 appendfilename 配置（默认是 appendonly.aof）设置。保存目录同 RDB 持久化方式一致，通过 dir 配置指定。
Redis 提供了多种 AOF 缓冲区同步文件策略（刷新缓冲区），由配置文件中参数 appendfsync 控制，参数如下：
重写机制
随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入 AOF 重写机制压缩文件体积。AOF 文件重写是 Redis 通过重写机制生成一个 "精简版" 的 AOF 文件（只保留恢复数据的必要命令），替代旧文件。这个 "精简版" AOF文件去除其中沉余的操作，即删除旧的 AOF中的无效命令，例如：del、hdel、srem等重写后将会删除，只需要保留数据的最终版本，即多条写操作合并为一条，例如 lpush list a、lpush list b、lpush list 从可以合并为 lpush list a b c。
较小的 AOF 文件一方面降低了硬盘空间占用，一方面可以提升启动 Redis 时数据恢复的速度。
AOF重写过程可以手动触发和自动触发。
- 手动触发：调用 bgrewriteaof 命令（非阻塞）。
- 自动触发：根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时 机。auto-aof-rewrite-min-size：表示触发重写时 AOF 的最小文件大小，默认为 64MB；auto-aof-rewrite-percentage：代表当前 AOF 占用大小相比较上次重写时增加的比例，即：(当前AOF大小 - 上次重写后AOF大小) / 上次重写后AOF大小 × 100% ，默认 100，也就是100%。只有当这个 "增长比例 ≥ 配置值"，且满足
auto-aof-rewrite-min-size的大小门槛时，才会触发自动重写，若 AOF 文件没达到 auto-aof-rewrite-min-size 值，哪怕满足其他重写条件，也不会触发自动重写。
# 触发重写的最小 AOF 文件大小（低于此值不触发，默认 64MB）
auto-aof-rewrite-min-size 64mb
# 触发重写的文件增长率（默认 100%）
# 公式：当前 AOF 文件大小 > 上一次重写后的大小 × (100% + 百分比值)
auto-aof-rewrite-percentage 100
样例说明：
第一次重写：AOF 文件从 0 增长到 64MB（达到
auto-aof-rewrite-min-size），触发重写；第二次重写：上一次重写后文件大小为 64MB，当文件增长到 128MB（64×2）时，触发重写；
AOF重写流程
首先，主进程会创建子进程，子进程负责重写。重写时，子进程把内存中当前的数据获取出来，以AOF格式写入到一个新的AOF中。内存中的数据状态，就相当于 AOF文件结果整理后的模样了。此时，子进程写入新的 AOF 文件时，若父进程仍然在不停的接收客户端新的请求，即子进程在重写时，内存数据发生变化，子进程这里会通过信号通知父进程，父进程再将这些新请求产生的 AOF 数据写入到缓冲区，然后再刷新到新的 AOF 文件中。最后用新的 AOF文件替换老的 AOF文件。
混合持久化
RDB 是以二进制形式写入文件，AOF 是以文本格式写入文件，也就是说相同数据量下，RDB 文件体积远小于 AOF 文件，RDB 持久化过程在性能方面开销低，但是RDB持久化数据丢失风险高。RDB 是 "间隔性快照"，只有触发快照时才写磁盘，未触发时修改仅停留在内存；若在写入期间出现任何意外，那么将会导致数据丢失。
生产环境中，通常不会单单使用 RDB 或 AOF，而是 AOF 和 RDB 的混合使用。
aof-use-rdb-preamble yes； // 表示使用混合持久化，no表示不使用
redis的混合使用，结合了两个的优点进行改进。混合使用按照 aof文件的方式，每一个操作都会记录入文件。在触发 aof 重写后，就会把当前内存的状态按照 rdb 的二进制格式写入到新的 aof 文件中。后续再进行的操作仍然是按照 aof 文本的方式追加到文件后面。
若 redis上同时存在 aof 文件和 rdb 快照时，此时会以 aof 为主，rdb 就直接被忽视了。