配置文件详解、RDB 及 AOF 备份机制(二)|学习笔记

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 快速学习配置文件详解、RDB 及 AOF 备份机制(二)

开发者学堂课程【Redis 入门实战演练 配置文件详解、RDB 及 AOF 备份机制(二)】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/653/detail/10835


配置文件详解、RDB 及 AOF 备份机制(二)


二、Redis 持久化

Redis 虽然是一个内存级别的缓存程序,也就是 redis 是使用内存进行数据的缓存的,但是其可以将内存的数据按照一定的策略保存到硬盘上,从而实现数据持久保存的目的,目前redis支持两种不同方式的数据持久化保存机制,分别是 RDB 和 AOF

1、RDB 模式

RDB 的全称是 Redis DataBase基于时间的快照。其默认只保留当前最新的一次快照。特点是执行速度比较快,缺点是可能会丢失从上次快照到当前时间点之间未做快照的数据。

RDB 实现的具体过程Redis 一旦从某个时间段之内生成了 key,就会传给磁盘。Redis 从主进程先 fork 出一个子进程(复制出一个子进程),使用的是写时复制机制(copy-on-write)子进程将内存的数据保存为一个临时文件到磁盘上,比如dump.rdb.temp,temp 表示的是临时文件。因为数据没有从内存中保存完,当数据保存完成之后再将上一次保存的RDB文件替换掉,替换过程类似于 MV,将原文件覆盖掉,然后关闭子进程(将子进程回收),这样可以保证每一次做 RDB 快照时候保存的数据都是完整的,因为直接替换 RDB 文件的时候可能会出现突然断电等问题而导致 RDB 文件还没有保存完整就突然关机导致停止保存进而使数据丢失,可以手动将每次生成的 RDB 文件进程备份,这样可以最大化保存历史数据。

图示为流程图:

image.png

在一个 redis 服务器中,redis 的内存假设为4G,dump 的时候由 redis 的主进程先生成一个子 进程,生成时间基于之前设定的触发策略。由这个子进程负责将数据写入磁盘的某个文件,这个文件是一个临时文件,当这个临时文件百分之百完全写完之后,再由子进程替换成之前的 RDB 文件,替换完成后原文件就会消失了,这样就可以保证了数据的一致性。需要注意的是在 dump 过程中并不影响后续其他数据的读取,子进程由主进程生成,子进程又去写入数据。好处就是不是一边替换一边 dump,边替换边dump可能会遇到在 dump 过程中突然断电等情况,进而使 RDB 文件成为不完整文件了。而是在临时文件百分之百把内存数据放到硬盘之后再去替换,这样的话就不会在突发情况下虽然会导致 RDB 临时文件出现问题,但不会影响 RDB 文件,即使遇到了断电情况,在开机后依旧可以依据 RDB 文件尽最大可能将 RDB 临时文件恢复出来,将业务的影响降到最低,而再有了 AOF 数据的完整性基本上可以保证。

image.png

先转换成数据库的状态再内存,并保存为 RDB 文件;还原时将 RDB 文件还原成数据库内存,无论是重启 Redis 还是重启服务器都会从该文件进行还原。

2、RDB 模式的优点

l RDB 快照保存了某个时间点的数据,可以通过脚本执行 bgsave(非阻塞)或者save(阻塞)命令自定义时间点备份,可以保留多个备份,当出现问题可以恢复到不同时间点的版本。最终结果仅有一个文件,若想要把历史文件都进行保存,需要自行写入一个脚本,先手动对文件进行备份,备份成功后就将 RDB 文件重命名,当下次再备份的时候,还会生成 dump.rdb 这样的文件,也对其进行重命名,修改成 RDB...的格式。自动备份很大达成,因为不确定什么时候才会触发一次备份,也就不能进行对备份文件重命名的操作。备份时是基于 bgsave 进行的,即在子进程进行备份的时候是基于后台备份的,不影响 redis 主进程对内存的读写。当然子进程不能对 flink 进行修改,因为它执行的是写实复制,保证了数据在主进程里依然可以写入,但是子进程只能够复制。缓冲区是主进程在子进程执行完数据备份之后存放备份过程当中产生的新数据,做完 RDB 快单之后,把文件保存到硬盘,然后把RDB文件发送给 slave,再把缓冲区的内容发送过去。即对于子进程来说,它只完成读取的任务,但没有权限写入,可以这样理解,一旦执行了 dump,子进程对内存数据是只读的,负责 dump,往磁盘写入数据;而主进程是可以写入数据的,数据一旦被 dump 完之后,redis 主进程结合缓冲区发给 slave,完成主动同步。如果是本机任务,就没有了缓冲区,只能够将数据备份下来,一旦备份之后,新的数据只有在下一次再 RDB 时,才能备份到 redis 服务器,因此会有一段时间的延迟。

