redis的两种持久化机制

Posted 2020-11-16 abel111

---恢复内容开始---

RDB:在指定的时间间隔对redis中的数据进行快照存储，默认开启

AOF:记录每次操作redis的命令，将命令写入到AOF文件中，当重启redis时会重新执行这些命令来恢复数据，默认关闭。

RDB方式：

           Redis会根据redis.conf配置文件定期将数据快照至一个RDB文件中：

           save [seconds] [changes]:意为每seconds秒内如果数据有changes次修改，那么就进行一次rdb快照存储。可配置多条save指令，让redis执行多级的快照保存策略。

RDB工作原理：RDB持久化是指在指定的时间间隔内对内存中的数据进行一次快照存储,写入本地磁盘中。实际操作过程是先fork一个子进程，再将数据写入到一个临时文件中，写入成功后，再将之前的文件替换，用二进制压缩存储的。RDB是redis默认的持久化方式，会在对应的目录下产生一个dump.rdb的文件，重启redis会加载这个dump.rdb文件，恢复原始数据。

 

RDB的触发分为两种：手动触发和自动触发。

   手动触发可以是：

         save:    该命令会阻塞redis,在sava期间，不能执行其他命令，直到持久化完成。

         bgsave:该命令不会阻塞redis，在后台进行的。该触发方式会fork一个子进程，由子进程负责持久化，因此阻塞只会发生在fork子进程的时候。

  自动触发：

          save m n:根据redis配置文件配置规则自动触发。

         从节点全量复制时，主节点发送一个rdb文件给从节点完成复制操作时，主节点会触发bgsave。

        执行debug reload时自动触发RDB持久化。

         执行shutdown时，若没有开启aof  也会触发RDB持久化。

 

   注意：fork操作会阻塞redis，导致redis读写性能下降，我们可以通过控制单个redis实例的最大内存，来尽可能降低fork时的消耗。也可通过减少自动触发的频率，减少fork次数。

 RDB优点：

            对性能影响最小：因为它会fork一个子进程来完成持久化操作，几乎不影响redis处理客户端请求的效率。

            他可以按照每小时，每分钟，每天来进行快照存储，可以作为一种可靠的灾难恢复手段。

            数据恢复比AOF要快很多。

RDB缺点  ：

                如果更新数据后，还没来得及持久化，redis就宕机了，那么更新的数据就会丢失。

              如果redis中的数据非常多且CPU处理能力不足的情况下，在fork子进程的时候就会消耗更长的时间，这时若对redis进行额外的操作的话，redis处理这个操作的时间就更长。

 

AOF方式:

         

• AOF工作原理

          采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。

 

          AOF的整个流程大体分为两步，一步是命令的实时写入（如果是 appendfsync everysec 配置，会有1s损耗），第二步是对aof文件的重写（重写是直接把当前内存的数据生成对应命令）。

         对于增量追加到文件这一步主要的流程是：命令写入=》追加到aof_buf =》同步到aof磁盘。那么这里为什么要先写入buf在同步到磁盘呢？如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。

         aof重写的目的是为了减少aof文件的大小，可以手动或者自动触发。

       手动触发： bgrewriteaof，自动触发 就是根据配置规则来触发。

 

• AOF如何配置：

                      AOF默认是关闭的，如要开启，进行如下配置：appendonly yes。AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：

                     appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快

                     appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢

                    appendfsync everysec：折中的做法，交由后台线程每秒fsync一次

 

               随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。

 

                AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：

            auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

             上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。

 

              AOF的优点：

 最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据。

AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。

AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。

 

          AOF的缺点：

       AOF文件通常比RDB文件更大

       性能消耗比RDB高

       数据恢复速度比RDB慢

            

---恢复内容结束---