Redis持久化 RDB & AOF

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: Redis持久化 RDB & AOF

前言

redis的十大类型终于告一段落了,下面我们开始redis持久化新篇章

为啥需要持久化呢?

我们知道redis是挡在mysql前面的带刀侍卫

是在内存中的,假如我们的redis宕机了,难道数据直接冲入mysql???

这显然是不可能的,mysql肯定扛不住这样的场景,所以我们有了redis持久化策略

实际上redis是可以使用rdb和aof混合策略的

但是在本篇博客中笔者先单独谈论rdb,以及一点点的源码分析

再考虑aof的情况

废话不多说,现在我们开始今天的内容吧

RDB

主动触发

rdb主要作用是指定时间内写入硬盘,在恢复的时候全部写入内存

生成的文件叫做dump.rdb 我们可以在conf文件中修改其的保存规则

默认的规则如下

这里分为redis6.0.16以前和6.2以后

这里分为redis6.0.16以前和6.2以后

6.0.16 保存规则是

900s 至少一次修改

300s 10w次修改

60s 1w次修改

6.2以上版本是

3600s 1次

300s 100次

60s 1000次

注意:这里的参数不太好理解,官网的表述也是含糊其辞的

为了方便测试 我们修改成5秒至少两次修改,用于查看情况

可以使用vim编辑器对conf文件进行编辑

我们还可以对生成的dump文件名以及路径进行修改方便观察

这里是尝试过了忘记截图了

我们直接说结论:

在五秒内执行两次写操作,dump文件会进行更新

在五秒外 甚至十秒内写入两次也是会更新的,笔者查阅资料未果,于是开始阅读源码

最终是在server.c的serverCorn函数中发现

这里我们就能发现大于我们设置的时间 也是ok的

下面我们不做过多测试,具体可以自行进行测试

注:记得开两个服务端,一个在linux一个在redis方便查看对应的文件大小变化

以上四redis的主动调用

下面我们来说说redis的rdb的手动保存

这里我们修改完config文件箱查看是否生效可以使用config get/set 属性来查看

手动触发

主要是两个命令

save 和 bgsave

save指令是不可以使用的因为如果使用就会直接阻塞,直到保存完成再允许用户线程再访问

bgsave则是fork一个子进程来完成rdb文件的快照服务,不进行阻塞

生产上是万万不能使用save来保存快照的

优缺点

下面我们谈谈rdb的优缺点

优点:

文件非常紧凑,非常适合备份文件,一把抓,适合灾难恢复

最大限度提高了redis的性能,子进程制度则rdb,父进程负责读写数据

缺点:

可能会丢失最近一次修改的数据,因为还没有达到保存快照的条件

在数据量比较庞大的时候,子进程也会很耗时,且非常影响服务器的性能

检查和修复rdb文件

假设我这里随便在rdb文件后面添加一串乱码

此时redis服务器重启的时候就无法成功

我们需要找到这个文件夹中使用修复工具

此时就修复成功了

出现rdb快照的情况

注:禁用rdb快照 在设置的时候直接设置save ""即可

rdb优化配置项

1.stop-write-on-bgsave-error yes 默认为yes,快照写入 失败的时候,直接停止,保证数据一致性

2.rdbcompression yes 压缩,占用空间大了只保存最后一次修改的结果

3.rdbchecksum 算法校验可靠性   类似于之前tcp那块的校验和算法

4.rdb-del-sync-files 复制实例的时候没有指定持久化的直接删除,默认为no

AOF

我们刚刚说了RDB,那么为啥还需要一个AOF呢

他的诞生就是为了解决rdb可能直接丢失一次最近写入的数据,因为不满足保存快照的条件

注意 redis默认是不打开aof的,需要设置

appendonly  设置为yes即可

主要做的事情就是以日志形式保存设置的命令,在重启的时候直接重新执行一遍

下面我们介绍一下aof执行的流程

三种写回策略:

