浅谈redis内存数据的持久化方式皇家赌场手机版

第二行的意思是,当AOF文件的大小大于64MB时才进行重写,因为如果AOF文件本来就很小时,有几个无效的命令也是无伤大雅的事情。

RDB方式的持久化是通过对内存中的数据进行快照完成的,当符合一定条件时,Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上。

三、二者的区别

两种持久化方式可以单独使用一种,也可以二者同时使用。

然后通过客户端设置一个键值:

AOF文件保存路径跟RDB文件相同,都是通过dir来设置

在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。

具体过程如下:

AOF文件是可识别的纯文本,它的内容就是一个个的Redis标准命令,

auto-aof-rewrite-percentage:aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写,即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写,如果之前没有重写,则以启动时的aof文件大小为依据。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍(设置为100)时,自动启动新的日志重写过程。如果将百分比指定为0,则表示关闭该功能。

在使用Redis存储非临时数据时,一般都需要打开AOF持久化来降低进程终止导致的数据丢失,AOF可以将Redis执行的每一条写命令追加到硬盘文件中,这一过程显然会降低Redis的性能,但是大部分情况下这个影响是可以接受的,另外,使用较快的硬盘能提高AOF的性能。

当使用Redis存储非临时数据时,一般需要打开AOF持久化来降低进程终止导致的数据丢失。AOF可以将Redis执行的每一条写命令追加到硬盘文件中,这一过程显然会降低Redis性能,但是大部分情况下这个影响是可以被接受的,另外可以使用较快的硬盘以提高AOF的性能。

每个快照条件独占一行,他们之间是或关系,只要满足任何一个就进行快照。上面配置save后的第一个参数T是时间,单位是秒,第二个参数M是更改的键的个数,含义是:当时间T内被更改的键的个数大于M时,自动进行快照。比如save 900 1的含义是15分钟内(900s)被更改的键的个数大于1时,自动进行快照操作。

rdbchecksum:是否校验rdb文件,从rdb格式的第五个版本开始,在rdb文件的末尾会带上CRC64的校验和,这跟有利于文件的容错性,但是在保存rdb文件的时候,会有大概10%的性能损耗,所以如果你追求高性能,可以关闭该配置。

1). 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。2). 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。3). 如果日志过大,Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建。

appendfsync:aof持久化策略的配置,no表示不执行fsync,由操作系统保证数据同步到磁盘(30秒每次,数据放在Page Cache中),速度最快,但是最不安全。always表示每次写入都执行fsync,以保证数据同步到磁盘。everysec表示每秒执行一次fsync,可能会导致丢失这1s数据。dis-persistence-demystified.html,如果不确定,选择"everysec"。

save 900 1save 300 10save 60 10000dbfilename dump.rdbdir ./

appendfilename:AOF文件名

一、概述

(2)AOF:定期或者在每次执行命令后将命令本身记录下来;

开启AOF

配置:

示例

appendonly:yes为启用AOF,no为关闭AOF

默认情况下,Redis没有开启AOF持久化功能,可以通过在配置文件中作如下配置启用:

二、AOF

第一行的意思是,目前的AOF文件的大小超过上一次重写时的AOF文件的百分之多少时再次进行重写,如果之前没有重写过,则以启动时AOF文件大小为依据。

dbfilename:设置dump文件的名字。

下面演示RDB方式持久化,首先使用配置有如下快照规则:

3、执行FLUSHALL命令;

2、AOF方式

(3)当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此,一次快照操作完成。

AOF的优势有哪些呢?

RDB载入的速度要比AOF载入的快,当redis启动时,如果rdb持久化和aof持久化都打开了,那么程序会优先使用aof方式来恢复数据集,因为aof方式所保存的数据通常是最完整的。如果aof文件丢失了,则启动之后数据库内容为空。

如果这所有的命令都写到AOF文件的话,将是一个比较蠢的行为,因为前面两个命令会被第三个命令覆盖,所以AOF文件完全不需要保存前面两个命令,事实上Redis确实就是这么做的。删除AOF文件中无用的命令的过程称为"AOF重写",AOF重写可以在配置文件中做相应的配置,当满足配置的条件时,自动进行AOF重写操作。配置如下:

1、根据配置规则进行自动快照,配置文件中SNAPSHOTTING部分可设置;

当设置appendfsync为no的时候,Redis不会主动调用fsync去将AOF日志内容同步到磁盘,所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统,是每30秒进行一次fsync,将缓冲区中的数据写到磁盘上。

bgsave命令会先fork出一个子进程,然后在子进程中生成RDB文件。由于在子进程中执行IO操作,所以bgsave命令不会阻塞Redis服务器进程,Redis服务器进程在此期间可以继续对外提供服务。

选项:

注意:如果想把正在运行的redis数据库,从RDB切换到AOF,建议先使用动态切换方式,再修改配置文件,重启数据库。(不能直接修改配置文件,重启数据库,否则数据库中数据就为空了,因为加载的时候找不到aof文件,服务器就认为数据为空。)

我们还可以手动执行BGREWRITEAOF命令主动让Redis重写AOF文件:

配置:

