一篇文章揭秘Redis的磁盘持久化机制

前言

Redis 是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将 Redis 中的数据以数据或命令的形式从内存保存到本地磁盘。当下次 Redis 重启时,利用持久化文件进行数据恢复。Redis 提供了 RDB 和 AOF 两种持久化机制,前者将当前的数据保存到磁盘,后者则是将每次执行的写命令保存到磁盘(类似于 MySQL 的 Binlog)。本文将详细介绍 RDB 和 AOF 两种持久化方案,包括操作方法和持久化的实现原理。

正文

Redis 是一个基于 K-V 存储的数据库服务器,下面先介绍 Redis 数据库的内部构造以及 K-V 的存储形式,有助于我们更容易理解 Redis 的持久化机制。

1. Redis数据库结构

一个单机的 Redis 服务器默认情况下有 16 个数据库(0-15号),默认使用的是 0 号数据库,可以使用 SELECT 命令切换数据库。

Redis 中的每个数据库都由一个 redis.h/redisDb 结构表示,它记录了单个 Redis 数据库的键空间、所有键的过期时间、处于阻塞状态和就绪状态的键、数据库编号等等。

typedef struct redisDb {
 // 数据库键空间,保存着数据库中的所有键值对
 dict *dict;
 // 键的过期时间,字典的键为键,字典的值为过期事件 UNIX 时间戳
 dict *expires;
 // 正处于阻塞状态的键
 dict *blocking_keys;
 // 可以解除阻塞的键
 dict *ready_keys;
 // 正在被 WATCH 命令监视的键
 dict *watched_keys;
 struct evictionPoolEntry *eviction_pool;
 // 数据库编号
 int id;
 // 数据库的键的平均 TTL,统计信息
 long long avg_ttl;
} redisDb;

由于 Redis 是一个键值对数据库(key-value pairs database), 所以它的数据库本身也是一个字典,对应的结构正是 redisDb。其中,dict 指向的是一个记录键值对数据的字典,它的键是一个字符串对象,它的值则可以是字符串、列表、哈希表、集合和有序集合在内的任意一种 Redis 类型对象。 expires 指向的是一个用于记录键的过期时间的字典,它的键为 dict 中的数据库键,它的值为这个数据库键的过期时间戳,这个值以 long long 类型表示。

2. RDB持久化

RDB 持久化(也称作快照持久化)是指将内存中的数据生成快照保存到磁盘里面,保存的文件后缀是 .rdb。rdb 文件是一个经过压缩的二进制文件,当 Redis 重新启动时,可以读取 rdb 快照文件恢复数据。RDB 功能最核心的是 rdbSave 和 rdbLoad 两个函数, 前者用于生成 RDB 文件并保存到磁盘,而后者则用于将 RDB 文件中的数据重新载入到内存中:

RDB 文件是一个单文件的全量数据,很适合数据的容灾备份与恢复,通过 RDB 文件恢复数据库耗时较短,通常 1G 的快照文件载入内存只需 20s 左右。Redis 提供了手动触发保存、自动保存间隔两种 RDB 文件的生成方式,下面先介绍 RDB 的创建和载入过程。

2.1. RDB的创建和载入

2.1.1. 手动触发保存

Redis 提供了两个用于生成 RDB 文件的命令,一个是 SAVE,另一个是 BGSAVE。而触发 Redis 进行 RDB 备份的方式有两种,一种是通过 SAVE 命令、BGSAVE 命令手动触发快照生成的方式,另一种是配置保存时间和写入次数,由 Redis 根据条件自动触发保存操作。

1. SAVE命令

SAVE 是一个同步式的命令,它会阻塞 Redis 服务器进程,直到 RDB 文件创建完成为止。在服务器进程阻塞期间,服务器不能处理任何其他命令请求。

客户端命令

127.0.0.1:6379> SAVE
OK

服务端日志

6266:M 15 Sep 2019 08:31:01.258 * DB saved on disk

执行 SAVE 命令后,Redis 在服务端进程(PID为6266)执行了 SAVE 操作,这个操作发生期间会一直阻塞 Redis 客户端的请求处理。

