阿里JAVA面试题剖析：Redis 的持久化有哪几种方式？不一样的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？

面试原题

redis 的持久化有哪几种方式？不一样的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？

面试官心理分析

redis 若是仅仅只是将数据缓存在内存里面，若是 redis 宕机了再重启，内存里的数据就所有都弄丢了啊。你必须得用 redis 的持久化机制，将数据写入内存的同时，异步的慢慢的将数据写入磁盘文件里，进行持久化。

若是 redis 宕机重启，自动从磁盘上加载以前持久化的一些数据就能够了，也许会丢失少量数据，可是至少不会将全部数据都弄丢。

这个其实同样，针对的都是 redis 的生产环境可能遇到的一些问题，就是 redis 要是挂了再重启，内存里的数据不就全丢了？能不能重启的时候把数据给恢复了？

面试题剖析

持久化主要是作灾难恢复、数据恢复，也能够归类到高可用的一个环节中去，好比你 redis 整个挂了，而后 redis 就不可用了，你要作的事情就是让 redis 变得可用，尽快变得可用。

重启 redis，尽快让它堆外提供服务，若是没作数据备份，这时候 redis 启动了，也不可用啊，数据都没了。

极可能说，大量的请求过来，缓存所有没法命中，在 redis 里根本找不到数据，这个时候就死定了，出现缓存雪崩问题。全部请求没有在 redis 命中，就会去 mysql 数据库这种数据源头中去找，一会儿 mysql 承接高并发，而后就挂了...

若是你把 redis 持久化作好，备份和恢复方案作到企业级的程度，那么即便你的 redis 故障了，也能够经过备份数据，快速恢复，一旦恢复当即对外提供服务。

redis 持久化的两种方式

RDB：RDB 持久化机制，是对 redis 中的数据执行周期性的持久化。

AOF：AOF 机制对每条写入命令做为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，能够经过回放 AOF 日志中的写入指令来从新构建整个数据集。

经过 RDB 或 AOF，均可以将 redis 内存中的数据给持久化到磁盘上面来，而后能够将这些数据备份到别的地方去，好比说阿里云等云服务。

若是 redis 挂了，服务器上的内存和磁盘上的数据都丢了，能够从云服务上拷贝回来以前的数据，放到指定的目录中，而后从新启动 redis，redis 就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。

若是同时使用 RDB 和 AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来从新构建数据，由于 AOF 中的数据更加完整。

RDB 优缺点

RDB会生成多个数据文件，每一个数据文件都表明了某一个时刻中 redis 的数据，这种多个数据文件的方式，很是适合作冷备，能够将这种完整的数据文件发送到一些远程的安全存储上去，好比说 Amazon 的 S3 云服务上去，在国内能够是阿里云的 ODPS 分布式存储上，以预约好的备份策略来按期备份redis中的数据。

RDB 对 redis 对外提供的读写服务，影响很是小，可让 redis 保持高性能，由于 redis 主进程只须要 fork 一个子进程，让子进程执行磁盘 IO 操做来进行 RDB 持久化便可。

相对于 AOF 持久化机制来讲，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。

若是想要在 redis 故障时，尽量少的丢失数据，那么 RDB 没有 AOF 好。通常来讲，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。

RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，若是数据文件特别大，可能会致使对客户端提供的服务暂停数毫秒，或者甚至数秒。

AOF 优缺点

AOF 能够更好的保护数据不丢失，通常 AOF 会每隔 1 秒，经过一个后台线程执行一次fsync操做，最多丢失 1 秒钟的数据。

AOF 日志文件以 append-only 模式写入，因此没有任何磁盘寻址的开销，写入性能很是高，并且文件不容易破损，即便文件尾部破损，也很容易修复。

AOF 日志文件即便过大的时候，出现后台重写操做，也不会影响客户端的读写。由于在 rewrite log 的时候，会对其中的指导进行压缩，建立出一份须要恢复数据的最小日志出来。再建立新日志文件的时候，老的日志文件仍是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件便可。

AOF 日志文件的命令经过很是可读的方式进行记录，这个特性很是适合作灾难性的误删除的紧急恢复。好比某人不当心用 flushall 命令清空了全部数据，只要这个时候后台 rewrite 尚未发生，那么就能够当即拷贝 AOF 文件，将最后一条 flushall 命令给删了，而后再将该 AOF 文件放回去，就能够经过恢复机制，自动恢复全部数据。

对于同一份数据来讲，AOF 日志文件一般比 RDB 数据快照文件更大。

AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低，由于 AOF 通常会配置成每秒 fsync 一第二天志文件，固然，每秒一次 fsync，性能也仍是很高的。（若是实时写入，那么 QPS 会大降，redis 性能会大大下降）

之前 AOF 发生过 bug，就是经过 AOF 记录的日志，进行数据恢复的时候，没有恢复如出一辙的数据出来。因此说，相似 AOF 这种较为复杂的基于命令日志/merge/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。不过 AOF 就是为了不 rewrite 过程致使的 bug，所以每次 rewrite 并非基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的从新构建，这样健壮性会好不少。

RDB和AOF到底该如何选择

不要仅仅使用 RDB，由于那样会致使你丢失不少数据；

也不要仅仅使用 AOF，由于那样有两个问题：第一，你经过 AOF 作冷备，没有 RDB 作冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，能够避免 AOF 这种复杂的备份和恢复机制的 bug；

redis 支持同时开启开启两种持久化方式，咱们能够综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，做为数据恢复的第一选择; 用 RDB 来作不一样程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可使用 RDB 来进行快速的数据恢复。

---

本文的重点是你有没有收获与成长，其他的都不重要，但愿读者们能谨记这一点。同时我通过多年的收藏目前也算收集到了一套完整的学习资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、Jvm性能调优、Spring，MyBatis，Nginx源码分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多个知识点高级进阶干货，但愿对想成为架构师的朋友有必定的参考和帮助

须要更详细架构师技能思惟导图和如下资料的能够加一下技术交流分享群：“708 701 457”免费获取