对线面试官 -Redis 九 | 持久化的方式及优缺点

面试官：Redis 持久化有了解吗？可以聊一聊吗？

面试官心理分析：redis 如果仅仅只是将数据缓存在内存里面，如果 redis 宕机了再重启，内存里的数据就全部都弄丢了啊。你必须得用 redis 的持久化机制，将数据写入内存的同时，异步的慢慢的将数据写入磁盘文件里，进行持久化。如果 redis 宕机重启，自动从磁盘上加载之前持久化的一些数据就可以了，也许会丢失少许数据，但是至少不会将所有数据都弄丢。这个其实一样，针对的都是 redis 的生产环境可能遇到的一些问题，就是 redis 要是挂了再重启，内存里的数据不就全丢了？能不能重启的时候把数据给恢复了？

派大星：可以的，Redis 持久化分为两种：

• RDB 持久化：是对 Redis 中数据执行周期性的持久化，具有时效性。

• AOF 持久化：把每条写入命令作为日志，以append-only的模式写入一个日志文件中，在 Redis 重启的时候，可以通过回放 AOF 日志的写入命令来重新构建整个数据库。

面试官：那你知道 RDB 和 AOF 这两种方式有什么区别吗？或者它们有什么优缺点？派大星：首先来说对于 RDB 来讲：

• 优点：首先对于 RDB 来说：它具有时效性，因为该特性所以它会有多个数据文件，每个数据文件都代表 Redis 中某一时刻的数据。这种方式非常适合做冷备，可以将这种完整的数据文件发送到远程的安全存储上，比如 S3，阿里云的 ODPS，从而以一个预定好的策略来定期备份 Redis 数据。并且该方式对 Redis 的读写服务影响非常小，从而也能让 Redis 保持高性能，因为 Redis 主进程只需要 fork 一个子进程让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。有点类似于 Java 序列化，恢复速度相对比较快。

• 缺点：由于其时点性，所以它不支持拉链，永远只有一个dump.rdb文件，同时也会造成时点与时点之前窗口数据容易丢失(8 点得到一个 rdb 文件 9 点刚要得到 rdb 文件 挂机了)。RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

派大星：其次来说 AOF，

• 优点：丢失数据相对较少或不丢失，一般 AOF 会每隔 1 秒，通过后台线程执行一次fsync操作，最多丢失 1s 的数据，AOF 日志文件的命令是通过可读性非常好的方式进行记录，所以这个特性非常适合做灾难性的误删除的紧急恢复(比如某人不小心用 flushall 命令清空了所有数据,只要这个时候后台 rewrite 还没有发生)。

• 缺点：同样的备份文件 AOF 相比较于 RDB，文件会比较大，恢复速度也比较慢，单纯使用 AOF 的话由于其每秒都会fsync一次日志文件的特性，会导致写的时候的 QPS 相比较于 RDB 的 QPS 要低一些。Redis 性能也会有所降低。

派大星：当然在 Redis4.0 之后也有所更新，具体如图所示：

当然 AOF 也会产生一写小的问题就是，进行数据恢复的时候，有可能不会恢复出一摸一样的数据。因为基于 AOF 这种较为复杂的基于命令日志/merage/回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式更加脆弱，容易有 bug。不过 AOF 就是为了避免 rewrite 过程导致 bug，因此每次 rewirte 的时候并不是基于旧的指令日志进行 merge 的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性就会好一些。

面试官：不错，那么在实际生产中，如何选择呢？

派大星：首先来说不要仅仅使用 RDB，因为时点性的原因会导致丢失很多数据，同时也不要仅仅使用 AOF，因为那样会有两个问题，第一通过 AOF 做冷备，没有 RDB 的体积小恢复的速度快，第二，RDB 每次简单粗暴的生成快照文件更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug。Redis 目前是支持同时开启这两种方式的持久化的，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择；用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的是有可以采用 RDB 来进行快速的数据恢复。（同时 Redis4.0 之前 Redis 中 RDB 和 AOF 可以同时开启但是只会用 AOF 恢复，但是在 4.0 之后 AOF 中包含 RDB 全量增加记录的写操作）。

面试官：非常不错，我对你这边的情况还是比较满意的。

派大星：谢谢。

如有问题，欢迎加微信交流：w714771310 备注【技术交流】加群，或关注微信公众号【码上遇见你】。