BGSAVE命令:从命令名字就能看出来,这个命令与SAVE命令的区别就在于该命令的快照操作是在后台异步进行的,进行快照操作的同时还能处理来自客户端的请求。执行BGSAVE命令后Redis会马上返回OK表示开始进行快照操作,如果想知道快照操作是否已经完成,可以使用LASTSAVE命令返回最近一次成功执行快照的时间,返回结果是一个Unix时间戳。

在执行fork的时候,操作系统(类Unix)会使用写时复制(copy-on-write)策略,即fork函数发生的一刻,父子进程共享同一内存数据,当父进程要更改其中某片数据时(如执行一个写命令),操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据。

现在到D:Redis_x64_321目录看,目录下出现了Redis的快照文件dump.rdb:

(1)RDB:按照指定的规则“定期”将内存中的数据存储到硬盘上;

当设置appendfsync为always时,每一次写操作都会调用一次fsync,这时数据是最安全的,当然,由于每次都会执行fsync,所以其性能也会受到影响。

(2)父进程继续接受并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件;

在执行fork的时候操作系统会使用写时复制策略,即fork函数发生的一刻,父进程和子进程共享同一块内存数据,当父进程需要修改其中的某片数据时,操作系统会将该片数据复制一份以保证子进程不受影响,所以RDB文件存储的是执行fork操作那一刻的内存数据。所以RDB方式理论上是会存在丢数据的情况的(fork之后修改的的那些没有写进RDB文件)。

rdbcompression:是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串,默认都设为 yes,如果你希望保存子进程节省点cpu,你就设置它为 no,不过这个数据集可能就会比较大

Redis允许用户自定义快照条件,当满足条件时自动执行快照。缺省情况下,Redis把数据快照存放在磁盘上的二进制文件中,文件名为dump.rdb,此外,我们也可以通过配置文件来修改Redis服务器dump快照的频率,在打开redis.windows.conf文件之后,我们搜索save,可以看到下面的配置信息:

RDB触发机制:

执行SAVE或BGSAVE命令

Save是在Redis进程中执行的,由于Redis是单线程实现,所以当save命令在执行时会阻塞Redis服务器一直到该命令执行完成为止。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

4、执行复制(replication)时。

RDB方式的持久化是通过快照的方式完成的。当符合某种规则时,会将内存中的数据全量生成一份副本存储到硬盘上,这个过程称作”快照”,Redis会在以下几种情况下对数据进行快照:

原理:

AOF重写是重新生成一份AOF文件,新的AOF文件中一条记录的操作只会有一次,而不像一份老文件那样,可能记录了对同一个值的多次操作。其生成过程和RDB类似,也是fork一个进程,直接遍历数据,写入新的AOF临时文件。在写入新文件的过程中,所有的写操作日志还是会写到原来老的AOF文件中,同时还会记录在内存缓冲区中。当重完操作完成后,会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。

一、RDB

# appendfsync alwaysappendfsync everysec# appendfsync no

1、SAVE:

RDB存在哪些优势呢?

Redis支持两种持久化方式:

文件中的内容正是Redis刚才执行的命令的内容,内容的格式就先不展开叙述了。

auto-aof-rewrite-min-size:设置允许重写的最小aof文件大小,避免了达到约定百分比但尺寸仍然很小的情况还要重写

Redis默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中,可以通过配置文件中的dir和dbfilename两个参数分别指定快照文件的存储路径和文件名,默认的存储路径和文件名如下图所示:

dir:rdb文件输出路径。

建议采用appendfsync everysec

2、BGSAVE:

启动Redis服务:

2、用户执行SAVE或BGSAVE;

Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的。所以,我们需要将内存中的数据持久化!典型的需要持久化数据的场景如下:

(1)Redis使用fork函数复制一份当前进程(父进程)的副本(子进程);

AOF持久化配置

save:save 900 1 表示在900秒内如果有一个key被操作了,就执行保存快照,可以设置多个条件,各个条件彼此之间是或的关系,如果要禁用,将条件都删除,写成save ""即可。

1). 一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。2). 对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。3). 性能最大化。对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。4). 相比于AOF机制,如果数据集很大,RDB的启动效率会更高。

3、appednfsync always

五、常用配置

快照执行的过程如下:

开启之后,Redis每执行一条写命令就会将该命令写入硬盘中的AOF文件。AOF文件保存路径和RDB文件路径是一致的,都是通过dir参数配置,默认文件名是:appendonly.aof,可以通过配置appendonlyfilename参数修改,例如:

=============================================================================

命令:BGREWRITEAOF, 我们应该经常调用这个命令来来重写。

根据配置自动快照

执行重写命令之后查看现在的AOF文件:

注意最后三行,分别表示:

每一条写命令都生成一条日志,AOF文件会很大。

当执行FLUSHALL命令时,Redis会清除数据库中的所有数据。需要注意的是:不论清空数据库的过程是否触发了自动快照的条件,只要自动快照条件不为空,Redis就会执行一次快照操作,当没有定义自动快照条件时,执行FLUSHALL命令不会进行快照操作。

本文由皇家赌场手机版发布于首页,转载请注明出处:浅谈redis内存数据的持久化方式皇家赌场手机版

相关阅读