RDB
概念
RDB持久化是 父进程 fork 一个子进程。子进程创建RDB文件，将父进程内存某一时刻数据复制保存到临时快照文件，即 Snapshot 快照存储，完成后将原有RDB文件进行原子替换。
优点
- 子进程进行持久化，避免服务进程进行IO操作。
- 写时复制技术，RDB持久化过程中，有写操作到父进程，子进程会复制一份父进程内存数据执行持久化
- 恢复数据速度快，特别适合数据量大的情况。性能好
- 灾难恢复，进行冷备份。推荐将RDB文件转移到其他储存介质，比如Amazon的S3、阿里云的OSS
- 灵活的设置备份频率和周期，适合全量复制的场景
缺点
-
因为持久化时间相对长，在服务器发生故障时，持久化过程中丢失的数据会比AOF的方式更多，因此数据的高可用性低。
-
RDB无法做到实时存储/秒级存储，而且需要通过fork创建子进程，属于重量级操作。
AOF
概念
实时持久化
以日志的形式追加记录服务器所处理的每个写操作、删除操作。在日志追加写入完成之后才会进程内存数据的实际更新。查询操作不会记录，以文本的方式记录。当 Redis 重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
工作流程：命令写入到缓冲区、缓冲区的数据同步到磁盘、对磁盘的AOF文件定期重写，重启加载AOF文件进行数据恢复
优点
- 数据追加到文件毫秒级别，异步执行，所以数据安全性高，不会因为宕机丢失太多数据
- 当文件过大时还会自动进行命令的合并执行，例如删除某些不必要的命令。
缺点
- 对于相同数量的数据集而言，AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
如何选择
-
不要仅仅使用 RDB，因为那样会导致你丢失很多数据。
-
也不要仅仅使用 AOF，因为那样有两个问题，第一，你通过 AOF 做冷备，没有 RDB 做冷备，来的恢复速度更快; 第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug 。
-
Redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
-
如果同时使用 RDB 和 AOF 两种持久化机制，那么在 Redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。
