您的位置:首页 > 数据库 > Redis

浅谈:Redis持久化机制(一)RDB篇

2021-06-04 15:19 1066 查看

浅谈:Redis持久化机制(一)RDB篇

​ 众所周知,redis是一款性能极高,基于内存的键值对NoSql数据库,官方显示,它的读效率可达到11万次每秒,写效率能达到8万次每秒,因为它基于内存以及存读效率高的特性,在市场上的应用中一般都把它作为缓存来使用,同时这也意味着它不能大量的无限制的填充数据,否则容易内存填满,导致redis会向硬盘申请虚拟内存,造成内存和外存的不断I/O,致使效率低下,甚至引起宕机,那么问题来了,既然只是当做缓存而不是为了永久存储数据,redis为什么要做持久化呢?这样做有什么意义呢?

1.为什么要做持久化

  • 第一点要明确,redis作为内存数据库,宕机后就会发生数据消失,之所以要去做持久化只是为了能在重启之后快速的恢复数据,而不是存储数据;redis的持久化并不能够保证数据的完整性.
  • 当然,如果要把redis当做DB用,DB数据要完整,所以需要一个完整的数据源(比如mysql),当启动时将数据源的数据全部加载到redis里面,这只适用于数据量小的不易改变的,比如:字典库。像mysql那样大量的存储数据是行不通的。

2.RDB(redis database)

​ 说完redis持久化的原因,我们再详聊一下redis做持久化的第一种方式RDB,这种方式也是redis默认的一种持久化方式,默认是开启的。

​ 从字面上来看,RDB也就是redis database,翻译成中文就是redis 数据库,也就是说这种持久化方式就是像数据库一样存储了数据,当然事实上也是这样的,RDB方式是通过存储快照数据来完成的,既然是快照数据,那就是说明这种方式只关注了某一刻缓存的数据状态,关注的是那一刻数据是什么,它并没有去记录这个数据变更的一系列过程。也就是说,RDB持久化方式关注的是数据存储的结果,而非是数据存储的过程。

​ 另外,既然是快照数据,redis又要保证性能,因此要明白RDB持久化时肯定不会是实时的,肯定是隔一段时间触发一次,否则的话redis作为一个单线程处理的服务,光顾着去持久化数据了,怎么还有时间处理来自客户端的请求访问,这也就说明了由于有时间间隔,redis的RDB方式的持久化会丢失最后一次持久化后的数据,这也就表明了redis的持久化没有办法保证数据的完整性。

2.1 触发快照的方式

  • 配置参数定期执行(在redis.conf中配置:save 多少秒内 数据变了多少)
save ""  # 不使用RDB存储  不能主从
save 900 1  # 表示15分钟(900秒钟)内至少1个键被更改则进行快照。
save 300 10 # 表示5分钟(300秒)内至少10个键被更改则进行快照。
save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。
  • 命令显式触发(save或者bgsave命令)

    127.0.0.1:6379> bgsave
    Background saving started
  • 2.2 RDB执行流程

    1.redis父进程首先判断,当前是否正在执行save,如果正在执行,则先返回。

    2.父进程fork()复制出子进程,在这个过程中父进程是阻塞的,不再处理redis接收到的其他命令。当父进程fork结束,又可以重新处理工作。

    3.子进程创建RDB文件,根据父进程的内存快照生成临时快照文件,完成后对原有的文件进行替换。始终保持RDB文件的完整性。

    4.子进程生成RDB文件完成后,就响应信息给父进程,父进程更新统计信息。

    2.3 RDB文件结构

    1、头部5字节固定为“REDIS”字符串
    2、4字节“RDB”版本号(不是Redis版本号),当前为9,填充后为0009
    3、辅助字段,以key-value的形式

    字段名 字段值 字段名 字段值
    redis-ver 5.0.5 aof-preamble 是否开启aof
    redis-bits 64/32 repl-stream-db 主从复制
    ctime 当前时间戳 repl-id 主从复制
    used-mem 使用内存 repl-offset 主从复制

    4、存储数据库号码
    5、字典大小6、过期key
    7、主要数据,以key-value的形式存储
    8、结束标志
    9、校验和,就是看文件是否损坏,或者是否被修改。

    2.4 RDB的优缺点

    优点:

  • RDB是二进制压缩文件,占用空间小,便于传输。(做主从复制时传递给slaver效率也很高)
  • 通过主进程fork复制子进程,由子进程完成持久化的方式,这样可以最大化的保证redis的性能。但是前提条件是redis的数据量不能太大,否则fork的过程太长,容易造成阻塞。

缺点:

  • 不能保证数据的完整性,会丢失最后一次fork之后的数据。例如,redis进行持久化的操作是1分钟一次,当上次持久化完成后的30秒内,新添加了5000个数据,那么redis发生宕机然后重新恢复时,那30秒的数据会丢失。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: