您的位置:澳门皇冠金沙网站 > 办公软件 > 浅谈redis内存数据的持久化方式【澳门皇冠金沙网

浅谈redis内存数据的持久化方式【澳门皇冠金沙网

2020-04-21 15:51

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

具体过程如下:

快照执行的过程如下:

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

现在强行kill Redis服务,执行shutdown命令:

RDB触发机制:

3、appednfsync always

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

# appendfsync alwaysappendfsync everysec# appendfsync no

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

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。

3、执行FLUSHALL命令;

AOF的优势有哪些呢?

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

AOF的劣势有哪些呢?

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

一、概述

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

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

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

将Redis作为数据库使用; 将Redis作为缓存服务器使用,但是缓存miss后会对性能造成很大影响,所有缓存同时失效时会造成服务雪崩,无法响应。

Redis支持两种持久化方式:

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

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

启动Redis服务:

二、AOF

三、二者的区别

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

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

dbfilename:设置dump文件的名字。

2、appendfsync everysec

2、用户执行SAVE或BGSAVE;

选项:

appendfilename:AOF文件名

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

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

在Redis的配置文件中存在三种同步方式,它们分别是:appendfsync always #每次有数据修改发生时都会写入AOF文件。appendfsync everysec #每秒钟同步一次,该策略为AOF的缺省策略。appendfsync no #从不同步。高效但是数据不会被持久化。

原理:

当设置了主从模式时,Redis会在复制初始化时进行自动快照。

一、RDB

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

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

建议采用appendfsync everysec

配置:

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

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

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

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

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

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

可以发现,之前设置的key在Redis重启之后又通过快照文件dump.rdb恢复了。

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

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

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

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

2、BGSAVE:

快照模式可以和AOF模式同时开启,互补影响。

配置:

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

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

AOF文件重写

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

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

1、SAVE:

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

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

二、Redis数据持久化

4、执行复制(replication)时。

除了让Redis自动进行快照外,当我们需要重启,迁移,备份Redis时,我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作。

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

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

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

执行快照的场景

dir:rdb文件输出路径。

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

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

AOF持久化配置

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

开启AOF

这两个配置项通常一起使用。

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

示例

1、RDB方式

当设置appendfsync为everysec的时候,Redis会默认每隔一秒进行一次fsync调用,将缓冲区中的数据写到磁盘。但是当这一次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略,再等一秒钟。也就是在两秒后再进行fsync,这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞,所以当前的写操作就会阻塞。所以,结论就是:在绝大多数情况下,Redis会每隔一秒进行一次fsync。在最坏的情况下,两秒钟会进行一次fsync操作。这一操作在大多数数据库系统中被称为group commit,就是组合多次写操作的数据,一次性将日志写到磁盘。

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

Redis支持两种数据持久化方式:RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上,后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用,但是通常会将两者结合使用。

本文介绍Redis所支持的两种数据持久化方式。

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

本文由澳门皇冠金沙网站发布于办公软件,转载请注明出处:浅谈redis内存数据的持久化方式【澳门皇冠金沙网

关键词:

  • 上一篇:没有了
  • 下一篇:没有了