Redis之RDB和AOF持久化介绍

什么是数据库状态

  redis是一个键值对的数据库服务器,服务器中通常包含中任意个非空的数据库,而每个数据库又可以包含任意个键值对,为了方便起见,我们将服务器中的非空数据库以及他们的键值对统称为数据库状态。

RDB持久化的逻辑

  RDB持久化就可以手动执行也可以根据服务器配置选项定期的执行,该功能可以将某个时间点上的数据库状态保存到一个RDB文件中,这个文件其实是一个二进制的文件,通过这个文件可以还原生成RDB文件时的数据库状态。

RDB文件的创建

  有两个生成redisRDB文件的命令,一个是SAVE,一个是BGSAVE。SAVE命令是使用服务器进程来生成RDB文件,在生成RDB文件的时候,会阻塞所有的读写操作,服务器不能处理任何命令请求。BGSAVE命令是同过服务器进程派生出来一个子进程,然后有子进程负责创建RBD文件,服务器进程可以继续处理命令请求。

  其实创建RDB文件的工作都是通过rdbsave函数实现的是不过两种命令以不同的方式调用这个函数。

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

  其实这个很简单,我们上面已经提到过SAVE命令或阻塞一切请求,当然拥抱口BGSAVE请求了,所以在执行SAVE期间,再次执行BGSAVE命令会被直接拒绝。

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

  我们知道BGSAVE命令是服务器的子进程来完成的,服务器进程可以继续接收和执行命令,但是再BGSAVE命令执行期间服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式和平时有所不同,主要有一下几种情形:

  1.在BGSAVE命令执行期间,客户端发起的SAVE命令会被服务器拒绝。服务器禁止SAVE命令和BGDAVE命令同时执行是为了避免父进程和子进程同时执行两个rdbsave调用,防止产生竞争条件。

  2.在BGSAVE命令执行期间客户端发起BGSAVE命令会被服务器拒绝,因为同时执行两个BGSAVE命令也会产生竞争条件

  3.在BGSAVE命令执行期间,客户端发起BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行

  4.在BGREWRITEAOF命令执行期间,客户端发起BGSAVE命令会被服务器直接拒绝,主要是因为BGREWRITEAOF和BGSAVE命令都是由子进程来完成的,禁止他们同时执行知识一个性能方面的考虑,因为并发出两个子进程,并且这两个子进程同时进行大量的磁盘写入操作,并不是什么好事情。

RDB文件的载入

  对于RDB文件的载入就相对简单了,RDB文件的载入工作是在服务器启动的时候自动执行的,并且在服务器载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止。

RDB自动间歇性保存

  上面我们讲了如何创建RDB文件,但是什么时候来创建RBD文件呢?除了手动的执行命令之外,我们还可以通过配置来让服务器自动来创建RDB文件,我们可以在redis的配置文件中通过以下配置来实现:

save    900    1
save    300    10
save     60     10000

  用户可以通过save选项设置多个保存条件(当然可以超过三个了,十个八个都可以,因为这些保存条件其实是保存在一个数组中的),但是只要其实任意一个条件满足,服务器就会执行BGSAVE命令。而上面的三条保存配置其实也是在我们开启了RDB持久化但是没有配置相关保存条件下时服务器给的默认的配置。

RDB自动保存的触发原理

  我们知道了如何配置保存条件的,但是这个保存条件是怎么触发的呢?

  其实服务器除了通过一个数据存储我们的保存条件外,还会维持一个dirty的计数器,以及一个lastsave属性,其中dirty计数器用来统计距离上一次成功执行SAVE命令或者BGSAVE命令后服务器对数据库状态进行了多少次修改(包括写入,删除,更新等操作),而lastsave属性是一个UNIX的时间戳,记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间。这两个值都会在成功执行完BGSAVE命令后重置:dirty重置成0,lastsave更新为当前时间。

  而对于条件的判断则是Redis服务器会周期性的操作函数serverCron默认每隔100毫秒执行一次,该函数用于对正在运行的服务器进行维护,它的其中一项工作就是检查save选项所设置的保存条件是否满足,如果满足则执行BGSAVe命令。必须同时满足的条件是:1.距离上一次成功执行保存的时间超过设置的时间,2.数据库状态的修改次数超过设置的修改次数

RDB的文件结构

暂略

原文地址:https://www.cnblogs.com/htyj/p/11731396.html

时间: 2024-10-08 02:06:42

Redis之RDB和AOF持久化介绍的相关文章

