码迷,mamicode.com
首页 > 其他好文 > 详细

redis的两种持久化机制

时间:2019-10-18 12:17:28      阅读:79      评论:0      收藏:0      [点我收藏+]

标签:nta   save   percent   bug   工具轻松   使用   替换   持久   默认   

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

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慢

            

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

redis的两种持久化机制

标签:nta   save   percent   bug   工具轻松   使用   替换   持久   默认   

原文地址:https://www.cnblogs.com/abel111/p/11697589.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!