2. BGSAVE命令

BGSAVE 是一个异步式的命令,和 SAVE 命令直接阻塞服务器进程的做法不同,BGSAVE 命令会派生出一个子进程,由子进程负责创建 RDB 文件,服务器进程(父进程)继续处理客户的命令。

客户端命令

127.0.0.1:6379> BGSAVE
Background saving started

服务端日志

6266:M 15 Sep 2019 08:31:22.914 * Background saving started by pid 6283
6283:C 15 Sep 2019 08:31:22.915 * DB saved on disk
6266:M 15 Sep 2019 08:31:22.934 * Background saving terminated with success

通过服务端输出的日志,可以发现Redis 在服务端进程(PID为6266)会为 BGSAVE 命令单独创建(fork)一个子进程(PID为6283),并由子进程在后台完成 RDB 的保存过程,在操作完成之后通知父进程然后退出。在整个过程中,服务器进程只会消耗少量时间在创建子进程和处理子进程信号量上面,其余时间都是待命状态。

BGSAVE 是触发 RDB 持久化的主流方式,下面给出 BGSAVE 命令生成快照的流程:

  1. 客户端发起 BGSAVE 命令,Redis 主进程判断当前是否存在正在执行备份的子进程,如果存在则直接返回
  2. 父进程 fork 一个子进程 (fork 的过程中会造成阻塞的情况),这个过程可以使用 info stats 命令查看 latest_fork_usec 选项,查看最近一次 fork 操作消耗的时间,单位是微秒
  3. 父进程 fork 完成之后,则会返回 Background saving started 的信息提示,此时 fork 阻塞解除
  4. fork 创建的子进程开始根据父进程的内存数据生成临时的快照文件,然后替换原文件
  5. 子进程备份完毕后向父进程发送完成信息,父进程更新统计信息

3. SAVE和BGSAVE的比较

命令 SAVE BGSAVE
IO类型 同步 异步
是否阻塞 全程阻塞 fork时发生阻塞
复杂度 O(n) O(n)
优点 不会消耗额外的内存 不阻塞客户端
缺点 阻塞客户端 fork子进程消耗内存

2.1.2. 自动触发保存

因为 BGSAVE 命令可以在不阻塞服务器进程的情况下执行,所以 Redis 的配置文件 redis.conf 提供了一个 save 选项,让服务器每隔一段时间自动执行一次 BGSAVE 命令。用户可以通过 save 选项设置多个保存条件,只要其中任意一个条件被满足,服务器就会执行 BGSAVE 命令。 Redis 配置文件 redis.conf 默认配置了以下 3 个保存条件:

save 900 1
save 300 10
save 60 10000

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

  • 服务器在 900 秒之内,对数据库进行了至少 1 次修改。
  • 服务器在 300 秒之内,对数据库进行了至少 10 次修改。
  • 服务器在 60 秒之内,对数据库进行了至少 10000 次修改。

Redis 服务器会周期性地操作 serverCron 函数,这个函数每隔 100 毫秒就会执行一次,它的一项任务就是检查 save 选项所设置的保存条件是否满足,如果满足的话,就自动执行 BGSAVE 命令。

2.1.3. 启动自动载入

和使用 SAVE 和 BGSAVE 命令创建 RDB 文件不同,Redis 没有专门提供用于载入 RDB 文件的命令,RDB 文件的载入过程是在 Redis 服务器启动时自动完成的。启动时只要在指定目录检测到 RDB 文件的存在,Redis 就会通过 rdbLoad 函数自动载入 RDB 文件。

下面是 Redis 服务器启动时打印的日志,倒数第 2 条日志是在成功载入 RDB 文件后打印的。

$ redis-server /usr/local/etc/redis.conf
6266:C 15 Sep 2019 08:30:41.830 # Redis version=5.0.5, bits=64, commit=00000000, modified=0, pid=6266, just started
6266:C 15 Sep 2019 08:30:41.830 # Configuration loaded
6266:M 15 Sep 2019 08:30:41.831 * Increased maximum number of open files to 10032 (it was originally set to 256).
6266:M 15 Sep 2019 08:30:41.832 # Server initialized
6266:M 15 Sep 2019 08:30:41.833 * DB loaded from disk: 0.001 seconds
6266:M 15 Sep 2019 08:30:41.833 * Ready to accept connections