l 可以最大化 IO 的性能,因为父进程在保存 RDB 文件的时候难一要做的是 fork 出一个子进程,然后后续的操作都会依据这个子进程完成操作,父进程无需任何的 IO 操作降低了主进程的压力,因为无论是对于数据备份还是主动同步,都交给了子进程去完成,主进程依然是负责接收外部用户的请求,

l RDB 在大量数据比如几个 G 的数据,恢复的速度比 AOF 的快因为在恢复的时候不像 AOF 从上到下进行逐行执行,RDB 是直接将一个文件还原到内存,不存在逐行执行的弊端:上一行执行了 key,创建和删除的操作都会占用时间。

3、RDB 模式的缺点

l 不能实时的保存数据,会丢失自上一次执行 RDB 备份到当前的内存数据备份一旦开始,新的数据只有在下一次备份的时候才会保存到文件里面去,否则将是一个无用的数据。

l 数据非常大的时候,从父进程 fork 的时候需要一点时间,可能是毫秒或者秒或者分钟,取决于磁盘 I0 性能。因为子进程 fork 完成之后,需要从内层向磁盘保存数据,而保存数据需要一定的时间,具体要看数据的多少以及磁盘的性能。

4、AOF 模式

AOF:按照操作顺序依次将操作添加到指定的日志文件当中,特点是数据安全性相对较高,缺点是即使有些操作是重复的也会全部记录。比如刚创建了一些数据然后把他们删除,或者是对写错数据的修改等等这些没有意义行为也都会被记录下来。这是与 RDB 不同的,RDB 只会记录当前的状态,即在 key 写完之后备份的时候,RDB 只会备份当前的,之前的语句均不会被记录备份下来。

AOF 和 RDB 一样使用了写时复制机制,AOF 默认为每秒钟 fsync 一次,往磁盘上写入数据有一次,即将执行的命令保存到 AOF 文件当中,这样即使 redis 服务器发生故障的话顶多也就丢失1秒钟之内的数据,因为这是每秒钟向磁盘刷新一次的模式。也可以设置不同的 fsync 策略,或者设置每次执行命令的时候执行 fsync,fsync 会在后台执行线程,所以主线程可以继续处理用户的正常请求而不受到写入AOF 文件的 IO 影响。

无论是使用 RDB 还是 AOF,redis 主进程都是可以继续响应用户的请求,而不会报错或产生队列

5、AOF 模式优缺点:

l AOF 的文件大小要大于RDB格式的文件因为 AOF 的每条日志(每个操作)都会被记录下来,不像 RDB 只保留当前日志(操作)

l 根据使用的 fsync 策略(fsync 是同步内存中 redis 所有已经修改的文件到存储设备),默认是 appendfsync everysec 即每秒执行一次 fsync有可能会产生一部分的数据丢失,当然丢失的这部分数据会远远的低于 RDB,因为 RDB 备份是基于某段时间内发生了多少 key 的变化来执行的,时间是不好把控的,丢失的数据也就不好确定了。AOF 导致的数据丢失是在我们所能承受的范围内的。

 

三、本节重点

1.RDB 和 AOF 持久化策略优缺点

RDB 与 AOF 的实现方式

2、redis 配置文件

最主要的几条配置文件,可以在控制台通过grepI^[a-Z]apps/ redis/etc/ redis.conf查看

image.png

主要包括地址监听、持久化策略以及 dump 文件的保存位置

3、熟悉通过脚本向 redis 读写数据(python)

通过 python 方式去了解 Java 的书写方式,并且要熟悉 Java 的书写方式,因为 Java 的应用相对更加广泛。

4、redis 各种安装方式及使用 service 文件启动

上述启动方式并不一定

5、两个执行策略

