ToB企服应用市场:ToB评测及商务社交产业平台

标题: 【Java面试】RDB 和 AOF 的实现原理、优缺点 [打印本页]

作者: 铁佛 时间: 2022-8-20 21:38
标题: 【Java面试】RDB 和 AOF 的实现原理、优缺点

Hi，大家好，我是Mic。
一个工作了5年的粉丝私信我，最近面试碰到很多Redis相关的问题。
其中一个面试官问他Redis里面的持久化机制，没有回答得很好。
希望我帮他系统回答一下。
关于Redis里面的RDB和AOF两种持久化机制的原理和优缺点这个问题。
下面看看普通人和高手的回答。

普通人：

RDB是一种快照的方式然后AOF是一种就是指令追加的方式。
它们两个都是Redis里面的一种数据持久化的一个机制。
RDB它是快照嘛，快照的话它的那个时间间隔它会有一个配置但是这种配置过程中就是有可能会导致说我的数据丢失的一个问题。
但是AOF它是那种就是追加的方式嘛，所以它的一个数据安全性可能会比RDB会好一点。
高手：

好的，关于这个问题，我从几个点来回答。
首先，Redis本身是一个基于Key-Value结构的内存数据库，为了避免Redis故障导致数据丢失的问题，所以提供了RDB和AOF两种持久化机制。
RDB是通过快照的方式来实现持久化的，也就是说会根据快照的触发条件，把内存里面的数据快照写入到磁盘，
以二进制的压缩文件进行存储。

RDB快照的触发方式有很多，比如

执行bgsave命令触发异步快照，执行save命令触发同步快照，同步快照会阻塞客户端的执行指令。
根据redis.conf文件里面的配置，自动触发bgsave
主从复制的时候触发

AOF持久化，它是一种近乎实时的方式，把Redis Server执行的事务命令进行追加存储。简单来说，
就是客户端执行一个数据变更的操作，Redis Server就会把这个命令追加到aof缓冲区的末尾，
然后再把缓冲区的数据写入到磁盘的AOF文件里面，至于最终什么时候真正持久化到磁盘，是根据刷盘的策略来决定的。

另外，因为AOF这种指令追加的方式，会造成AOF文件过大，带来明显的IO性能问题，所以Redis针对这种情况提供了
AOF重写机制，也就是说当AOF文件的大小达到某个阈值的时候，就会把这个文件里面相同的指令进行压缩。

因此，基于对RDB和AOF的工作原理的理解，我认为RDB和AOF的优缺点有两个。

RDB是每隔一段时间触发持久化，因此数据安全性低，AOF可以做到实时持久化，数据安全性较高
RDB文件默认采用压缩的方式持久化，AOF存储的是执行指令，所以RDB在数据恢复的时候性能比AOF要好

在我看来，所谓优缺点，本质上其实是哪种方案更适合当前的应用场景而已。
以上就是我对这个问题的理解！
总结

这个问题的实际意义在于，求职者要知道在什么场景下选择什么样的持久化策略。
因此如果能够对AOF和RDB这两种持久化方式有比较深入的理解，
那自然也就能够在实际开发中合理的进行应用了。
喜欢我作品的小伙伴，记得点赞收藏加关注。

版权声明：本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Mic带你学架构！
如果本篇文章对您有帮助，还请帮忙点个关注和赞，您的坚持是我不断创作的动力。欢迎关注「跟着Mic学架构」公众号公众号获取更多技术干货！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)