Redis持久化 RDB & AOF

简介: 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是老大

相关文章
|
5月前
|
NoSQL 安全 关系型数据库
Redis:持久化的两种方式
Redis持久化机制主要包括RDB和AOF两种方式。RDB通过生成数据快照进行持久化,支持手动或自动触发,具有加载速度快、文件紧凑等特点,但无法实时保存数据。AOF则记录每个操作命令,保障数据更安全,支持多种写入策略,并可通过重写机制优化文件大小。两者各有优劣,常结合使用以兼顾性能与数据安全。
|
5月前
|
存储 缓存 NoSQL
Redis持久化深度解析:数据安全与性能的平衡艺术
Redis持久化解决内存数据易失问题,提供RDB快照与AOF日志两种机制。RDB恢复快、性能高,但可能丢数据;AOF安全性高,最多丢1秒数据,支持多种写回策略,适合不同场景。Redis 4.0+支持混合持久化,兼顾速度与安全。根据业务需求选择合适方案,实现数据可靠与性能平衡。(238字)
|
8月前
|
存储 监控 NoSQL
流量洪峰应对术:Redis持久化策略与内存压测避坑指南
本文深入解析Redis持久化策略与内存优化技巧,涵盖RDB快照机制、AOF重写原理及混合持久化实践。通过实测数据揭示bgsave内存翻倍风险、Hash结构内存节省方案,并提供高并发场景下的主从复制冲突解决策略。结合压测工具链构建与故障恢复演练,总结出生产环境最佳实践清单。
315 9
|
存储 NoSQL 安全
Redis的两种持久化方式---RDB、AOF
通过本文的介绍,我们详细讲解了Redis的两种主要持久化方式:RDB和AOF。每种方式都有其独特的优缺点和适用场景。在实际应用中,可以根据具体需求选择合适的持久化方式,或者同时启用RDB和AOF,以达到最佳效果。希望本文能帮助您更好地理解和应用Redis的持久化机制,构建高效、可靠的数据存储解决方案。
1135 79
|
11月前
|
NoSQL Redis
Redis的数据持久化策略有哪些 ?
Redis 提供了两种方式,实现数据的持久化到硬盘。 1. RDB 持久化(全量),是指在指定的时间间隔内将内存中的数据集快照写入磁盘。 2. AOF持久化(增量),以日志的形式记录服务器所处理的每一个写、删除操作 RDB和AOF一起使用, 在Redis4.0版本支持混合持久化方式 ( 设置 aof-use-rdb-preamble yes )
|
存储 NoSQL Redis
Redis 持久化揭秘:选择 RDB、AOF 还是混合持久化?
Redis 是一个内存数据库,意味着它主要将数据存储在内存中,从而能够提供极高的性能。然而,作为内存数据库,Redis 默认情况下的数据不会永久保存。为了确保数据在重启或故障后能够恢复,Redis 提供了几种 **持久化机制**。这些机制允许 Redis 将内存中的数据保存到硬盘上,从而实现数据持久化。
805 22
Redis 持久化揭秘:选择 RDB、AOF 还是混合持久化?
|
NoSQL 关系型数据库 MySQL
Redis持久化机制 RDB 和 AOF 的选择
Redis持久化机制 RDB 和 AOF 的选择
302 0
|
存储 缓存 NoSQL
大数据-45 Redis 持久化概念 RDB AOF机制 持久化原因和对比
大数据-45 Redis 持久化概念 RDB AOF机制 持久化原因和对比
239 2
大数据-45 Redis 持久化概念 RDB AOF机制 持久化原因和对比
|
存储 缓存 NoSQL
Redis中的rdb和aof
本文深入探讨了Redis的持久化机制,包括RDB和AOF两种方式。详细解释了RDB的工作原理、优势和劣势,以及AOF的实现原理、配置选项、文件重写机制和三种数据同步方式,还介绍了AOF文件修复工具redis-check-aof的使用,并通过实例展示了如何开启和配置AOF持久化方式。
Redis中的rdb和aof
|
存储 NoSQL Redis
SpringCloud基础7——Redis分布式缓存,RDB,AOF持久化+主从+哨兵+分片集群
Redis持久化、RDB和AOF方案、Redis主从集群、哨兵、分片集群、散列插槽、自动手动故障转移
SpringCloud基础7——Redis分布式缓存,RDB,AOF持久化+主从+哨兵+分片集群