你知道redis的RDB和AOF持久化机制吗？

博主小白是一只正在努力学习开发的的“小猪猪”，昵称取自与动画片《猪猪侠》,以不轻易放弃,勇往直前的，乐观 积极的心态努力学习的人。本人正在学习java，主要喜欢自我收集有用资料，愿将所获和大家交流探讨，与大家一起进步，同时也希望对大家有所帮忙。现在，博主也想通过这种方式总结出各种知识点，文章有关的技术点的异常，错误，希望大家指点。

就拿我们在玩redis的时候，如果突然之间redis挂机了咋办，里面的缓存数据没了咋办，瞬间感觉整个人都不好了。还有在我们没有进行数据备份的时候，咱手有点欠，把redis重启了 。。。。 emm 数据这东西 唉！
在redis中有一种神奇的东西，持久化:RDB,AOF。那我和你们说呀，把这个东西安排舒服辽，那些什么问题都不是事。

1.我们先介绍一下RDB,AOF持久化是什么吧~~

(1).RDB持久化机制对redis数据是执行周期性的持久化。
(2).AOF机制对每条命令作为日志，以append-only的模式写入日志文件中，当我们重启redis的时候，可以去通过回放AOF日志中写入指令去重新构建整个的数据集。
还有一个咱可以通过RDB,AOF把在redis缓存中的数据持久化到磁盘上去，然后在biubiu备份到其他地方去。比如。阿里云呀。。。
这样的话就算redis挂机了，服务器上面内存，磁盘数据都没了，咱也不怕辽。可以把之前拷贝在云服务上面的数据，放到指定目录 重启redis 这样就整个人都好了呀
当然哈，咱牛逼不用RDB,AOF也是可以的，可以在***.conf把它们都禁用，这个呢 emmm 还是用得好。
还有一点，就比如我们把RDB，AOF两个同时使用，那redis持久化肯定是先用AOF来重构建数据呀，没为什么，就因为AOF中的数据更加完整。
还是不清楚没事，咱准备整个图让大家更理解一下吧

2.RDB的优点与缺点大总结

(1).RDB会生出多个数据文件，每个数据文件都代表了某一个时刻中redis的数据。
好处：非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去。
一：在redis故障时，想尽可能少丢失数据，那么EDB没有AOF好。RDB数据快照文件都是每隔5分钟或者更长时间生成，一旦redis进程宕机，就这5分钟数据拜拜辽。

(2).对redis的读写服务，影响非常非常小，可以让redis保持高性能。
why:因为redis主进程只需要fork一个子进程，让子进程执行IO操作来进行RDB持久化就可以。

二：RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据太大了，可能会导致对客服端提供的服务进行过长的等待。

(3).和AOF持久化来比，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

3.AOF持久化机制的优点，缺点大总结。

(1).AOF对数据的保护更好。一般AOF每隔一秒，在后台就会执行一次fsync操作，最多最多就一秒数据。
一：同一份数据AOF日志文件通常比RDB数据快照文件更大。
(2).写入性能非常高，AOF日志以append0only模式写入，所以根本不需要磁盘的开销，文件也不容易破损，即使文件尾部破损，也很容易修复
二:AOF开启后，支持写QPS(每一秒查询数据率)会比RDB支持写QPS低，因为AOF一般配置每一秒fuync一次日志文件。
(3).在AOF日志文件过大的时候，会在后台进行重写操作，不会影响客户端读写。
因为在rewrite log的时候，会对其进行压缩，在创建一份需要恢复的最小日志出来，再创建日志文件的时候，老的日志文件当然还是会写入的。当新的merge后的日志文件ready的时候，在交换新老日志文件就o了。
(4).AOF的日志文件是通过非常可读方法进行记录的，这个特性非常适合灾难性的误删除的紧急恢复。
例如:咱不小心用flushall命令清空了所以数据，只要这个时候后台rewrite还没有发生，那么就可以立刻拷贝AOF文件，把最后一条flushall命令删了，在将该AOF文件放回去，就可以通过恢复机制。自动恢复啦。

让我们来看看rewrite的原理

4,那么RDB与AOF我们到底用哪一种呢？？？

嘿嘿嘿 我们为什么要有这种问题呢，两种一起用它不香吗 是不是 咱来说说为什么啦。
1.单独使用RDB，可能会导致数据丢失很多哟。
2.单独使用AOF，RDB冷备比AOF冷备牛逼，别问 问就是恢复速度更加快速。RDB生成数据快照，更好顶，同时也可以避免AOF复杂的备份好恢复机制bug。
3.一起用男女搭配干活不累一样的啦。
用AOF保证数据不丢失，数据恢复第一选择。用RDB来做不同程度的冷备，在AOD文件都丢失或者损坏不可用的时候，还可以使用RD进行快速数据恢复。

大家好我是小猪猪侠期待你的关注 点赞 转发。