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

Posted 2021-03-26 iamyzh

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 来进行快速的数据恢复。