redis的 rdb 和 aof 持久化的区别 [转]

aof,rdb是两种 redis持久化的机制.用于crash后,redis的恢复. rdb的特性如下: Code: fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来.save, shutdown, slave 命令会触发这个操作.粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复. aof有如下特性: Code: 把写操作指令,持续的写到一个类似日志文件里.(类似于从postgresql等数

Redis中RDB和AOF持久化区别和联系

RDB和AOF持久化   ?RDB持久化 RDB是什么? 原理是redis会单独创建(fork) 一个与当前进程一模一 样的子进程来进行持久化,这个子进程的所有数据(变量.环境变量,程序程序计数器等)都和原进程一模一 样,会先将数据写入到一个临时文件中,待持久化结束了,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程不进行任何的io操作,这就确保了极高的性能 1.这个持久化文件在哪里 RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘.也是默认的持久化方式,这种方式是就是将

redis的rdb与aof持久化机制

Redis提供了两种持久化方案:RDB持久化和AOF持久化,一个是快照的方式,一个是类似日志追加的方式 RDB快照持久化 RDB持久化是通过快照的方式,即在指定的时间间隔内将内存中的数据集快照写入磁盘.在创建快照之后,用户可以备份该快照,可以将快照复制到其他服务器以创建相同数据的服务器副本,或者在重启服务器后恢复数据.RDB是Redis默认的持久化方式 save 900 1 当时间到900秒时,如果至少有1个key发生变化,就会自动触发bgsave命令创建快照 save 300 10 当时间到3

redis的 rdb 和 aof 持久化的区别

aof,rdb是两种 redis持久化的机制.用于奔溃后,redis的恢复. rdb的特性如下: Code: fork一个进程,遍历hash table,利用copy on write,把整个db dump保存下来.save, shutdown, slave 命令会触发这个操作.粒度比较大,如果save, shutdown, slave 之前crash了,则中间的操作没办法恢复. aof有如下特性: Code: 把写操作指令,持续的写到一个类似日志文件里.(类似于从postgresql等数据库导

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

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

003.图解分析 redis 的 RDB 和 AOF 两种持久化机制的工作原理

目录 RDB AOF 小结 参考 我们已经知道对于一个企业级的 redis 架构来说,持久化是不可减少的 tip 牢记企业级 redis 集群架构是用来支撑海量数据.高并发.高可用 持久化主要是做灾难恢复.数据恢复,也可以归类到高可用的一个环节里面去 比如你 redis 整个挂了,redis 就不可用了,你要做的事情是让 redis 变得可用,尽快变得可用你会怎么做? 你会重启 redis,尽快让它对外提供服务,但是就像上一讲说,如果你没做数据备份,这个时候 redis 就算启动了,也不可用,数

004.redis 的 RDB 和 AOF 两种持久化机制的优劣势对比

目录 RDB 持久化机制的优点 RDB 持久化机制的缺点 AOF 持久化机制的优点 AOF 持久化机制的缺点 RDB 和 AOF 到底该如何选择 参考 RDB 持久化机制的优点 适合做冷备 RDB 会生成多个数据文件,每个数据文件都代表了某一个时刻中 redis 的数据,这种多个数据文件的方式,非常适合做冷备,可以将这种完整的数据文件发送到一些远程的安全存储上去,如云上,以预定好的备份策略来定期备份 redis 中的数据 性能影响小 能让 redis 对外提供的读写服务不受影响,因为 redis

Redis 详解 (七) AOF 持久化

目录 1.AOF简介 2.AOF 配置 3.开启 AOF 4.AOF 文件恢复 5. AOF 重写 6.AOF的优缺点 上一篇文章我们介绍了Redis的RDB持久化,RDB 持久化存在一个缺点是一定时间内做一次备份,如果redis意外down掉的话,就会丢失最后一次快照后的所有修改(数据有丢失).对于数据完整性要求很严格的需求,怎么解决呢? 本篇博客接着来介绍Redis的另一种持久化方式——AOF. 回到顶部 1.AOF简介 Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库

Redis的RDB和AOF

1.数据快照RDB 1.1原理 (1)RDB是将某一时刻的数据持久化到磁盘中,是一种快照的方式. (2)redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件.正是这种特性,让我们可以随时来进行备份,及时redis处于运行状态: (3)对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而主进程是不会进行任何IO操作的,这样就确保了redis极高的性能. (4)如果需要进行大规模数据的恢复,且对于数据