redis 系列16 持久化 RDB

原文:redis 系列16 持久化 RDB

一.概述

  Redis是内存数据库,一旦服务器进程退出,服务器中的数据库内存数据状态也会消失。为了解决这个问题,Redis提供了RDB 持久化功能,这个功能可以将redis在内存中的数据库状态保存到磁盘中,避免数据意外丢失。

  RDB持久化可以手动执行,也可以根据服务器配置选项定期执行,是在指定的时间间隔,对你的数据进行快照存储。该RDB文件快照是一个经过压缩的二进制文件。文件名为dump.rdb,该文件保存在redis目录下,当redis服务器停机后,只要RDB文件存在,下次重启Redis服务时就会自动还原数据库数据状态。

  1.1 RDB文件的创建

    通过Redis两个命令来生成RDB文件,一是SAVE,另一个是BGSAVE。SAVE命令是会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在阻塞期间,服务器不能处理任何命令请求。

    127.0.0.1:6379> save   -- 等待RDB文件创建完毕
    OK    

    与SAVE不同,BGSAVE命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程(父进程)继续处理命令请求。当BGSAVE命令在执行期间,客户端再发送BGSAVE命令会被服务器拒绝,因为同时执行两个GBSAVE命令也会产生竞争条件。最后BGREWRITEAOF和GBSAVE两个命令也不能同时执行。

    127.0.0.1:6379> bgsave  --派生子进程,并由子进程创建RDB文件
    Background saving started

  

  1.2 RDB文件载入

    和创建文件不同,RDB文件的载入是在服务器启动时自动执行的,并没有用于载入RDB文件的命令,只要Redis服务器在启动时检测到RDB文件的存在,它就会自动载入RDB文件。能过启动时日志记录可以查看。需要注意的是,如果打开了AOF持久化,那么服务器会优先使用AOF文件来还原数据库状态。

  

  1.3 自动间隔性保存

    文件的创建除了SAVE和GBSAVE保存RDB 文件,还可以通过配置SAVE选项,让服务器每隔一段时间自动执行一次BGSAVE命令。可以配置SAVE选项设置多个保存条件,只要任意一个条件被满足,服务器就会执行BGSAVE命令。

    --默认配置的SAVE选项,保存方式有三种条件,满足任意一种就可以,如下:
    127.0.0.1:6379> config get save
    1) "save"
    2) "900 1 300 10 60 10000"

    (1) 服务器在900秒之内,对数据库进行了至少1次修改。

    (2) 服务器在300秒之内,对数据库进行了至少10次修改。

    (3) 服务器在60秒之内,对数据库进行了至少10000次修改。

  1.4 检查保存条件是否满足

    Redis的服务器周期性操作默认每隔100毫秒就会检查执行一次,用于对正在运行的服务器进行维护,其中一项工作是检查save 选项所设置的保存条件是否已经满足,如果满足就调用BGSAVE命令。

  1.5  RDB工作方式

    当Redis需要保存dump.rdb文件时,服务器执行以下操作:

    (1)Redis调用forks. 同时拥有父进程和子进程。

    (2)子进程将数据集写入到一个临时 RDB 文件中。

    (3)当子进程完成对新 RDB 文件的写入时,Redis用新 RDB 文件替换原来的 RDB 文件,并删除旧的 RDB 文件。

  

  1.6  RDB 文件结构

    下面简单了解一下RDB文件结构,这里不再深入了解。下面脚本显示了本机dump.rdb文件的位置。该rdb文件结构中各部分 如下图表格所示:

    [[email protected] redis]# pwd
    /usr/local/redis
    [[email protected] redis]# ls -l
    -rwxrwxrwx 1 root root    1687 11月 22 10:03 dump.rdb

文件结构各部份


描述


redis


RDB文件最开头是REDIS部分,保存五个字符,程序在载入文件时,快速检查所载入的文件是否是RDB文件


Db_version


