您的位置:金沙游乐场85155 > 大数据库 > 金沙85155登入浅谈redis内存数据的持久化方式

金沙85155登入浅谈redis内存数据的持久化方式

发布时间:2020-04-20 23:31编辑:大数据库浏览(72)

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

    2、用户执行SAVE或BGSAVE;

    AOF持久化的实现

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

    1). 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。2). 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。

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

    AOF以纯文本的形式记录了Redis执行的写命令,例如在开启AOF持久化的情况下执行如下命令:

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

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

    appendfilename:AOF文件名

    1、appendfsync no

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

    金沙85155登入,执行重写命令之后查看现在的AOF文件:

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

    根据配置自动快照

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

    然后查看D:Redis_x64_321appendonly.aof文件:

    2、BGSAVE:

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

    RDB触发机制:

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

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

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

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

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

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

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

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

    根据配置规则进行自动快照; 用户执行SAVE, BGSAVE命令; 执行FLUSHALL命令; 执行复制时。

    4、执行复制(replication)时。

    RDB持久化配置

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

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

    具体过程如下:

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

    原理:

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

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

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

    3、执行FLUSHALL命令;

    快照原理

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

    SAVE命令:当执行SAVE命令时,Redis同步进行快照操作,期间会阻塞所有来自客户端的请求,所以放数据库数据较多时,应该避免使用该命令;

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

    同步硬盘数据

    1、SAVE:

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

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

    示例

    配置:

    AOF文件重写

    配置:

    假设Redis执行了如下命令:

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

    Redis使用fork函数复制一份当前进程的副本;父进程继续处理来自客户端的请求,子进程开始将内存中的数据写入硬盘中的临时文件;当子进程写完所有的数据后,用该临时文件替换旧的RDB文件,至此,一次快照操作完成。

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

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

    一、RDB

    五、常用配置

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

    现在重新启动Redis,然后再用客户端连接,检查之前设置的key是否还存在:

    二、AOF

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

    Redis支持两种持久化方式:

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

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

    执行FLUSHALL命令

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

    三、二者的区别

    dir:rdb文件输出路径。

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

    dbfilename:设置dump文件的名字。

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

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

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

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

    四、二者优缺点

    执行SAVE或BGSAVE命令

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

    二、Redis数据持久化

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

    建议采用appendfsync everysec

    AOF的优势有哪些呢?

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

    1). 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。2). 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。

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

    RDB又存在哪些劣势呢?

    虽然每次执行更改数据库的内容时,AOF都会记录执行的命令,但是由于操作系统本身的硬盘缓存的缘故,AOF文件的内容并没有真正地写入硬盘,在默认情况下,操作系统会每隔30s将硬盘缓存中的数据同步到硬盘,但是为了防止系统异常退出而导致丢数据的情况发生,我们还可以在Redis的配置文件中配置这个同步的频率:

    本文由金沙游乐场85155发布于大数据库,转载请注明出处:金沙85155登入浅谈redis内存数据的持久化方式

    关键词:

上一篇:没有了

下一篇:没有了