Redis面试篇 -- Redis持久化的方式有哪些？优缺点分别是什么？

Redis持久化方式 

---

 

       持久化的目的主要是作灾难恢复，数据恢复。因为Redis的数据全都放在内存里面，若是Redis挂了，没有配置持久化的话，重启的时候数据会所有丢失。

        忽然间，大量的请求过来，缓存全都没法命中，形成缓存雪崩，mysql没法承载大量的请求，形成整个系统崩溃。 若是把Redis持久化作好，即便Redis故障了，也可以当即重启，对外提供服务。

 

        Redis持久化分为两种：

• RDB持久化： 在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操做过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换以前的文件，用二进制压缩存储 。
• AOF持久化： AOF 机制对每条写入命令做为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，能够经过回放 AOF 日志中的写入指令来从新构建整个数据集。            

        经过RDB和AOF，均可以Redis内存中的数据持久化到磁盘中，也能够被分到其余地方，好比阿里云等。若是Redis挂了，能够从磁盘或者阿里云等地方拷贝数据到Redis中，重启Redis，Redis就会自动根据文件来重构数据。

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

RDB持久化的配置：

     Redis会将数据集的快照dump到dump.rdb文件中。此外，咱们也能够经过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件以后，咱们搜索save，能够看到下面的配置信息：

 　save 900 1              #在900秒(15分钟)以后，若是至少有1个key发生变化，则dump内存快照。
   save 300 10             #在300秒(5分钟)以后，若是至少有10个key发生变化，则dump内存快照。
   save 60 10000           #在60秒(1分钟)以后，若是至少有10000个key发生变化，则dump内存快照。

AOF持久化配置：

     在Redis的配置文件中存在三种同步方式，它们分别是：

  appendfsync always      #每次有数据修改发生时都会写入AOF文件。
  appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。
  appendfsync no            #从不一样步。高效可是数据不会被持久化。

 

RDB和AOF的优缺点

---

 

RDB的优缺点：

• 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是很是完美的。好比，你可能打算每一个小时归档一次最近24小时的数 据，同时还要天天归档一次最近30天的数据。经过这样的备份策略，一旦系统出现灾难性故障，咱们能够很是容易的进行恢复。
• 相对于 AOF 持久化机制来讲，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
• RDB 对 redis 对外提供的读写服务，影响很是小，可让 redis 保持高性能，由于 redis 主进程只须要 fork 一个子进程，让子进程执行磁盘 IO 操做来进行 RDB 持久化便可。
• 对于灾难恢复而言，RDB是很是不错的选择。由于咱们能够很是轻松的将一个单独的文件压缩后再转移到其它存储介质上。
• 若是想要在 redis 故障时，尽量少的丢失数据，那么 RDB 没有 AOF 好。通常来讲，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。
• RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，若是数据文件特别大，可能会致使对客户端提供的服务暂停数毫秒，或者甚至数秒。

 

AOF的优缺点：

• AOF 能够更好的保护数据不丢失，通常 AOF 会每隔 1 秒，经过一个后台线程执行一次fsync操做，最多丢失 1 秒钟的数据。
• AOF 日志文件以append-only模式写入，因此没有任何磁盘寻址的开销，写入性能很是高，并且文件不容易破损。 若是咱们本次操做只是写入了一半数据就出现了系统崩溃问题，不用担忧，在Redis下一次启动以前，咱们能够经过redis-check-aof工具来帮助咱们解决数据 一致性的问题。
• AOF 日志文件即便过大的时候，出现后台重写操做，也不会影响客户端的读写。由于在rewrite log 的时候，会对其中的指令进行压缩，建立出一份须要恢复数据的最小日志出来。在建立新日志文件的时候，老的日志文件仍是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件便可。 所以在进行rewrite切换时能够更好的保证数据安全性。
• AOF以一个格式清晰、易于理解的日志文件用于记录全部的修改操做， 很是适合作灾难性的误删除的紧急恢复。 好比有人不当心用flushall命令清空了全部数据，只要这个时候后台rewrite尚未发生，那么就能够当即拷贝 AOF 文件，将最后一条flushall命令给删了，而后再将该aof文件放回去，就能够经过恢复机制，自动恢复全部数据。
• 对于相同数量的数据集而言，AOF文件一般要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
• AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低， 由于 AOF 通常会配置成每秒 fsync 一第二天志文件。
• 类 似 AOF 这种较为复杂的基于命令日志 / merge / 回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。

如何选择？

---

 

RDB和AOF如何选择？

•  不要仅仅使用 RDB，由于那样会致使你丢失不少数据；
• 也不要仅仅使用 AOF，由于那样有两个问题：第一，你经过 AOF 作冷备，没有 RDB 作冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，能够避免 AOF 这种复杂的备份和恢复机制的 bug；
• redis 支持同时开启开启两种持久化方式，咱们能够综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，做为数据恢复的第一选择; 用 RDB 来作不一样程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可使用 RDB 来进行快速的数据恢复。