精华内容
下载资源
问答
  • RDB与AOF的区别

    万次阅读 2019-05-05 08:30:08
    AOFRDB是两种redis持久化的机制。 RDB: RDB是将支持当前数据的快照存成一个数据文件的持久化机制。 1.在生成快照时,将当前进程fork出一个子进程. 2.然后再子进程中循环所有的数据,将数据写入到二进制文件中。 3....

    AOF和RDB是两种redis持久化的机制。

    RDB:
    RDB是将支持当前数据的快照存成一个数据文件的持久化机制。
    1.在生成快照时,将当前进程fork出一个子进程.
    2.然后再子进程中循环所有的数据,将数据写入到二进制文件中。
    3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。
    优点:
    1.一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这样非常方便进行备份。比如你可能打算每1天归档一些数据。
    2.方便备份的同时,我们也很容易的将一个RDB文件移动到其他存储物质上。
    3.RDB 可以最大化 Redis 的性能:父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。
    劣势:
    如果你想在服务器上避免数据的丢失,那么RDB就不适合了,因为RDB文件需要保存整个数据集的状态,因为你可能会在5分钟才保存一次RDB文件,在这种情况下,一旦发生故障停机,你可能会损失好几分钟的数据。
    每次在保存RDB的时候,Redis都要fork出一个子进程,并由子进程来进行实际的持久化工作,如果在数据集比较庞大时,fork可能会非常耗时,造成服务器在那么一瞬间会停止处理客户端;虽然AOF重写也需要进行fork,但AOF重写的执行时间间隔有多长,数据的耐久性都不会有任何损失。
    AOF:
    AOF: Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写操作,并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。AOF的工作原理就是是将写操作追加到文件中,文件的冗余内容会越来越多。所以Redis 新增了重写机制。当AOF文件的大小超过所设定的最大值时,Redis就会对AOF文件的内容压缩。
    优点:数据的完整性和一致性更高
    缺点:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。
    总结
    Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。
    RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
    Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。
    AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。
    Redis 针对 AOF文件大的问题,提供重写的瘦身机制。
    若只打算用Redis 做缓存,可以关闭持久化。
    若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份,留一后手。AOF出问题了,还有RDB。

    展开全文
  • RDB AOF 抉择对比

    2018-09-06 23:05:40
    RDB的启动优先级低于AOF的启动优先级,在宕机的情况下会优先启动AOF RDB使用二进制的文件作为快照,所以文件的体积小点,AOF则使用了文件追加的方式,所以文件的提及大一些 RDB的恢复速度快,AOF的恢复速度慢一些 ...

    RDB的启动优先级低于AOF的启动优先级,在宕机的情况下会优先启动AOF

    RDB使用二进制的文件作为快照,所以文件的体积小点,AOF则使用了文件追加的方式,所以文件的提及大一些

    RDB的恢复速度快,AOF的恢复速度慢一些

    RDB文件dump过程中若出现故障,那么会丢失较多的数据,AOF可以有一秒的数据丢失

    RDB的操作相对较重一些,会fork出子线程历来dump文件并将临时文件中的内容刷新到旧文件中

    AOF若不是用bg操作,操作还是比较轻的

     

     

    展开全文
  • redis(三)-RDB与AOF

    2020-06-11 23:48:32
    RDB快照: 快照机制是redis的一种持久化策略; 简单描述下就是:每隔一段时间(redis.conf中可以配置),将当前数据库的内容备份到磁盘上;下次启动服务时,将会自动从.RDB文件中恢复数据; #下面三个设置意思是: #每900秒,...

    参考资料:
    redis 4.x cookbook 中文版;
    redis官方文档
    注: 本文redis的版本为: 5.0.3

    redis学习路径

    RDB快照:

    快照机制是redis的一种持久化策略;
    简单描述下就是:每隔一段时间(redis.conf中可以配置),将当前数据库的内容备份到磁盘上;下次启动服务时,将会自动从.RDB文件中恢复数据;

    #下面三个设置意思是:
    #每900秒,且至少进行了一次键值对修改;将触发一次rdb快照;
    #每300秒,且至少进行了10次键值对修改;将触发一次rdb快照;
    #每60秒,且至少进行了10000次键值对修改;将触发一次rdb快照;
    #注释掉save,将不会触发rdb快照;
    #save "" 也会禁止rdb快照;
    save 900 1
    save 300 10
    save 60 10000
    
    #如果启用RDB快照(至少配置一个保存点[save xxx xxx])并且最新的后台保存失败,则Redis将停止接受写入.
    #假如设定了持久化监控,那么建议关闭此配置,这样可以让redis在系统和磁盘出问题的时候,依然可以接收数据;
    stop-writes-on-bgsave-error yes
    
    #是否在保存rdb快照文件时使用压缩字符串对象;
    #如果选择'yes'将会提高cpu消耗,选择'no'会占用更多空间,通常'yes'更占优;
    rdbcompression yes
    
    #持久化之前是否进行校验;
    #yes开启校验,有更高的抗损坏性,但是保存或读取rdb快照文件损失10%性能;
    #no关闭校验,意味着checksum的值永久为0,读取rdb快照文件时将不再进行校验;
    rdbchecksum yes
    
    #rdb快照文件名称;
    dbfilename dump.rdb
    
    #rdb快照工作目录,注意,此处仅能设置文件夹,生成的文件以dbfilename为准;
    dir /var/lib/redis
    

    在客户端在中,我们可以使用如下命令来触发RDB持久化:

    127.0.0.1:6379> set key1 value1 nx
    OK
    127.0.0.1:6379> keys *
    1) "key1"
    127.0.0.1:6379> get key1
    "value1"
    #手动触发快照;注意了,save命令是阻塞的,意味着除非此命令执行完成,否则不接收其他命令;生产环境禁用;
    127.0.0.1:6379> save
    OK
    #手动触发快照;此处是由redis分出一个子子进程,进行快照;redis的主进程依然可以接收命令;
    #子进程在快照的时候,生成一个临时快照文件;
    #在持久化完成之后,历史快照文件将会被删除,临时文件将以dbfilename 配置的值重命名;
    127.0.0.1:6379> bgsave
    Background saving started
    
    

    AOF持久化

    AOF持久化是指,通过追加文件的方式进行持久化;
    在配置文件中,可以决定是相隔多久向AOF文件中追加一次数据,或者是每写入一次数据库就追加一次;(这里的追加,是指将数据刷新到磁盘上,也即是配置文件中的appendfsync)

    #AOF是对持久化文件(AOF文件)进行追加的一种持久化方式;
    #前面的RDB持久化,由于每次都需要对数据库进行快照,所以注定是要间隔一段时间才能进行一次;
    #出现断电情况时,将会丢失几分钟的数据;
    #AOF是每次写入都会追加,哪怕断电也顶多丢失一秒钟写入的数据;
    #AOF,RDB可以同时开启;AOF文件是非二进制压缩文件,占用空间大;
    #RDB优点是二进制压缩文件可以快速还原;AOF优点是,数据丢失量更少;
    #默认关闭AOF
    appendonly no
    #aof文件名称;
    appendfilename "appendonly.aof"
    #fsync,是指通知系统将从内存中输出的数据刷新到磁盘上(某些系统根据调用立即刷新,某些系统是尽快刷新)
    #下面的配置有三个值:
    #no,由操作系统决定什么时候刷新;(速度最快,但是丢失的数据较多)
    #always,每个写操作都刷新;(速度最慢,但是安全)
    #everysec,每秒同步刷新一次;(妥协值)
    appendfsync everysec
    #当aof设置为每秒或者是每次操作都fsync()时,后台如果进行BGSAVE/触发AOF追加(会有大量的磁盘IO);
    #如果主线程也进行追加,也会调用fsync(),这种情况下,会触发阻塞;linux中最长阻塞可达30s;
    #如果配置为no,则进行追加,即主线程阻塞;如果设置为yes,则不追加,
    #并将数据写入到缓冲区aof_rewrite_buf_blocks,等到子进程的fsync()执行完成后,通知主线程进行fsync();
    #因为存在缓冲区的数据没有持久化到数据库,这样就有可能会丢失阻塞时间内的数据;
    #因此,如果不允许主线程出现延时,则选择yes;通常建议no;
    no-appendfsync-on-rewrite no
    #触发重写aof文件的条件:aof文件已经达到指定值(64M),且与上次AOF文件相比,已经增加了指定百分比(100%)
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb
    #redis启动时,发现aof文件因系统原因出现不完整现象的处理设置;
    #no,中断redis进程;(用户可以在redis未启动时对aof执行:redis-check-aof修复文件)
    #yes,提示用户,继续运行;
    #注意,如果aof文件中间因为不明原因出现问题,依然会退出;
    #此配置是指在aof文件末尾没有找到足够的字符组成数据;
    aof-load-truncated yes
    #以RDB文件名称为前缀;同时,在进行持久化时,产生AOF文件,将会以RDB结构为开头,后续部分内容为AOF结构;
    #在恢复的时候,redis会优先读取AOF文件(因为默认AOF文件数据会更完整)进行恢复;
    #这种设置,可以更快的持久化,更快的恢复,更小的AOF文件;默认为yes;
    #如果不开启aof,此处开启了也毫无意义;
    aof-use-rdb-preamble yes
    #lua脚本执行的最大时间,设置0,不做限制;单位s;
    lua-time-limit 5000
    

    在客户端,可以通过命令来主动触发AOF文件的重写;

    127.0.0.1:6379> BGREWRITEAOF
    Background append only file rewriting started
    

    查看上次持久化时间

    127.0.0.1:6379> LASTSAVE
    (integer) 1324043588
    

    RDB与AOF混用

    由于这两者都有自己的缺点:
    RDB可能会丢失较长时间的数据;
    AOF会导致持久化文件臃肿以及启动数据库变慢;
    所以最好的方式是混合使用它们;

    #混用的关键配置:
    #以RDB文件名称为前缀;同时,在进行持久化时,产生AOF文件,将会以RDB结构为开头,后续部分内容为AOF结构;
    #在恢复的时候,redis会优先读取AOF文件(因为默认AOF文件数据会更完整)进行恢复;
    #这种设置,可以更快的持久化,更快的恢复,更小的AOF文件;默认为yes;
    #如果不开启aof,此处开启了也毫无意义;
    aof-use-rdb-preamble yes
    

    扩充资料:

    redis的RDB快照机制详解
    redis开启主从复制后,持久化之后如何处理过期KEY

    展开全文
  • 文章目录前言一、RDB二、AOF总结 前言 redis作为内存数据库,存在断电数据丢失的问题,所以redis有两种技术实现来保证数据的完整性。rdbaof。分别代表内存数据库两种思路,全量快照保存和日志形式保存。 一、RDB ...


    前言

    redis作为内存数据库,存在断电数据丢失的问题,所以redis有两种技术实现来保证数据的完整性。rdb和aof。分别代表内存数据库两种思路,全量快照保存和日志形式保存。

    一、RDB

    学习rdb最权威的方式就是去看他的redis.conf配置文件,里面有很多详细说明
    在这里插入图片描述
    rdb是全量保存当前时刻内存数据到磁盘。
    从文档的描述可以看出,rdb保存的周期是根据这个公式来的
    save
    在多少时间内,key变化了多少次
    就比如上面的三个配置,可以得出,
    redis在60秒内变化了10000次则触发rdb写进磁盘
    或者redis在300秒内key变化了10次
    再或者redis在900秒内key变化了1次写磁盘

    这里其实有个问题存在的
    假设晚上12点redis需要将rdb文件写到磁盘,那么我们知道写磁盘涉及到IO,那么redis是不是会阻塞?
    答案是,redis肯定不会阻塞,因为一旦阻塞,就会影响redis的使用。那么redis是怎么做的呢?
    答案是,redis在这里通过linux的系统调用接口fork出一个子进程。fork为什么可以实现?
    理由是fork的话,那么在内存中会消耗极少的空间来存储redis中对应key的引用指针,然后fork底层利用copy-on-write写时复制的方式实现高效。写时复制相当于java的copyonwriteList的原理,当你需要在redis主进程操作key的时候,在内存中会复制一份原来value值,然后把redis主进程的key的引用指针改写到这个新的内存空间,这样就不影响到fork出来的进程。写时复制是在大量工程中验证过得,因为很少发生大量对原来进程所有的引用重写更改的情况。所以fork的效率非常高。

    在这里插入图片描述

    但是如果单纯使用rdb,可以想象得到,在我进行rdb文件写磁盘的时候,同时用户对redis有key的操作的话,那这些数据就会丢失。要解决这个问题,就需要aof了。

    二、AOF

    在这里插入图片描述
    通过aof的描述,可以知道aof相比rdb对于数据完整性更好
    aof是实时记录用户对key的新增,修改,删除操作,然后将这些操作日志写在和rdb相同目录下的appendonly.aof文件中。
    aof有三种方式写入磁盘aof文件中,分别是

    #这是最安全的方式,用户每次对key的更改操作,redis都会调用linux内核直接flush到磁盘中,这种模式丢失数据最少,丢失一条数据
    # appendfsync always
    
    #redis会把数据先发送都linux内核缓存起来,时间每间隔一秒调用系统的flush写到磁盘,这种模式丢失数据中等,一秒的数据,小于一个缓冲区的大小
    appendfsync everysec
    
    #redis不管linux内核什么时候将数据flush 到磁盘,只要linux内核的数据缓存满了,linux内核会flush,这种模式丢失数据最多,最多一个缓冲区
    # appendfsync no
    
    

    aof还存在一个问题,如果持续往磁盘中aof文件中写入日志记录,随着时间增长,aof的文件也就变得巨大
    为解决这个问题,redis有个重写的机制。
    什么是重写?
    就是将aof文件中,可以抵消的指令抵消掉,只留下精简的指令来就可以恢复当前内存中数据。举例,比如set k1 xx 然后set k1 yy。那么redis重写之后在aof文件中只会留下set k1 yy这个指令,因为前面的操作对于恢复当前内存数据没有帮助。
    怎么样重写?
    Redis提供两种方式重写,第一种是认为在redis客户端执行

    127.0.0.1:6379> BGREWRITEAOF
    

    第二种是通过redis自动的方式进行重写。
    在这里插入图片描述
    百分比100,是指redis会记录上次重写的aof文件的大小,当aof文件的大于等于上次重写文件大小的100%(可以改)同时重写时候文件的大小最少是64M(可以改),防止重写的aof文件偏小而频繁进行重写。

    听起来,aof比rdb更好点,实际上,在redis4之前使用的是aof。即使你开启rdb也不生效。
    但redis4之后就使用rdb和aof混合的方式。rdb负载在某个时刻把内存整个数据dump到磁盘中,aof记录redis从dump开始,对redis key的更改操作。一句话rdb全量,aof增量。
    在数据进行重写的时候,redis会把rdb文件先进行重写进aof文件,然后把剩下的aof文件追加到重写的aof文件后面

    总结

    redis4之前使用aof的方式,会产生一个问题,就是aof重写的时间过长。恢复较慢
    redis5之后使用rdb和aof的方式,重写的时候先把rdb文件先重写,然后把aof文件追加到重写的文件中,速度较快

    展开全文
  • RDB与AOF

    2020-11-03 19:52:19
    文章目录rdb触发RDB快照通过RDB文件恢复数据RDB 的优缺点AOF配置重写触发机制根据AOF文件恢复数据AOF的重写机制AOF 的优缺点 rdb save 900 1 save 300 10 save 60 10000 rdb默认配置 当 900 秒执行 1 个写命令时,...
  • RDB 什么是RDB 每隔一段时间,把内存中的数据写入磁盘的临时文件,作为快照,恢复的时候把快照文件读进内存。如果宕机重启,那么内存里的数据肯定会没有的,那么...相对AOF来说,当有更大文件的时候可以快速重启恢
  • AOF 持久化记录服务器执行的所有写操作命令,并在服务器启动时,通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis...Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下, 当 Redis 重启时
  • 1. RDB 持久化的优缺点 2. AOF 持久化的优缺点 3. 混合持久化 Redis 是一个键值对数据库服务器,服务器中通常包含着任意个非空数据库,而每个非空数据库中有可以包含任意个键值对,为了方便起见,我们将服务器中...
  • Redis持久化之RDB与AOF对比总结

    千次阅读 2020-03-29 17:01:39
    编程界的小学生一、原理1、RDB优缺点以及原理2、AOF优缺点以及原理二、面试:RDB与AOF哪个快?1、分析2、持久化过程哪个快3、哪个持久化方式会对主进程影响较大三、文件格式1、RDB1.1、文件在哪1.2、文件格式2、AOF...
  • Redis之RDB与AOF 笔记

    2018-05-07 16:12:52
    AOF定义:以日志的形式记录每个操作,将Redis执行过的所有指令全部记录下来(读操作不记录),只许追加... 一.RDB与AOF同时开启 默认先加载AOF的配置文件  二.相同数据集,AOF文件要远大于RDB文件,恢复速度慢于R...
  • 持久化之RDB 定义:在指定的时间间隔内生成数据集的时间点快照 RDB 的优点: 1.RDB 是一个非常紧凑的文件 它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份: 比如说,你可以在最近的 24 小时...
  • 持久化简介 1.什么是持久化 利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制称为持久化...1.RDB启动方式 —— save指令 命令 save //redis操作者(用户)即时(随时进行)执行命令
  • ????思考:我们的Redis必须使用数据持久化吗?Redis又是如何持久化? (1)如果我们的Redis服务器只作为缓存使用,Redis中存储的所有数据都是从其他...AOFAOF机制对每条写入命令作为日志,以append-only的模式写入一
  • 文章目录Redis持久化持久化之RDB手动触发自动触发持久化之AOF Redis持久化 持久化之RDB RDB是Redis默认持久化方式,默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave进行RDB持久化数据。 ...
  • Redis之RDBAOF如何选择?

    千次阅读 2019-12-08 20:30:54
    RDB持久化方式能够在指定的时间间隔对内存中的数据进行快照存储; AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件...
  • Redis RDB与AOF持久化详解

    千次阅读 2020-12-09 22:35:47
    为什么要有RDBAOF? Redis数据库基于内存储存数据,而内存的缺点就是当服务器挂掉了,数据就没了。 所以Redis需要持久化来恢复数据,而持久化的方式就有RDBAOF Redis 持久化 RDB 持久化(snapshotting) 把当前...
  • RDB与AOF两种方式都开启时,Redis会优先使用AOF日志来恢复数据,因为AOF保存的文件比RDB文件更完整。 总结 如果你只是单纯把Redis作为缓存服务器,那么可以完全不用考虑持久化,在如今的大多数服务器架构中,...
  • Redis 持久化 RDB AOF

    2021-11-03 13:41:45
    Redis 持久化支持两种方式 RDB AOF,文章记录两者的执行过程配置。 一、RDB RDB 持久化是把当前进程数据生成快照保存到硬盘的过程,触发 RDB 持久化过程分为手动触发和自动触发。 1. save 命令 会堵塞当前 ...
  • redis的rdbaof模式性能对比 系统是 debian testing,kernel 3.2 686。redis 2.4.8。 测试方法是用 python 写的脚本对 redis 数据库进行写入,看写入速度。 100000/300000/1000000 是数据量,插入的都是 string。第...
  • redis持久化的意义,在于故障恢复 比如你部署了一个redis,作为cache缓存,当然也可以保存一些较为重要的数据 如果没有持久化的话,redis遇到灾难性故障的时候,就会...1、RDBAOF两种持久化机制的介绍 rdb和...
  • Redis的持久化RDB与AOF

    2021-09-08 23:15:20
    Redis的持久化RDB与AOF Redis是一个内存数据库,数据保存在内存中,但是内存中的数据在服务器发生故障的时候易丢失,持久化是将内存中数据保存到硬盘中。在Redis中,持久化方式有两种,即快照(RDB)日志(AOF)。 RDB...
  • RDB与AOF孰优孰劣?

    千次阅读 2020-04-28 11:23:43
    RDB AOF RDB 基于内存快照,有两种方式 save 和 bgsave,前者会阻塞 redis 服务,后者是异步 fork 子进程不影响主进程提供服务。大部分情况,我们会通过配置时间间隔触发 RDB 文件写入。RDB 文件中保存的是 redis...
  • Redis中RDB与AOF的区别

    2020-08-18 09:34:42
    redis提供两种方式进行持久化,一种是RDB持久化(原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化),另外一种是AOF持久化(原理是将Reids的操作日志以追加的方式写入文件)。那么这两种持久化方式有...
  • 一、RDB的优缺点 1.1、RDB的优点 (1)RDB文件是紧凑的二进制文件,比较适合做冷备,全量复制的场景。 RDB做会生成多个文件,每个文件都代表了某一个时刻的Redis完整的数据快照; RDB这种多个数据文件的方式,非常...
  • RDB与AOF的比较 RDB: 内存快照形式, 二进制文件体积小,恢复数据速度快,容易丢失数据。 AOF: 存储指令形式, 指令多故而aof文件体积大, 需要一条条执行指令恢复数据故而恢复速度慢,但数据安全性高。 命令 RDB AOF ...
  • 一、前言 由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,于是需要开启redis的持久化功能,将数据保存到磁盘上,当...AOF方式:将Reids的操作命令以追加的方式写入文件,当服务...
  • Redis的两种持久化RDBAOF(超详细)

    千次阅读 多人点赞 2020-10-22 10:01:59
    先通过故事理解一下RDBAOF,再来详细讲讲两者的区别 RDBAOF的故事 我是Redis,一个叫Antirez的男人把我带到了这个世界上。 “快醒醒!快醒醒!”,隐隐约约,我听到有人在叫我。 慢慢睁开眼睛,原来旁边是MySQL...
  • RDB与AOF详解redis

    2019-12-23 20:41:27
    rdb 如何持久化 Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写进一个临时文件中,等到持久化过程结束了,再用这个临时文件替换... 如果要进行大规模数据的恢复,RDB方式要比AOF方式恢复速度要快。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 59,575
精华内容 23,830
关键字:

rdb与aof

友情链接: Chuankou.rar