Redis持久化,RDB和AOF
Posted node2017
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis持久化,RDB和AOF相关的知识,希望对你有一定的参考价值。
Redis强大的功能很大部分是由于他把数据缓存在内存中,为了使Redis在重启的时候,数据不丢失,就需要已某种方式把数据持久化到磁盘中。Redis持久化的方式有俩种,RDB和AOF。
RDB:快照方式,允许你每隔一段时间对内存数据做一次快照然后存储到硬盘中。该方式是Redis默认的持久化方式。
RDB可以通过在配置文件中配置时间或者改动键的个数来定义快照条件,编辑配置文件redis.conf,找到
save 900 1 #15分钟之内至少有一个建被更改则进行快照
save 300 10 #5分钟之内至少有10个建被更改则进行快照
save 60 10000 #1分钟之内至少有1000个建被更改则进行快照
他们之间是或的关系,RDB持久化到磁盘的文件默认路径是在当前目录,文件名为dump.rdb,你可以通过配置文件配置dir和dbfilename来指定文件目录和文件名称,RDB文件还可以进行压缩,你可以通过配置rdbcompression参数来进行压缩。
RDB快照过程:
1、Redis使用fork函数复制一份当前的父进程作为子进程
2、父进程继续处理用户的请求,子进程开始把内存中的数据持久化到磁盘上
3、当子进程把内存中的数据写入到临时文件完成之后,会把该临时文件替换掉旧的RDB文件。
RDB优点:RDB文件内容紧凑,文件小(比AOF文件小)非常适合于灾难恢复,而且能最大程度的使用Redis性能,因为Redis主程序可以fork一个子进程来单独处理RDB持久化,而Redis主进程毋须参与这个过程,另外相对于AOF的数据恢复,RDB数据恢复比AOF快得多。
RDB缺点:由于RDB是间隔一段时间进行快照持久化,那么有可能就在系统发生故障的时候,你就会丢失这段时间内的数据。另外由于RDB在处理持久化数据的时候,有可能就是在数据量庞大的时候,fork出的子进程会非常耗时,如果系统在这时候发生故障,那么你就会丢失这段时间的数据。
由于RDB缺点的存在,Redis又有另外一种持久化的方式,AOF。
AOF:通过将发送到服务器的写操作命令记录下来,形成AOF文件,文件默认名称是appendonly.aof,可以通过appendfilename来指定文件名称。你可以通过配置文件打开AOF功能
appendonly yes
AOF的原理是直接把用户插入到服务器的命令追加到结尾,那么文件会原来越大,一些重复的写命令也会越来越多,这时,我们可以利用BGREWRITEAOF 命令来重写AOF,重写的配置如下:
auto-aof-rewrite-percentage 100 #aof文件大小超过上次重写时文件大小的百分之几开始重写,如果之前没有写过,则根据启动时文件大小。
auto-aof-rewrite-min-size 64mb #限制允许重写时的最小文件大小。
AOF在同步内存数据到磁盘上时,并不是马上把文件写如到磁盘中,而是先把文件缓存到系统,然后每隔30秒将文件写入到磁盘中,我们可以在配置文件中配置同步的策略
appendfsync always #每次都同步,保证数据不会丢失,但会慢
appendfsync everysec #每秒同步,系统默认同步策略
appendfsync no #不主动同步,由操作系统决定,快,但数据容易丢失
AOF同步过程:
1、Redis 执行 fork() ,现在同时拥有父进程和子进程。
2、子进程开始将新 AOF 文件的内容写入到临时文件。
3、对于所有新执行的写入命令,父进程一边将它们累积到一个内存缓存中,一边将这些改动追加到现有 AOF 文件的末尾: 这样即使在重写的中途发生停机,现有的 AOF 文件也还是安全的。
4、当子进程完成重写工作时,它给父进程发送一个信号,父进程在接收到信号之后,将内存缓存中的所有数据追加到新 AOF 文件的末尾。
5、搞定!现在 Redis 原子地用新文件替换旧文件,之后所有命令都会直接追加到新 AOF 文件的末尾。
参考文档:http://doc.redisfans.com/topic/persistence.html#append-only-file-aof
以上是关于Redis持久化,RDB和AOF的主要内容,如果未能解决你的问题,请参考以下文章