由于 AOF 文件属于增量的写入命令备份,RDB 文件属于全量的数据备份,所以更新频率比 RDB 文件的更新频率高。所以如果 Redis 服务器开启了 AOF 持久化功能,那么服务器会优先使用 AOF 文件来还原数据库状态;只有在 AOF 的持久化功能处于关闭状态时,服务器才会使用优先使用 RDB 文件还原数据库状态。

2.2. RDB的文件结构

RDB 文件是经过压缩的二进制文件,下面介绍关于RDB文件的一些细节。

2.2.1. 存储路径

SAVE 命令和 BGSAVE 命令都只会备份当前数据库,备份文件名默认为 dump.rdb,可通过配置文件修改备份文件名 dbfilename xxx.rdb。可以通过以下命令查看备份文件目录和 RDB 文件名称:

$ redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/usr/local/var/db/redis"
127.0.0.1:6379> CONFIG GET dbfilename
1) "dbfilename"
2) "dump.rdb"

RDB 文件的存储路径既可以在启动前配置,也可以通过命令动态设定。

  • 配置项:通过 dir 配置指定目录,dbfilename 指定文件名
  • 动态指定:Redis 启动后也可以动态修改 RDB 存储路径,在磁盘损害或空间不足时非常有用,执行命令为:
config set dir {newdir}
config set dbfilename {newFileName}

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对我们的支持。

(0)

