由于resid的内存数据库虽然访问速度快，但是由于服务宕机或服务退出，数据将会丢失
1. RDB创建
EDB持久haul所需持久化生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成的RDB文件时的数据库状态；SAVE和BGSAVE命令可以用于生成RDB文件；RDB方式的持久化是通过快照完成的，当符合一定条件时redis会自动将内存中的所有数据进行快照并存储在硬盘上，
RDB优点：
- RDB是一个非常紧凑的文件，他保存了某个时间点的数据，非常适用于数据的备份，可以很方便传送到另一个远端数据中心，非常适用于灾难恢复，
- RDB在保存RDB文件时父进程唯一需要的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他的io操作，所以RDB持久化方式可以最大化redis的性能
- 与AOF相比在恢复大的数据集的时候，RDB方式会更快一些
缺点：
redis意外宕机，会丢失部分数据
当redis数据量比较大时，fork的过程是非常耗时的，fork的过程是阻塞的，在这期间redis是不能响应客户端的请求得，
RDB文件的致命缺点是其数据快照的持久化方式决定了必然做不到事实持久化，而在数据越来重要的今天，数据的大量丢失很多时候是无法忍受的，因此AOF持久化成为主流此外，RDB文件需要满足特定格式，兼容性差
2 AOF持久化
AOF持久化是通过保存redis服务器所执行的写命令来记录数据库状态，也就是当redis执行一个改变数据集的命令时，比如（set）这个命令就会被追加到AOF文件末尾、
开启AOF：修改redis.conf配置文件，默认appendonly no 关闭状态， 改为appendonly yes
AOF持久化执行流程
- 命令追加(append);将redis的写命令追加到缓冲区aof_buf
- 文件写入（write）和文件同步：根据不同的同步策略将aof_buf中的内容同步到硬盘
- 文件重写：定期重写AOF达到压缩的目的
append追加命令：
redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写入命令都直接写入硬盘，导致硬盘IO成为redis的瓶颈
命令追加的格式是redis命令请求得协议格式，他是一种纯文本格式，具有兼容性好，可读性强，容易处理，操作简单避免二次开销等优点，在AOF文件中，除了用于指定数据库的select命令，是有redis添加的其他都是客户端发送过来的命令
AOF优缺点：
支持秒级的持久化
可用于不同版本的redis服务器，兼容性强
AOF文件刻度性高，分析容易
缺点：文件大，恢复速度慢，对性能影响大
3. 持久化策略选择
持久化开启都是要付出性能方面的代价的：对于RDB持久化，一方面是bgsave操作时redis主进程会阻塞，另一方，子进程向硬盘写数据也会带来IO压力，对于AOF向硬盘写数据的频率大大提高了IO压力，甚至可能造成AOF追加阻塞
选择建议：
如果redis中的数据丢失没有影响（redis作用于数据库的缓存）那么无论是单机还是主从架构，都是可以不进行持久化的
在单机情况下，（对于个人开发者，这种情况可能比较常见）如果可以接受十分钟或者更多的数据丢失选择RDB对redis的性能更加有利；如果只能接受秒级的数据丢失，应该选择AOF
在多数情况下。我们都会配置主从环境，slave的存在既可以实现数据的热备，也可以进行读写分离分担redis的读请求以及在master宕掉后继续提供服务
异地灾备：上述讨论的几种持久化策略，针对的都是一般的系统故障，如进程异常退出，宕机，断电，这些故障不会损坏硬盘，但是对于一些可能导致硬盘损坏的灾难情况，如火灾地震，就需要进行异地灾备