一个字符串表示的整数,4个字节,记录了RDB文件的版本号


databases


该部份包含着0个或任意多个数据库,以及各数据库中的键值对数据


Eof


占1个字节,标志着RDB文件正文内容的结束,当程序遇到这个值的时候,就知道所有数据库的所有键值对都已经载入完毕了


Check_sum


占8字节的无符号整数,保存一个校验和,通过前四部分内容进行计算得出。用来检查RDB文件是否出错或者损坏

    下面通过linux的od命令来查看redis服务器产生的RDB 文件,并指定-c参数可以以ASCII编码方式打印信息。信息中能直接看到的信息是:第一部分是redis,  Db_version部分是0008, Eof部分是372 。

  

  1.7  RDB优势

    (1) RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。

    (2)RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心,非常适用于灾难恢复。

    (3)RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能。

    (4)与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些。

  

  1.8  RDB缺点

    (1)如果数据不允许任何丢失,那么RDB不适合(虽然可以配置不同的save时间点)。

    (2)经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求。

二. RDB持久化测试

    (1) 首先关闭redis服务。当关闭服务时报错,首先检查一下是否是权限的问题,因为在shutdown命令的时候,会进行save操作,而save需要操作dump.rdb文件,如果没有权限则会报这个错。

    [[email protected] redis]# redis-cli shutdown
    (error) ERR Errors trying to SHUTDOWN. Check logs
    -- 需要放开对dump.rdb文件的写入权限,服务关闭成功
    [[email protected] redis]# redis-cli shutdown
    [[email protected] redis]# redis-cli

    (2) 服务启动,首先set 写入一条数据,然后关闭服务进程。

    [[email protected] redis]$ redis-serverredis.conf
    127.0.0.1:6379> set name "test"
    OK
    127.0.0.1:6379> get name
    "test"
    127.0.0.1:6379> exit
    [[email protected] redis]$ redis-cli shutdown

    (3)重次重启服务,查看持久化

    查看刚才的键值对,发现键值对已存在,说明数据持久化保存到了磁盘中,原理是在关闭服务时,会先调用save操作,保存到dump.rdb文件中,在重启服务后,加载dump.rdb文件。

    [[email protected] redis]$ redis-serverredis.conf
    [[email protected] redis]$ redis-cli
    127.0.0.1:6379> get name
    "test"

   

  总结:作为RDB快照持久化,如果是正常关闭redis服务,再重启后数据是不会丢失的,但如果系统崩溃或者强杀,用户将会丢失最近一次生成快照之后更改的所有数据。

  

  

原文地址:https://www.cnblogs.com/lonelyxmas/p/10230763.html

时间: 2024-11-05 19:01:36

redis 系列16 持久化 RDB的相关文章

进阶的Redis之数据持久化RDB与AOF

大家都知道,Redis之所以性能好,读写快,是因为Redis是一个内存数据库,它的操作都几乎基于内存.但是内存型数据库有一个很大的弊端,就是当数据库进程崩溃或系统重启的时候,如果内存数据不保存的话,里面的数据就会丢失不见了.这样的数据库并不是一个可靠的数据库. 所以数据的持久化是内存型数据库的重中之重.它不仅提供数据保存硬盘的功能,还可以借此用硬盘容量扩展数据存储空间,使得Redis的可以存储超过机器本身内存大小的数据. Redis对于数据持久化提供了两种持久化的方案,RDB与AOF.它们的原理

redis学习之——持久化RDB 和AOF

RDB: 在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里.rdb 保存的是dump.rdb文件 RDB工作原理: Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件.整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方,式要比AOF方式更加

redis 系列17 持久化 AOF

