存储在内存中的数据是比较容易丢失的，谁知道万一突然断电了，没有进行磁盘持久化的数据可就没了。考虑到这种情况，Redids提供了两种持久化的方式：RDB和AOF。
RDB持久化
RDB持久化是将某个时间点上的数据保存到一个RDB文件中。因为这个特性，RDB持久化也叫做快照持久化。
RDB文件是一个经过压缩的二进制文件，通过该文件可以还原Redis中的数据，但是会缺少生成RDB文件之后的数据。
RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。更适合做冷备。
优点
- 压缩后的二进制文，适用于备份、全量复制，用于灾难恢复加载RDB恢复数据远快于AOF方式，适合大规模的数据恢复。
- 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。数据恢复比AOF快。
缺点
- RDB是周期间隔性的快照文件，数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
- 备份时占用内存，因为 Redis 在备份时会独立fork一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍），最后再将临时文件替换之前的备份文件。所以要考虑到大概两倍的数据膨胀性。
注意手动触发及COW
- SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，导致无法提供服务。
- BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，在保存完成后向主进程发送信号告知完成。在BGSAVE 执行期间仍可以继续处理客户端的请求。
- Copy On Write 机制，备份的是开始时刻内存中的数据，只复制被修改内存页数据，不是全部内存数据。
- Copy On Write 时如果父子进程大量写操作会导致分页错误。
AOF持久化
AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销。有点像 Mysql 中的binlog。AOF更适合做热备。
优点 AOF是通过一秒一次的频率进行异步更新，不会像RDB那样丢失很多数据，最多丢失1s的数据。
缺点
- 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
- 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。
AOF流程
第一步：命令的实时写入，不同级别可能有1秒数据损失。命令先追加到aof_buf然后再同步到磁盘，如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。
第二步：对aof文件的重写，目的是为了减少AOF文件的大小，可以自动触发或者手动触发(BGREWRITEAOF)，Fork出子进程操作，期间Redis服务仍可用。
注意：
- 在重写期间，由于主进程依然在响应命令，为了保证最终备份的完整性；它依然会写入旧的AOF中，如果重写失败，能够保证数据不丢失。
- 为了把重写期间响应的写入信息也写入到新的文件中，因此也会为子进程保留一个buf，防止新写的file丢失数据。
- 重写是直接把当前内存的数据生成对应命令，并不需要读取老的AOF文件进行分析、命令合并。
- 无论是 RDB 还是 AOF 都是先写入一个临时文件，然后通过rename完成文件的替换工作。
关于Fork的建议
- 降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
- 控制Redis最大使用内存，防止fork耗时过长；
- 合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。
- Redis在执行BGSAVE和BGREWRITEAOF命令时，哈希表的负载因子>=5，而未执行这两个命令时>=1。目的是尽量减少写操作，避免不必要的内存写入操作。
- 哈希表的扩展因子：哈希表已保存节点数量 / 哈希表大小。因子决定了是否扩展哈希表。
恢复
- 启动时会先检查AOF(数据更完整)文件是否存在，如果不存在就尝试加载RDB。
- 既然单独用RDB会丢失很多数据。单独用AOF，数据恢复没RDB来的快，所以出现问题了第一时间用RDB恢复，然后AOF做数据补全。
