1 、概述
redis是一种noslq(not only sql)，那么他必定需要持久化，AOF和RDB就是redis持久化的两种方式。
2、RDB
2、1 什么是RDB？
在指定的时间间隔内将内存中的数据集快照写入到磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读取到内存中。
Redis会单独创建(fork)一个子进程进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程中，主进程是不尽兴任何IO操作的，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化后的数据可能会丢失。
RDB会保存一个dump.rdb的文件
2、2 Fork
fork的作用是复制一个与当前进程一样的进程，新进程的所有数据(变量、环境变量，程序计数器等)数值都和源进程一致，但是是一个全新的进程，并作为源进程的子进程
2、3 怎么触发
appendonly yes
我们可以在redis的配置文件位置中更改相关的配置。
- save：使用save命令之后，只管保存，其他不管，其他命令直接进入阻塞状态
- BGsava：redis会在后台异步进行快照操作，快照的同时还可以响应客户端请求，可以通过lastsave命令获取最后一次访问成功执行快照的时间
- 执行FLUSHALL命令，也会产生dump.rdb文件，但是里面是空的，没有意义
2、4 RDB的恢复
将备份文件(dump.rdb)移动到redis的安装目录并启动服务即可
使用CONFIG GET dir获取目录
2、5 优势
- 如果要进行大规模的数据恢复，RDB的方式要比AOF恢复的方式要快
- RDB可以最大化redis性能，父进程做的就是fork子进程，然后继续接受客户端请求，让子进程负责持久化操作，父进程无需进行io操作
- RDB是一个非常紧凑（compact）的文件，它保存了某个时间点的数据集，非常适合用作备份，同时也肥肠粉适合用作灾难性恢复，他只有一个文件，内容紧凑，通过备份源文件到本机外的其他主机上，一旦本机出现宕机，就能将被备份文件复制到redis的安装目录下，通过启动服务来完成数据的恢复。
2、6劣势
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照的所有修改
- fork的时候，内存中的数据被克隆了一份，大致2被的膨胀性需要考虑
2、7 停止
动态所有停止RDB保存规则的方法：redis-cli config set save “”
3、AOF
3、1 AOF是什么?
以日志的形式来记录每个写操作，将redis执行过的所有指令记录写下来(读操作不记录)，只允许追加文件不可以该写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF保存的文件格式是appendonly.aof文件
持久化操作
Redis的AOF操作是如何做到持久化呢？
从配置文件中我们可以发现
appendfsync always：每修改异步，每一次发生数据变更都会持久化到磁盘上，性能较差，但是数据完整性比较好
appendfsync everysec：每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失
appednfsync no：不同步。
3、2 AOF的启动/恢复/修复
正常恢复：
- 修改默认的appendonly no 改为yes
- 将有数据的aof文件复制一份保存到对应的目录
- 启动redis然后重新加载
异常恢复： - 修改默认的appendonly no 改为yes
- 备份被改写坏的AOF文件
- 调用redis-check-aof --fix命令进行修复(会自动删除掉不合法的指令)
- 重启redis然后重新加载
3、3 rewrite重写AOF文件
3、3、1 概述
AOF采用了文件追加的方式，文件会越来越大，为避免这种情况出现，新增重写机制，当AOF文件的带下超过设定的阈值的时候，redis就会启动AOF文件的内容压缩，只保留可以回复数据的最小指令集，可以使用命令bgrewriteaof
3、3、2 重写的原理
AOF比RDB文件更大，并且在存储命令的过程中增长更快，为了压缩AOF的持久化文件，redis提供了重写机制以此来实现控制AOF文件的增长，AOF重写实现的理论基础的是这样的
1、执行set hello world 50次
2、最后执行一次 set hello china
3、对于aof文件而言，前面的50次set都是没有意义的，AOF重写就是将key只保存最后的状态。
关于重写期间的数据一致性的问题
子进程在进行AOF重写期间，主进程还需要继续处理命令，而新的命令可能对现有的数据进行修改，会出现数据库的数据和重写后的aof文件中的数据不一致的情况，因此，redis增加了一个AOF重写缓存，除了会讲这个写命令的协议内容追加到现有的aof文件之外，还会追加到这个缓存中。
AOF文件覆盖
当子进程完成AOF重写之后会向父进程发送一个完成信号，父进程在接收到到完成信号之后会调用信号处理函数，完成以下工作：
将AOF重写缓存中的内容全部写入到新AOF文件中对新的AOF文件进行改名，覆盖原油的AOF文件
AOF重写的阻塞性
整个 AOF 后台重写过程中只有最后写入缓存和改名操作会造成主进程阻塞， 在其他时候AOF 后台重写都不会对主进程造成阻塞， 将 AOF 重写对性能造成的影响降到了最低
服务器在AOF功能开启的情况下，会维持一下三个变量
1、当前AOF的文件大小
2、最后一次重写之后，AOF文件大小的变量
3、AOF文件增长的百分比
每次当serverCron函数执行的时候，他都会检查以下条件是否全部满足，如果是的话，就会触发自动的AOF重写
1、没有BGSAVE的命令在进行，让是与RDB的冲突
2、没有BGREWRITEAOF在进行，方式与手动的AOF冲突
3、AOF文件大小至少大于设定值基本要求，大小没有意义
4、当前AOF文件大小和最后一次AOF重写后的大小之间的比率大于等于指定的增长百分比
redis会记录上次重写时AOF的大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍，且大于64M的时候触发。
3、4 优势
- 每修改同步：appendfsync always 同步持久化每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
- 每秒同步：appendfsync everyec异步操作，每秒记录，如果一秒内宕机，有数据丢失
- 不同步：appendfsync no 从不同步
3、5 劣势
- 相同数据集的数据而言，文件要远大于rdb文件，速度慢于rdb
- aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
4、 用哪一个？
简单的回顾一下优缺点
RBD：rdb持久化的方式能够在指定时间间隔对你的数据进行快照存储
AOF:AOF的持久化方式记录每次服务器写的操作，当服务器重启的时候会重新执行这些命令才回复原始的数据，AOF命令以redis协议的追加到保存每次写操作的文件末尾，redis还能对AOF文件进行后台的重写，使得AOF文件的提及不至于过大。
同样的我们在实践中知道，如果同时开启了AOF和RDB那么我们的redis会默认选择使用AOF。
只做缓存：如果我们只希望数据在服务器运行的候存在，你也可以不是用任何持久化的方式。
一般来说
- 如果我们想达到足以媲美PostgreSQL 的数据安全性，我们应该同时使用两种持久化功能
- 如果你非常关心数据，但是仍然能够接受几分钟内的数据丢失，那么你可以只使用RDB进行持久化，有很多用户都是只是用AOF持久化，但是我们并不推荐这种方式，因为定时生成RDB快照的方式非常便于数据备份。同样RDB的速度也比AOF要更快，除此之外，RDB还能避免出现AOF中的bug
- 我们希望在将来出现一个结合了AOF和RDB的单个持久化模型