redis持久化之RDB和AOF的区别以及redis恢复数据

RDB是什么
1.Redis DataBase
2.内存快照：内存中的数据在某一个时刻的状态记录，某一时刻的状态以文件的形式写到磁盘上，也就是快照
3.恢复数据时可以把RDB文件直接读入内存，很快的完成恢复

AOF是什么
Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF 则是通过保存Redis服务器所执行的写命令来记录数据库状态。

宕机恢复最好的办法：混合使用 AOF 日志和内存快照

1.内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作

2.快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销

---

RDB持久化机制的工作流程，遍历一遍！！

（1）redis根据配置自己尝试去生成rdb快照文件

（2）fork一个子进程出来

（3）子进程尝试将数据dump到临时的rdb快照文件中

（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件dump.rdb，每次生成一个新的快照，都会覆盖之前的老快照

为了防止长时间经常备份，提供了一个配置参数。

支持周期性备份和多条件组发使用，达到条件就触发

---

aof演化过程

1.每一条命令都写入aof。这样的话会拖垮我的缓冲区，叫做aof_buf。但是随着时间的过去我的aof文件会越来越大，加载分析都非常耗时。

2.直接存储最后的指令状态，这样还是非常的浪费时间，那么我们就fork一个子进程出来重写，但是在重写期间会出现数据跟新的话就会出现数据不一致的问题

3.2的解决办法就是创建一个重写缓冲区

重写子进程那一刻起，所有来的命令都进入重写缓冲区，等我重写完再去读取重写缓冲区的内容，将aof_rewrite_buf的内容写入到新的aof文件中，最后再重命名新的文件用于替换旧文件。两个缓冲区交替使用，一个工作一个空闲！！！！！！！！！！！！！！

---

总结：rdb和aof的优缺点

RDB的优点

1.体积更小：相同的数据量rdb数据比aof的小，因为rdb是紧凑型文件

2.恢复更快：因为rdb是数据的快照，基本上就是数据的复制，不用重新读取再写入内存

3.性能更高:父进程在保存rdb时候只需要fork一个子进程，无需父进程的进行其他io操作，也保证了服务器的性能。

RDB的缺点

1.故障丢失:因为rdb是全量的，我们一般是使用shell脚本实现30分钟或者1小时或者每天对redis进行rdb备份，但是最少也要5分钟进行一次的备份，所以当服务死掉后，最少也要丢失5分钟的数据。

2.耐久性差:相对aof的异步策略来说，因为rdb的复制是全量的，即使是fork的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork的时间也会延长，导致cpu吃紧，耐久性相对较差。

aof的优点

1.数据保证：我们可以设置fsync策略，一般默认是everysec，也可以设置每次写入追加，所以即使服务死掉了，咱们也最多丢失一秒数据

2.自动缩小：当aof文件大小到达一定程度的时候，后台会自动的去执行aof重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的aof中，旧的就会被删除掉。但是此条如果拿出来对比rdb的话还是没有必要算成优点，只是官网显示成优点而已。

aof的缺点

1.性能相对较差：它的操作模式决定了它会对redis的性能有所损耗

2.体积相对更大：尽管是将aof文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。

3.恢复速度更慢

---