l 一个是 bgsave,执行 RBD 时的默认策略,即后台备份数据。一旦执行 bgsave 策略,就会将当前数据备份到磁盘上,不影响主进程对redis的读写。对 bgsave 重新执行,由于当前数据很少,所以备份时间很快。

如果要实现多个文件的保存,也需要执行 bgsave 策略,因为一旦执行了 bgsave,就会生成相应的文件,再经过脚本响应或者其他方式将文件进行重命名。

l 另一个时 save,在使用 bgsave 时,读写并不受影响,但是 save 就不相同了,save 是前台备份,如果数据量很大,达到好几G,需要10秒钟甚至20秒才可以在磁盘上写完,而在这10秒或者20秒之内,是无法读取 redis 数据的,即被阻塞了。

6、备份脚本

通过脚本对 redis 数据进行周期性的备份,比如每间隔5分钟进行备份一次,备份完成之后将 rdb 文件分开保留下来,即使用 bgsave 执行快照,然后MV快照文件成需要的格式,例如 2020-02-07-01-30-40.rdb 的格式,这样之后下一个周期再进行备份的时候,假设5分钟进行备份一次,下一个周期就是 2020-02-07-01-35-40.rdb 了依次类推,再下一个就是在40分的时候,在下一个就是在45分的时候。这是很好实现的,但是为了保证磁盘的足够空间,最好只保存最近一小时或是最近5小时的 rdb 文件,当然磁盘空间足够的,也是可以保留最近一天的数据 rdb 文件,超过时间的就自动删除。尽量避免使用存储,因为在使用存储的时候,需要使用专门的网卡进行数据同步,尽量不要使用和应用程序所匹配的网卡,因为该网卡需要读取 redis 里面的数据且数据量较大,如果此时再使用该网卡,会导致这段时间网卡的带宽被耗尽。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
12月前
|
NoSQL 安全 关系型数据库
【Redis源码】详细的RDB和AOF持久化过程(五)
【Redis源码】详细的RDB和AOF持久化过程(五)
58 0
|
5月前
|
存储 NoSQL 关系型数据库
Redis持久化策略AOF、RDB详解及源码分析
Redis持久化策略AOF、RDB详解及源码分析
|
12月前
|
存储 NoSQL 关系型数据库
Redis的持久化策略(RDB、AOF、RDB-AOF混合持久化)
Redis的持久化策略(RDB、AOF、RDB-AOF混合持久化)
147 0
|
12月前
|
NoSQL Redis
Redis学习笔记-AOF 日志和 RDB快照
Redis学习笔记-AOF 日志和 RDB快照
92 0
|
存储 缓存 NoSQL
AOF和RDB持久化的区别
AOF和RDB持久化的区别
80 0
|
NoSQL Redis
你必须知道的Redis持久化机制-RDB快照
记录命令,持久化的数据量不大。但是在AOF日志恢复时,需要把日志的每条命令都执行一遍。如果日志很多,恢复过程就会变得很漫长。因此,Redis提供了另一种持久化机制,那就是RDB快照。
186 0
你必须知道的Redis持久化机制-RDB快照
|
NoSQL Redis 数据安全/隐私保护
Redis如何实现持久化(AOF、RDB、混合模式)的优缺点
Redis如何实现数据不丢失 Redis的读写操作都是在内存中,所以Redis性能才会高,但是当Redis重启后,内存中的数据就会丢失,那为了保存内存中的数据不会丢失,Redis实现了数据持久化机制,会把数据保存到磁盘,这样Redis重启就能够从磁盘恢复原有的数据
242 0
Redis如何实现持久化(AOF、RDB、混合模式)的优缺点
|
运维 NoSQL 大数据
持久化-RDB与AOF方案对比|学习笔记
快速学习持久化-RDB 与 AOF 方案对比
持久化-RDB与AOF方案对比|学习笔记
|
存储 缓存 NoSQL
持久化-AOF 持久化策略基本操作|学习笔记
快速学习持久化-AOF 持久化策略基本操作
108 0
持久化-AOF 持久化策略基本操作|学习笔记
|
存储 NoSQL Redis
持久化-AOF 自动重写配置|学习笔记
快速学习持久化-AOF 自动重写配置
211 0
持久化-AOF 自动重写配置|学习笔记