（一）RDB快照
在默认情况下，Redis将内存数据快照保存在名字为dump.rdb的二进制文件中
可以对Redis进行设置，让它在 N秒内数据集至少有M个改动 这一条件被满足时，自动保存一次数据集
例如：
以下设置会让Redis在满足 60秒内至少有1000个键被改动 这一条件 自动保存一次数据集
# save 60 1000 //关闭RDB只需要将所有的save 保存策略注释掉即可
可以手动执行命令生成RDB快照，进入redis客户端执行命令save 或 bgsave 可以生成dump.rdb文件
每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件
bgsave 的写时复制机制
Redis借助操作系统提供的写时复制技术(Copy-On-Write,COW),在生成快照的同时，依然可以正常处理写命令。
简单来说，bgsave子进程是由主线程fork生成的，可以共享主线程的所有内存数据
bgsave子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件。
此时，如果主线程对这些数据也都是读操作，那么，主线程和bgsave子进程相互不影响。
但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。
然后，bgsave子进程会把这个副本数据写入RDB文件，而在这个过程中，主线程仍然可以直接修改原来的数据
配置自动生成rdb文件后台使用的是bdsave方式
（二） AOF (append-only file)
快照功能并不是非常耐久(durable) : 如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入，且仍未保存到快照中的那些数据。
从1.1 版本开始，Redis 增加了一种完全耐久的持久化方式：AOF持久化，将修改的每一条指令记录进文件appendonly.aof中（先写入os cache,每隔一段时间fsync到磁盘）
这是一种resp协议格式数据，星号后面的数字代表命令有多少个参数，$号后面的数字代表这个参数有几个字符
注意，如果执行带过期时间的set命令，aof文件里记录的并不是执行的原始命令，
而是记录key过期的时间戳
你可以通过修改配置文件来打开AOF功能
# appendonly yes
从现在开始，每当Redis执行一个改变数据集的命令时（比如set）,这个命令就会被追加到AOF文件的末尾
这样的话，当Redis重新启动时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的
你可以配置Redis多久才将数据fsync到磁盘一次
有三个选项
推荐（并且也是默认）的措施为每秒fsync一次，这种fsync一次，这种fsync策略可以兼顾速度和安全性。
（三） AOF重写
AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据生成aof文件
重写后AOF文件里变成
当然AOF还可以手动重写，进入redis客户端执行命令bgrewriteaof重写AOF
注意，AOF重写redis会fork 出一个子进程去做（与bdsave命令类似），不会对redis正常命令处理有太多影响
生活真是充满希望那！！！！！！！！！
奥里给