Redis实现之RDB持久化(一)

RDB持久化

Redis是一个键值对数据库服务器,服务器中通常包含着任意个非空数据库,而每个非空数据库中又可以包含任意个键值对,为了方便起见,我们将服务器中的非空数据库以及它们的键值对统称为数据库状态。举个栗子,图1-1展示了一个包含三个非空数据库的Redis服务器,这三个数据库以及数据库中的键值对就是该服务器的数据库状态

图1-1   数据库状态示例

因为Redis是内存数据库,它将自己的数据库状态存储在内存里面,所以如果不想办法将存储在内存中的数据库状态保存到磁盘中,那么一旦服务器进程退出,服务器中的数据库状态也会消失。为了解决这个问题,Redis提供了RDB持久化功能,可以将Redis内存中的数据库状态保存到磁盘中,避免数据意外丢失

RDB持久化既可以手动执行,也可以根据服务器配置选项定期执行,该功能可以将某个时间点上的数据库状态保存到一个RDB文件中,如图1-2所示

图1-2   将数据库状态保存为RDB文件

RDB持久化功能所生成的RDB文件是一个经压缩的二进制文件,通过该文件可以还原生成RDB文件时的数据库状态,如图1-3所示

图1-3   用RDB文件来还原数据库状态

因为RDB文件是保存在硬盘中的,所以即使Redis服务器进程退出,甚至运行Redis服务器的计算机停机,但只要RDB文件还在,Redis服务器就可以用它来还原数据库状态

RDB文件的创建和载入

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

127.0.0.1:6379> SAVE			#等待直到RDB文件创建完毕
OK

  

和SAVE命令直接阻塞服务器进程的做法不同,BGSAVE命令会派生出一个子进程,然后由子进程负责创建RDB文件,服务器进程(父进程)继续处理命令请求:

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

  

创建RDB文件的实际工作由rdb.c/rdbSave函数完成,SAVE命令和BGSAVE命令会以不同的方式调用这个函数,通过以下伪代码可以明显看出这两个命令之间的区别:

def SAVE():
	#创建RDB文件
	rdbSave()

def BGSAVE():
    #创建子进程
    pid = fork()
    if pid == 0:
        #子进程负责创建RDB文件
        rdbSave()
        #完成之后向父进程发出信号
        signal_parent()
    elif pid > 0:
        #父进程继续处理命令请求,并通过轮询等待子进程信号
        handle_request_and_wait_signal()
    else:
        #处理出错情况
        handle_fork_error()

  

和使用SAVE命令或者BGSAVE命令创建RDB文件不同,RDB文件的载入工作是在服务器启动时自动执行的,所以Redis并没有专门用于载入RDB文件的命令,只要Redis服务器在启动时检测到RDB文件的存在,它就会自动载入RDB文件

以下是Redis服务器启动时打印的日志记录其中第二条DB loaded from disk:……就是服务器成功载入RDB文件之后打印的:

17859:S 18 Aug 11:26:16.363 # Server started, Redis version 3.0.0
17859:S 18 Aug 11:26:56.802 * DB loaded from disk: 36.336 seconds
17859:S 18 Aug 11:26:56.802 * The server is now ready to accept connections on port 6379

  

另外值得一提的是,因为AOF文件的更新频率通常比RDB文件的更新频率高,所以:

  • 如果服务器开启了AOF持久化功能,那么服务器就会优先使用AOF文件来还原数据库状态
  • 只有在AOF持久化功能处于关闭状态时,服务器才会使用RDB文件来还原数据库状态

服务器判断该用哪个文件来还原数据库状态的流程如图1-4所示

图1-4   服务器载入文件时的判断流程

载入RDB文件的实际工作由rdb.c/rdbLoad函数完成,这个函数和rdbSave函数之间的关系可以用图1-5表示

图1-5   创建和载入RDB文件

SAVE命令执行时的服务器状态

前面提到过,当SAVE命令执行时,Redis服务器会被阻塞,所以当SAVE命令正在执行时,客户端发送的所有命令请求都会被拒绝。只有在服务器完成SAVE命令、重新开始接受命令请求之后,客户端发送的命令才会被处理

BGSAVE命令执行时的服务器状态

因为BGSAVE命令的保存工作是由子进程执行的,所以在子进程创建RDB文件的过程中,Redis服务器仍然可以继续处理客户端的命令请求,但是,在BGSAVE命令执行期间,服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式会和平时有所不同

首先,在BGSAVE命令执行期间,客户端发送的BGSAVE命令会被服务器拒绝,因为同时执行两个BGSAVE命令也会产生竞争条件。然后,BGREWRITEAOF和BGSAVE两个命令不能同时执行:

  • 如果BGSAVE命令正在执行,那么客户端发送的BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后再执行
  • 如果BGREWRITEAOF命令正在执行,那么客户端发送的BGSAVE命令会被服务器拒绝

