共计 1228 个字符，预计需要花费 4 分钟才能阅读完成。
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 带你学架构！
如果本篇文章对您有帮忙，还请帮忙点个关注和赞，您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货！