Always    写一条备份一条

everysec   每秒进行备份

no             不自己备份,靠操作系统决定啥时候写回

文件说明

文件以前是和rdb放一块的,现在放在dir下面

在redis6之前是以appendonly.aof保存

现在是以三个文件混合保存

分别是 base   incr    清单文件

每次写入先放到incr增量文件中

incr文件可能存在多个,base文件只有一个

异常恢复

使用redis-check-aof --fix

优缺点

优点:

默认一秒写回,最多丢失一秒的数据

写一半断了也可以使用恢复策略

可以轻松导出文件,可读性强

假设我flushdb了   只要没继续进行写操作,是可以修改aof文件救回来的

缺点:

等效文件大于rdb,恢复速度慢于rdb

aof重写机制

随着aof文件的越来越大,占用空间也就越来越大,需要一定的瘦身计划

所以在达到一定的峰值之后会进行内容压缩

也就是假设我这里对k1进行了三次的设置

只会保存最后一次的更改

混合机制

两者共存的时候默认先加载aof,但是默认使用rdb

aof是老大

相关实践学习
基于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
相关文章
|
7天前
|
监控 NoSQL 测试技术
【赵渝强老师】Redis的AOF数据持久化
Redis 是内存数据库,提供数据持久化功能,支持 RDB 和 AOF 两种方式。AOF 以日志形式记录每个写操作,支持定期重写以压缩文件。默认情况下,AOF 功能关闭,需在 `redis.conf` 中启用。通过 `info` 命令可监控 AOF 状态。AOF 重写功能可有效控制文件大小,避免性能下降。
|
7天前
|
存储 监控 NoSQL
【赵渝强老师】Redis的RDB数据持久化
Redis 是内存数据库,提供数据持久化功能以防止服务器进程退出导致数据丢失。Redis 支持 RDB 和 AOF 两种持久化方式,其中 RDB 是默认的持久化方式。RDB 通过在指定时间间隔内将内存中的数据快照写入磁盘,确保数据的安全性和恢复能力。RDB 持久化机制包括创建子进程、将数据写入临时文件并替换旧文件等步骤。优点包括适合大规模数据恢复和低数据完整性要求的场景,但也有数据完整性和一致性较低及备份时占用内存的缺点。
|
1月前
|
存储 缓存 NoSQL
大数据-45 Redis 持久化概念 RDB AOF机制 持久化原因和对比
大数据-45 Redis 持久化概念 RDB AOF机制 持久化原因和对比
37 2
大数据-45 Redis 持久化概念 RDB AOF机制 持久化原因和对比
|
1月前
|
存储 缓存 NoSQL
大数据-46 Redis 持久化 RDB AOF 配置参数 混合模式 具体原理 触发方式 优点与缺点
大数据-46 Redis 持久化 RDB AOF 配置参数 混合模式 具体原理 触发方式 优点与缺点
56 1
|
6月前
|
NoSQL 关系型数据库 MySQL
Redis持久化机制 RDB 和 AOF 的选择
Redis持久化机制 RDB 和 AOF 的选择
98 0
|
6月前
|
存储 缓存 NoSQL
Redis之持久化(RDB和AOF)
Redis之持久化(RDB和AOF)
141 0
|
存储 缓存 NoSQL
【Redis 系列】redis 学习八,redis 持久化 RDB 和 AOF
【Redis 系列】redis 学习八,redis 持久化 RDB 和 AOF
|
3月前
|
缓存 NoSQL Redis
redis数据持久化之RDB和AOF
redis数据持久化之RDB和AOF
|
5月前
|
存储 NoSQL Redis
《面试官之你说我听》:简明的图解Redis RDB持久化、AOF持久化
《面试官之你说我听》:简明的图解Redis RDB持久化、AOF持久化
|
6月前
|
存储 NoSQL 程序员
Redis(持久化 -- RDB & AOF)
Redis(持久化 -- RDB & AOF)
62 2