一.概述 除了上篇介绍的RDB持久化功能之外,Redis还提供了AOF(Append Only File)持久化功能.与RDB保存数据库中的键值对来记录数据库状态不同,AOF是通过保存redis服务器所执行的写命令来记录数据库状态的.AOF持久化方式记录每次对服务器写的操作,当服务器启动时,就会通过载入和执行AOF文件中保存的命令来还原服务器关闭之前的数据库状态,并在服务器载入AOF文件并还原数据库状态时打印日志. 被写入AOF文件的所有命令都是纯文本格式,可以直接打开一个AOF文件来观察.所有

面试系列16 redis的持久化

1.RDB和AOF两种持久化机制的介绍 RDB持久化机制,对redis中的数据执行周期性的持久化 AOF机制对每条写入命令作为日志,以append-only的模式写入一个日志文件中,在redis重启的时候,可以通过回放AOF日志中的写入指令来重新构建整个数据集 如果我们想要redis仅仅作为纯内存的缓存来用,那么可以禁止RDB和AOF所有的持久化机制 通过RDB或AOF,都可以将redis内存中的数据给持久化到磁盘上面来,然后可以将这些数据备份到别的地方去,比如说阿里云,云服务 如果redis挂

Redis两种持久化方式(RDB&AOF)

爬虫和转载请注明原文地址;博客园蜗牛:http://www.cnblogs.com/tdws/p/5754706.html Redis所需内存 超过可用内存怎么办 Redis修改数据多线程并发—Redis并发锁 windows下redis基础操作与主从复制 从而 数据备份和读写分离 Redis两种持久化方式(RDB&AOF) Redis的持久化过程中并不需要我们开发人员过多的参与,我们要做的是什么呢?除了深入了解RDB和AOF的作用原理,剩下的就是根据实际情况来制定合适的策略了,再复杂一点,也就

Redis提供的持久化机制(RDB和AOF)

Redis提供的持久化机制 Redis是一种高性能的数据库,可以选择持久化,也可以选择不持久化. 如果要保存,就会存在数据同步的问题,可以简单认为一份数据放在内存中(快照),一份数据放在磁盘上,Redis提供了很灵活的持久化办法: Redis提供了RDB持久化和AOF持久化,本篇文章中将会对这两种机制进行一些对比 RDB机制的优势和略施 RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘. 也是默认的持久化方式,这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为

第十章 Redis持久化--RDB+AOF

注:本文主要参考自<Redis设计与实现> 1.Redis两种持久化方式 RDB 执行机制:快照,直接将databases中的key-value的二进制形式存储在了rdb文件中 优点:性能较高(因为是快照,且执行频率比aof低,而且rdb文件中直接存储的是key-values的二进制形式,对于恢复数据也快) 缺点:在save配置条件之间若发生宕机,此间的数据会丢失 AOF 执行机制:将对数据的每一条修改命令追加到aof文件 优点:数据不容易丢失 缺点:性能较低(每一条修改操作都要追加到aof文

Redis的持久化--RDB的工作原理及引发的问题

Redis持久化RDB模式的工作原理: Redis持久化RDB模式,Redis借助了fork命令的copy on write机制.在生成快照时,将当前进程整个复制出来,fork出一个子进程,然后在子进程中循环所有的数据,将数据写成为RDB文件. Redis持久化RDB模式引发的问题: RDB模式需要Redis服务所占内存的1倍的内存 例如一台机器总共16G内存,用了10G内存做Redis服务,假如这10G内存都占满了 这时运行save命令,这时会把10G的进程再复制一遍,变成20G,超过了16G

Redis持久化-RDB

Redis持久化-RDB Redis的持久化分为RDB持久化和AOF持久化,本篇文章主要说RDB持久化相关的东西. RDB持久化就是把当前redis数据库中的数据保存到硬盘的过程. 触发时机 RDB持久化的触发方式有两种,第一种是手动触发,另外一种是自动触发. 手动触发 手动触发RBD主要使用save和bgsave命令.其实bgsave是对save命令阻塞问题的优化,因此你应该总是使用bgsave命令. save save命令会阻塞当前主进程,直到RDB持久化过程执行完毕,对于内存比较大的实例会