因为BGSAVE和BGREWRITEAOF两个命令的实际工作都由子进程执行,所以这两个命令在操作方面并没有什么冲突的地方,不能同时执行它们只是一个性能方面的考虑——并发处两个子进程,并且两个子进程都同时执行大量的磁盘写入操作,对CPU是极大的消耗,要是数据库存储的键值对庞大,对内存的消耗想想都觉得恐怖

RDB文件载入时的服务器状态

服务器在载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止

自动间隔性保存

在上一节,我们介绍了SAVE命令和BGSAVE的实现方法,并且说明了这两个命令在实现方面的主要区别:SAVE命令由服务器进程执行保存工作,BGSAVE命令则由子进程执行保存工作,所以SAVE命令会阻塞服务器,而BGSAVE命令则不会

因为BGSAVE命令可以在不阻塞服务器的情况下执行,所以Redis允许用户通过没设置服务器配置的save选项,让服务器每隔一段时间自动执行一次BGSAVE命令。用户可以通过save选项设置多个保存条件,但只要其中一个条件被满足,服务器就会执行BGSAVE命令。举个栗子,如果我们向服务器提供以下配置:

save 	900 	1
save 	300 	10
save 	60 		10000

  

那么只要满足以下三个条件中的任意一个,BGSAVE命令就会被执行:

  • 服务器在900秒内对数据库进行了至少一次的修改
  • 服务器在300秒内对数据库进行了至少十次的修改
  • 服务器在60秒内对数据库进行了至少一万次的修改

设置保存条件

当Redis启动时,用户可以通过指定配置文件或传入启动参数的方式设置save选项,如果用户没有主动设置save选项,那么服务器会为save选项设置默认条件:

save 	900 	1
save 	300 	10
save 	60 		10000

  

接着,服务器会根据save选项所设置的保存条件,设置服务器状态redisServer结构体的saveparams属性:

redis.h

struct redisServer {
	……
	//记录了保存条件的数组
    struct saveparam *saveparams;
    ……
};

  

saveparams属性是一个数组,数组中每个元素都是一个saveparam结构体,每个saveparam结构体都保存了一个save选项设置的保存条件:

redis.h

struct saveparam {
	//秒数
    time_t seconds;
	//修改数
    int changes;
};

  

比如说,如果save选项的值为以下条件:

save 	900 	1
save 	300 	10
save 	60 		10000

  

那么服务器状态中的saveparams数组将会是图1-6所示的样子

图1-6   服务器状态中的保存条件

dirty计数器和lastsave属性

除了saveparams数组之外,服务器状态还维持着一个dirty计数器,以及一个lastsave属性:

  • dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后,服务器对数据库状态(服务器中的所有数据库)进行了多少次修改(包括写入、删除、更新等操作)
  • lastsave属性是一个Unix时间戳,记录了服务器上一次成功执行SAVE命令或BGSAVE命令的时间

redis.h

struct redisServer {
	……
	//修改计数器
    long long dirty;
    ……
	//上一次执行保存的时间
    time_t lastsave;
    ……
};

  

当服务器成功执行一个数据库修改命令后,程序就会对dirty计数器进行更新:命令修改了多少次数据库,dirty计数器的值就会增加多少。例如,如果我们为一个字符串键设置值:

127.0.0.1:6379> SET message "hello"
OK

  

那么程序会将dirty计数器的值加1。又比如,如果我们向一个集合键增加三个元素:

127.0.0.1:6379> SADD database Redis MongoDB MariaDB
(integer) 3

  

那么程序会将dirty计数器的值加3

图1-7展示了服务器状态中包含的dirty计数器和lastsave属性,说明如下:

  • dirty计数器的值为123,表示服务器在上次保存之后,对数据库状态共进行了123次修改
  • lastsave属性则记录了服务器上次执行保存操作的时间1378270800(2013年9月4日零时)

图1-7   服务器状态示例

检查保存条件是否满足

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

以下伪代码展示了serverCron函数检查保存条件的过程:

def serverCron():
	# …
    # 遍历所有保存条件
    for saveparam in server.saveparams:
         # 计算距离上次执行保存操作有多少秒
         save_interval = unixtime_now()-server.lastsave    

        # 如果数据库状态的修改次数超过条件所设置的次数
        # 并且距离上次保存的时间超过条件所设置的时间
        # 那么执行保存操作
         if      server.dirty >= saveparam.changes and                    save_interval > saveparam.seconds:       

                BGSAVE();
     # ...

  

程序会遍历并检查saveparams数组中的所有保存条件,只要有任意一个条件被满足时,那么服务器就会执行BGSAVE命令。举个栗子,如果Redis服务器的当前状态如图1-8所示

图1-8   服务器状态

那么当时间来到1378271101,也即是1378270800的301秒之后,服务器将自动执行一次BGSAVE命令,因为saveparams数组的第二个保存条件——300秒内有至少十次修改的条件已满足

假设BGSAVE在执行五秒后完成,那么图1-8所示的服务器状态将更新为图1-9所示,其中dirty计数器被重置为0,而lastsave属性也被更新为1378271106

图1-9   执行BGSAVE之后的服务器状态

以上就是Redis服务器根据save选项所设置的保存条件,自动执行BGSAVE命令,进行间隔性数据保存的实现原理

