RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，即 Snapshot 快照，恢复时是将快照文件直接读到内存里。

Redis 会单独创建一个子进程（fork）来进行持久化。

先将数据写入到一个临时文件中，待持久化过程完成后，再将这个临时文件内容覆盖到 dump.rdb。

整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。

RDB 的缺点是最后一次持久化后的数据可能丢失。

Fork

作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
在 Linux 程序中，fork() 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 写时复制技术
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程

配置

dbfilename dump.rdb  dump #文件名字,默认为 dump.rdb,当redis启动时会在相对目录./生成（dir配置指定）

dir ./ #相关持久化文件生成位置

stop-writes-on-bgsave-error yes #即当 redis 无法写入磁盘，关闭 redis 的写入操作。

rdbcompression yes #持久化的文件是否进行压缩存储。

rdbchecksum yes #完整性的检查，即数据是否完整性、准确性。

save     #写操作在多少秒内写多久保存一次，格式：save 秒 写操作次数

优点

适合大规模的数据恢复；
对数据完整性和一致性要求不高更适合使用；
节省磁盘空间；
恢复速度快。

缺点

Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑；
虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；
在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。

AOF

以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis 启动之初会读取该文件重新构建数据，换言之，如果 Redis 重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

执行流程

客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；
AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 Rewrite 重写，压缩 AOF 文件容量；
Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

AOF 和 RDB 同时开启时，系统默认读取 AOF 的数据（数据不会存在丢失）

配置

appendonly on # AOF默认开启

appendfilename "appendonly.aof" # 文件名称，保存位置收到dir配置影响

appendfsync everysec # 同步频率设置
- always
始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好。
- everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
- no
Redis 不主动进行同步，把同步时机交给操作系统。