相关推荐

  • Redis教程(十):持久化详解

    一.Redis提供了哪些持久化机制: 1). RDB持久化:     该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘.        2). AOF持久化:     该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的.     3). 无持久化:     我们可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的memcached了.     4).

  • Linux下redis的持久化、主从同步与哨兵详解

    1.0 redis持久化 Redis是一种内存型数据库,一旦服务器进程退出,数据库的数据就会丢失,为了解决这个问题,Redis提供了两种持久化的方案,将内存中的数据保存到磁盘中,避免数据的丢失. 1|1RDB持久化 redis提供了RDB持久化的功能,在指定的时间间隔内生成数据集的时间点快照(point-in-time snapshot)这个功能可以将redis在内存中的的状态保存到硬盘中,RDB持久化产生的RDB文件是一个经过压缩的二进制文件,这个文件被保存在硬盘中,redis可以通过这个文件

  • redis的2种持久化方案深入讲解

    前言 Redis是一种高级key-value数据库.它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富.有字符串,链表,集 合和有序集合.支持在服务器端计算集合的并,交和补集(difference)等,还支持多种排序功能.所以Redis也可以被看成是一个数据结构服务 器. Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为"半持久化模式"):也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为&q

  • 内存型数据库Redis持久化小结

    因为Redis是内存型数据库,所以为了防止因为系统崩溃等原因导致数据丢失的问题,Redis提供了两种不同的持久化方法来将数据存储在硬盘里面,一种方法是快照(RDB),它可以将存在于某一个时刻的所有数据都写入到硬盘里面,另外一种方法是只追加文件(AOF),它会在执行写命令时,将被执行的写命令都写入到硬盘里面. 快照持久化 Redis可以通过创建快照来获得在内存里面的数据在某一个时间点上的副本.在创建快照之后,用户可以对快照进行备份,可以将快照复制到其它服务器从而创建具有相同数据的服务器副本,还可以

  • redis数据的两种持久化方式对比

    一.概念介绍 redis提供了两种持久化的方式,分别是RDB(Redis DataBase)和AOF(Apend Only File). RDB方式 RDB方式是一种快照式的持久化方法,将某一时刻的数据持久化到磁盘中. •redis在进行数据持久化的过程中,会先将数据写入到一个临时文件中,待持久化过程都结束了,才会用这个临时文件替换上次持久化好的文件.正是这种特性,让我们可以随时来进行备份,因为快照文件总是完整可用的. •对于RDB方式,redis会单独创建(fork)一个子进程来进行持久化,而

  • 浅谈redis内存数据的持久化方式

    一.概述 Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的,然而当Redis重启后,所有存储在内存中的数据将会丢失,在很多情况下是无法容忍这样的事情的.所以,我们需要将内存中的数据持久化!典型的需要持久化数据的场景如下: 将Redis作为数据库使用: 将Redis作为缓存服务器使用,但是缓存miss后会对性能造成很大影响,所有缓存同时失效时会造成服务雪崩,无法响应. 本文介绍Redis所支持的两种数据持久化方式. 二.Redis数据持久化 Redis支持两种数据持久化方式:RDB

  • Redis两种持久化方案RDB和AOF详解

    本文主要针对Redis 有两种持久化方案RDB和AOF做了详细的分析,希望我们整理的内容能够帮助大家对这个两种方案有更加深入的理解. Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File).如果你想快速了解和使用RDB和AOF,可以直接跳到文章底部看总结.本章节通过配置文件,触发快照的方式,恢复数据的操作,命令操作演示,优缺点来学习 Redis 的重点知识持久化. RDB 详解 RDB 是 Redis 默认的持久化方案.在指定的时间

  • redis持久化的介绍

    1. RDB 1.1 RDB简介 RDB:在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里. 工作机制:每隔一段时间,就把内存中的数据保存到硬盘上的指定文件中. RDB是默认开启的! Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件.整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对

  • 从源码解读redis持久化

    为什么需要持久化? 由于Redis是一种内存型数据库,即服务器在运行时,系统为其分配了一部分内存存储数据,一旦服务器挂了,或者突然宕机了,那么数据库里面的数据将会丢失,为了使服务器即使突然关机也能保存数据,必须通过持久化的方式将数据从内存保存到磁盘中. 对于进行持久化的程序来说,数据从程序写到计算机的磁盘的流程如下: 1.客户端发送一个写指令给数据库(此时数据在客户端的内存) 2.数据库接收到写的指令以及数据(数据此时在服务端的内存) 3.数据库发起一个系统调用,把数据写到磁盘(此时数据在内核的

  • 一篇文章揭秘Redis的磁盘持久化机制

    前言 Redis 是内存数据库,数据都是存储在内存中,为了避免进程退出导致数据的永久丢失,需要定期将 Redis 中的数据以数据或命令的形式从内存保存到本地磁盘.当下次 Redis 重启时,利用持久化文件进行数据恢复.Redis 提供了 RDB 和 AOF 两种持久化机制,前者将当前的数据保存到磁盘,后者则是将每次执行的写命令保存到磁盘(类似于 MySQL 的 Binlog).本文将详细介绍 RDB 和 AOF 两种持久化方案,包括操作方法和持久化的实现原理. 正文 Redis 是一个基于 K-

  • 一篇文章讲透Tomcat的类加载机制

    目录 -     前言     - -     JVM 类加载器     - 1.JVM类加载器 2.类加载器的源码 -     Tomcat 的类加载机制     - 1.加载机制的特点 2.Tomcat 的类加载方案 3.分析应用类加载器的加载过程 总结 -     前言     - 你了解 Apache Tomcat 的类加载机制吗?本文将从底层原理切入,彻底揭秘 Tomcat 类加载所涉及的源码.机制和方案,助你深入掌握 Tomcat 类加载核心! -     JVM 类加载器    

  • 一篇文章弄懂Linux磁盘和磁盘分区

    前言 Linux 系统中所有的硬件设备都是通过文件的方式来表现和使用的,我们将这些文件称为设备文件,硬盘对应的设备文件一般被称为块设备文件. 本文介绍磁盘设备在 Linux 系统中的表示方法以及如何创建磁盘分区. 为什么要有多个分区? 防止数据丢失:如果系统只有一个分区,那么这个分区损坏,用户将会丢失所的有数据. 增加磁盘空间使用效率:可以用不同的区块大小来格式化分区,如果有很多1K的文件,而硬盘分区区块大小为4K,那么每存储一个文件将会浪费3K空间.这时我们需要取这些文件大小的平均值进行区块大

  • 一篇文章带你弄清楚Redis的精髓

    目录 一.Redis的特性 1.1 Redis为什么快? 1.2 Redis其他特性 1.3 Redis高可用 二.Redis数据类型以及使用场景 2.1 String 2.1.1 基本指令 2.1.2 应用场景 2.2 Hash 2.2.1 基本指令 2.2.2 应用场景 2.3 List 2.3.1 基本指令 2.3.2 应用场景 2.4 Set 2.4.1 基本指令 2.4.2 应用场景 2.5 ZSet(SortedSet) 2.5.1 基本指令 2.5.2 应用场景 三.Redis的事

  • 一篇文章带你彻底搞懂Redis 事务

    目录 Redis 事务简介 Redis 事务基本指令 实例分析 Redis 事务与 ACID 总结 Redis 事务简介 Redis 只是提供了简单的事务功能.其本质是一组命令的集合,事务支持一次执行多个命令,在事务执行过程中,会顺序执行队列中的命令,其他客户端提交的命令请求不会插入到本事务执行命令序列中.命令的执行过程是顺序执行的,但不能保证原子性.无法像 MySQL 那样,有隔离级别,出了问题之后还能回滚数据等高级操作.后面会详细分析. Redis 事务基本指令 Redis 提供了如下几个事

  • 一篇文章学会jsBridge的运行机制

    目录 js调用方式 安卓 1.js调用原生 2.原生调用js ios 总结 我司的APP是一个典型的混合开发APP,内嵌的都是前端页面,前端页面要做到和原生的效果相似,就避免不了调用一些原生的方法,jsBridge就是js和原生通信的桥梁,本文不讲概念性的东西,而是通过分析一下我司项目中的jsBridge源码,来从前端角度大概了解一下它是怎么实现的. js调用方式 先来看一下,js是怎么来调用某个原生方法的,首先初始化的时候会调用window.WebViewJavascriptBridge.in

  • 一篇文章搞懂MySQL加锁机制

    目录 前言 锁的分类 乐观锁和悲观锁 共享锁(S锁)和排他锁(X锁) 按加锁粒度区分 全局锁 表级锁(表锁和MDL锁) 意向锁 行锁 间隙锁 next-key lock(临键锁) 加锁规则 死锁和死锁检测 总结 前言 在数据库中设计锁的目的是为了处理并发问题,在并发对资源进行访问时,数据库要合理控制对资源的访问规则. 而锁就是用来实现这些访问规则的一个数据结构. 在对数据并发操作时,没有锁可能会引起数据的不一致,导致更新丢失. 锁的分类 乐观锁和悲观锁 乐观锁: 对于出现更新丢失的可能性比较乐观

  • 一篇文章弄懂JVM类加载机制过程以及原理

    目录 一.做一个小测试 二.类的初始化步骤: 三.看看你写对了没? 四.类的加载过程 五.类加载器的分类 1.启动类加载器(引导类加载器) 2.扩展类加载器 3.应用程序类加载器(系统类加载器) 六.类加载器子系统的作用 七.总结 一.做一个小测试 通过注释,标注出下面两个类中每个方法的执行顺序,并写出studentId的最终值. package com.nezha.javase; public class Person1 { private int personId; public Perso

  • Redis做数据持久化的解决方案及底层原理

    目录 数据持久化 RDB 生成方法 save bgsave 优点 缺点 AOF AOF记录过程 ServerCron 作用 server.hz 写入策略 End 之前的文章介绍了Redis的简单数据结构的相关使用和底层原理,这篇文章我们就来聊一下Redis应该如何保证高可用. 数据持久化 我们知道虽然单机的Redis虽然性能十分的出色, 单机能够扛住10w的QPS,这是得益于其基于内存的快速读写操作,那如果某个时间Redis突然挂了怎么办?我们需要一种持久化的机制,来保存内存中的数据,否则数据就

随机推荐