原文地址:https://www.cnblogs.com/beiluowuzheng/p/9739962.html

时间: 2024-10-12 02:26:14

Redis实现之RDB持久化(一)的相关文章

redis中的RDB持久化详解

1. 如何在redis中配置RDB持久化文件 在redis持久化中  默认是开启RDB模式的.这里我们只需要对RDB进行配置即可 在上面有三个配置选项 分别是 每隔900秒  有一条key进行变更 每个300秒 有10条key进行变更 没隔60秒  有10000条key进行变更. 以上任意条达成条件后,就会重新生成一个dump.rdb文件.就是当前redis内存中完整的快照,这个操作也被称之为snapshotting,快照也可以手动调用save或者bgsave命令,同步或异步执行rdb快照生成

Redis 学习 ---- 10.RDB持久化

10.1 RDB文件的创建和载入 有俩个Redis命令可以用于生成RDB文件,一个是SAVE,另一个是BGSAVE. SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止. BGSAVE命令会派生出一个子金城关负责创建RDB文件,服务器进程继续处理命令请求. RDB文件的载入工作是在服务器启动时自动执行的,因为AOF文件的更新频率通常比RDB文件的更新频率高,所以: ① 如果服务器开启了AOF持久化功能,那么服务器会优先使用过AOF文件来还原数据库状态: ② 只有在AOF持久化功能

Redis AOF、RDB持久化

RDB: AOF: 原文地址:https://www.cnblogs.com/Joy-Hu/p/8320326.html

redis之RDB持久化

Redis是一个键值对数据库服务器,服务器中通常包含着任意个非空数据库,而每个非空数据库中又可以包含任意个键值对,为了方便起见,我们将服务器中的非空数据库以及它们的键值对统称为数据库状态. 因为Redis是内存数据库,它将自己的数据库状态储存在内存里面,所以如果不想办法将储存在内存中的数据库状态保存到磁盘里面,那么一旦服务器进程退出,服务器中的数据库状态也会消失不见.为了解决这个问题,Redis提供了RDB持久化功能,这个功能可以将Redis在内存中的数据库状态保存到磁盘里面,避免数据意外丢失.

03.Redis单实例部署之基于RDB持久化

一.部署Redis单实例[RDB持久化] ## 操作系统环境说明 [[email protected] ~]# cat /etc/redhat-release;uname -r;uname -m; CentOS Linux release 7.5.1804 (Core) 3.10.0-862.el7.x86_64 x86_64 [[email protected] ~]# firewall-cmd --state ## 查看firewall墙的状态 not running [[email pro

redis 源码学习(RDB 持久化)

redis是个内存数据库,所有的操作都是在内存中进行,但是内存有个特点是,程序出问题或者系统出问题.重启,关机都会造成内存数据丢失. 所以需要把内存中的数据dump到硬盘中备份起来. RDB持久化,是内存数据库dump到硬盘的过程,其中RDB是个文件格式,待会介绍. 本文从两个方向剖析, 1)加载dump.rdb文件到内存中. 2)内存数据库dump到硬盘中dump.rdb文件. 加载dump.rdb文件到内存 main函数入口: int main(int argc, char **argv)

八、Redis 基础命令---管理--持久化--RDB

1.Redis 支持两种方式的持久化,一种是RDB , 一种是AOF .可用单独使用也可以二者结合使用. 2.RDB A.RDB方式是Redis默认采用的持久化方式,通过快照(snapshotting)完成的.当符合一定条件时Redis会自动将内存中的所有数据进行快照并存储在整个硬盘上.进行快照的条件:时间和改动的键的个数.当在指定的时间内被更改的键的个数大于指定的数值时就会进行快照. B.配置文件中已经预先设置了3个条件: save 900 1 save 300 10 save 60 1000

[redis读书笔记] 第二部分 单机数据库 RDB持久化

内存中的rdb是会存为文件以做到RDB持久化的.RDB文件时一个二进制文件. 一 载入与存储 文件的载入是在server启动时进行的(rdbload()),因为AOF的更新频率比RDB高,所以如果AOF持久化功能开启,服务器会优先从AOF还原DB,只有AOF关闭,才从RDB还原数据库. 文件的存储由rdbSave()/rdb.c来实现,SAVE/BGSAVE 命令可以触发,前者直接由Redis server处理,此时不能处理其他命令,后者会启动子进程进行处理,此时server可以处理其他命令,但

redis学习笔记——RDB和AOF持久化

为防止数据丢失,需要将 Redis 中的数据从内存中 dump 到磁盘,这就是持久化.Redis 提供两种持久化方式:RDB 和 AOF.Redis 允许两者结合,也允许两者同时关闭. RDB 可以定时备份内存中的数据集.服务器启动的时候,可以从 RDB 文件中恢复数据集. AOF(append only file) 可以记录服务器的所有写操作.在服务器重新启动的时候,会把所有的写操作重新执行一遍,从而实现数据备份.当写操作集过大(比原有的数据集还大),Redis 会重写写操作集. 值得一提的是