redis中持久化机制有两种方法，分别是AOF(Append Only File)与RDB.
一、RDB 将内存中的快照保存到文件。
1. RDB触发条件分为自动触发与手动触发。
- 自动触发：触发条件可以通过redis.conf 配置文件中的 SNAPSHOTTING 下配置：
默认配置如下：
save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
- 手动触发：save：阻塞命令，客户端无法进行命令操作 。bgsave：（非阻塞，子进程执行保存操作）
2. 恢复数据：
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。
3. RDB优势与劣势
优势：
- RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
- 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
劣势：
- RDB无法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)
- 存在版本兼容问题：RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)
- 对应1，数据丢失风险. 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)
二、AOF 命令追加到文件。
1. 开启aof
将 redis.conf 的 appendonly 配置改为 yes 即可。
AOF 保存文件的位置和 RDB 保存文件的位置一样，都是通过 redis.conf 配置文件的 dir 配置：
2. aof持久化策略。
在配置文件中，aof提供了三种持久化策略。可以通过对appendfsync字段配置：aof持久化策略的配置；
- no:表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
- always:表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
- everysec:表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。
3.aof文件恢复
重启 Redis 之后就会进行 AOF 文件的载入。
异常修复命令：redis-check-aof --fix 进行修复
4.aof文件重写
aof文件重写触发条件是通过配置文件的配置或者手工触发重写两种方式。
配置参数：
auto-aof-rewrite-percentage：默认值为100
auto-aof-rewrite-min-size：默认值为64mb
默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
注：AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
no-appendfsync-on-rewrite:设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。
redis aof重写是通过fork子进程的方式，子进程在进行aof重写期间父进程是可以处理客户端的命令操作，为了解决子进程重写期间，客户端向服务器执行了新的命令请求导致子进程与父进程的状态不一致的问题，redis增加了aof重写缓冲区，即在aof forkzi进程期间，服务器在写客户端命令期间也会向重写缓冲区写命令，待子进程完成aof重写，通知父进程，父进程阻塞客户端命令，将重写缓冲区中的内容写入到aof文件。