Redis支持RDB和AOF两种持久化机制，持久化可有效避免因进程退出造成的数据丢失问题。
5.1 RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB过程分为手动触发和自动触发。
5.1.1 触发机制
手动触发分别对应save和bgsave命令：
- save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对内存较大的实例会造成长时间阻塞，线上不建议使用。
- bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段（fork是linux创建一个和原先进程几乎一样的子进程的函数），时间很短。
自动触发RDB
- 使用save命令，save m n。表示m秒内数据集存在n次修改时，自动触发bgsave
- 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件发送给从节点。
- 执行debug reload命令重新加载redis时，自动触发save
- 默认情况下执行shutdown命令时，如果没开启AOF持久化功能则自动执行bgsave
5.1.2 流程说明
bgsave是主流的触发RDB持久化方式
5.1.3 RDB文件的处理
保存：
RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可通过config set dir {new Dir} 和config set dbfilename {new FileName} 运行期动态执行，当下次运行RDB时文件会保存到新目录。
当遇到坏盘或磁盘满，就可以先用命令设置到新的持久化目录，再用bgsave运行持久化，同样适用于AOF持久化文件。
压缩：
Redis默认用LZF算法对RDB文件压缩处理，压缩后文件远小于内存大小，默认开启。
通过参数config set rdbcompression {yes|no} 动态修改。
5.1.4 RDB的优缺点
优点：
RDB是紧凑压缩的二进制文件，代表Redis在某时间点上的数据快照。适用于备份，全量复制等场景。例如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或文件系统(HDFS)中。
Redis加载RDB恢复数据远快于AOF的方式。
缺点：
没法做到实时持久化/秒级持久化。因为bgsave每次都执行fork操作创建子进程，属于重量级操作，成本太高。
RDB用特定二进制格式保存，Redis版本有多个格式的RDB，老版本Redis无法兼容新版本RDB格式。
针对RDB不适合实时持久化，Redis提供AOF方式
5.2 AOF
以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF主要为了解决数据持久化的实时性。
5.2.1 使用AOF
AOF设置配置：appendonly yes，默认不开启。
AOF文件名通过appendfilename配置设置，默认文件名appendonly.aof。
保存路径同RDB持久化方式一致，通过dir配置指定。
- 所有写入命令都追加到aof_buf中。
- aof_buf根据对应策略向磁盘做同步操作。
- 随着AOF文件越来越大，需定期对AOF文件重写，达到压缩目的。
5.2.2 命令写入
AOF 写入的内容直接是文本格式的。
- 使用文本协议的原因：文本协议具有很好的兼容性；避免了二次处理开销；文本协议具有可读性，方便直接修改。
- AOF为什么把命令追加到aof_buf中？ Redis用单线程响应命令，如果每次命令直接追加到硬盘，那性能完全取决于当前磁盘负载； 好处：Redis可提供多种缓冲区同步磁盘策略，在性能和安全作出平衡。
5.2.3 文件同步
提供多种AOF缓冲区同步文件策略，由参数appendfsync控制。不同的值有不同含义。
| 可配置值 | 说明 |
|---|---|
| always | 命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync完成线程返回 |
| everysec | 命令写入aof_buf后调用系统write操作，完成后线程返回。fsync同步文件由专门线程每秒调用一次 |
| no | 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步，同步磁盘系统负责。 |
write和fsync说明：
- write触发延迟写机制。write操作在写入系统缓冲区后直接返回。之后磁盘操作依赖操作系统。
- fsync针对单个文件操作，例如AOF文件，做强制磁盘同步，fsync将阻塞直到写入磁盘完成后返回，保证数据持久化。
参数说明：
- 配置为always，每次写入都要同步AOF文件，Redis只支持几百TPS写入，严重影响Redis性能，不建议配置。
- 配置为no，操作系统每次同步AOF文件周期不可控，提升了性能，但是数据安全性无法保证。
- 配置为everysec，是建议的同步策略，也是默认配置。理论上只有在系统突然宕机情况下丢失1秒数据。
5.2.4 重写机制
随着命令不断写入AOF，文件越来越大，Redis引入AOF重写机制压缩文件体积。
AOF文件重写是把Redis进程内的数据转化为命令同步到新AOF文件的过程。
重写后AOF文件为何变小？：
- 进程内已经超时数据不再写入文件
- 旧的AOF文件含有无效命令，例如del key1,hdel key2,set a111等。
- 多条写命令可以合并为一个，例如：lpush list a,lpush list b可以转为lpush list a b。可以合并命令：list,set,hash,zset等。
AOF重写降低文件占用空间，另外一个是更小AOF文件可更快被Redis加载。
AOF**手动和自动触发**：
- 手动触发：直接调用bgrewriteaof命令
- 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定触发时机。前者表示AOF重写时文件最小体积，默认64MB，后者表示当前AOF文件空间和上次重写后AOF文件空间的比值。
AOF重写流程
5.2.5 重启加载
AOF和RDB都渴用于服务器重启时的数据恢复。
5.2.6 文件校验
加载损坏AOF文件会拒绝启动。
对于错误格式AOF文件，先备份，再用redis-check-aof-fix命令进行修复，修复后用diff -u对于数据差异，找到丢失数据。
AOF可能存在结尾不完整情况。Redis提供aof-load-truncated配置。让Redis忽略该问题并继续启动。