redis的持久化机制详解(RDB和AOF)

最新推荐文章于 2024-03-25 11:35:12 发布

Xuxq01

最新推荐文章于 2024-03-25 11:35:12 发布

阅读量437

点赞数

文章标签： redis 缓存 java

本文链接：https://blog.csdn.net/xuxq01/article/details/129309203

版权

一、redis的持久化方式

redis的持久化提供了两种方式,分别是RDB(redis databsse)和AOF(append only file),其中RDB是默认开启的,AOF是需要手动开启的,AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率.

先看官网的介绍:

持久性是指将数据写入持久存储，例如固态磁盘（SSD）。Redis 提供了一系列持久性选项。其中包括：

RDB（Redis 数据库）：RDB 持久性按指定的时间间隔执行数据集的时间点快照。
AOF（仅追加文件）：AOF 持久性记录服务器收到的每个写入操作。然后可以在服务器启动时再次重播这些操作，重建原始数据集。命令的记录格式与 Redis 协议本身相同。
无持久性：可以完全禁用持久性。这有时在缓存时使用。
RDB + AOF：您还可以在同一实例中组合 AOF 和 RDB。

二、RDB

(1)介绍和配置

1.RDB是一种快照方式,将redis某一时刻的数据以文件的形式持久化到硬盘,这样一来,即使出现故障宕机快照文件依旧存在,数据的可靠性得到了保证.

2.保存的文件默认名称为dump.rdb,我们可以在redis.conf文件中进行一些配置,根据官网的描述,RDB的配置在redis6和7之间发生了一些变化

其中save <second> <changes>是语法格式,表示每过second秒,如果有changes个key发生了改变,就写一份新的RDB文件,在redis7中已经改为了如下图,格式仍是save <second> <changes>

注:save ""表示关闭rdb

在redis.conf文件中搜索dir ./可以搜索到文件的保存路径,可以将dir后面的./换为其他想要的路径,修改完成后在redis中输入config get dir可以获取目录

需要注意,dir后面的文件夹必须存在,需要提前建好

(2)持久化触发的两种方式

1.RDB自动触发

只要我们执行的操作达到了second和changes的要求,就会产生一个dump.rdb文件放在设置的路径下

我设置的为save 5 2第一次不会产生文件,第二次产生

此时我们先将产生的文件更改名称,使用flushdb清空数据库,会发现重新产生了一个dump.rdb文件(实际上是空的),我们先不管他,rm删除他之后将之前产生的文件重新改回来名字,重新启动redis服务,会发现数据仍然存在.

2.RDB手动触发

有时我们会遇到这样的情况:我们有了一个重要的数据,但此时还没满足second和changes的要求,此时就需要我们手动来保存,覆盖掉最新的dump.rdb文件.

手动触发有两条命令save和bgsave(即background save,默认)

保存就保存,为什么会有两条命令呢?

1.save

redis会单独创建(fork)一个子进程来进行持久化,save在主进程中执行会阻塞当前的redis服务器直到持久化工作完成,save期间redis不能处理其他命令.

2.bgsave

这种方式会在后台异步进行快照操作,不阻塞快照,这就允许主进程可以同时提供缓存功能

(3)优缺点(官网说明)

1.优点

RDB 是 Redis 数据的一个非常紧凑的单文件时间点表示形式。RDB 文件非常适合备份。例如，您可能希望每隔 24 小时存档一次 RDB 文件，并将 RDB 快照每天保存 30 天。这使您可以在发生灾难时轻松还原数据集的不同版本。
RDB 非常适合灾难恢复，它是一个可以传输到远程数据中心或 Amazon S3（可能加密）的单个紧凑文件。
RDB 最大限度地提高了 Redis 性能，因为 Redis 父进程为了持久化而需要做的唯一工作是分叉一个子进程，该子进程将完成所有其余工作。父进程永远不会执行磁盘 I/O 或类似操作。
与 AOF 相比，RDB 允许更快地重新启动大数据集。

1.缺点

如果您需要在 Redis 停止工作（例如停电后）将数据丢失的可能性降至最低，则 RDB 不好。您可以在生成 RDB 的位置配置不同的保存点（例如，在至少 100 分钟和针对数据集写入 <> 次后，您可以有多个保存点）。但是，您通常会每五分钟或更长时间创建一个 RDB 快照，因此，如果 Redis 因任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新几分钟的数据。(即数据丢失风险大)
RDB 经常需要 fork（）才能使用子进程持久化在磁盘上。如果数据集很大，fork（）可能会很耗时，如果数据集非常大且 CPU 性能不是很好，则可能会导致 Redis 停止为客户端提供服务几毫秒甚至一秒钟。AOF 还需要 fork（），但频率较低，您可以调整重写日志的频率，而无需牺牲持久性。(即数据集多的时候会非常耗时)

(4)产生RDB快照的情况

1.配置文件中的save配置

2.手动save/bgsave

3.执行flushdb/flushall(此时产生的rdb文件是空的,为了和当前的操作保持一致,即清空)

4.执行shutdown且不开启AOF

三、AOF

(1)介绍

以日志的形式来记录每个写操作,将redis执行过的所有指令记录下来(读操作不记录),redis启动之初会读取该文件重构数据库,即根据日志内容从前到后执行一次完成数据恢复

默认是没有开启的,需要进行配置:appendonly yes

(2)三种写回策略

1.always:同步写回,每个命令执行完后立刻同步的将日志写回硬盘

2.everysec(默认):执行完写命令先把日志写到AOF文件的内存缓冲区,每隔一秒写入磁盘

3.no:操作系统控制写回,执行完写命令先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将内容写回磁盘

在redis6以前,aof文件保存路径和rdb文件在一起,在redis7以后,会在rdb文件保存路径下新建一个appendonlydir文件夹,在这个文件夹下生成aof文件,当然,也可以通过配置修改,这里不再演示

(3)持久化

redis6有且只有一个aof文件

redis7 multi part aof设计有三部分构成,将单个拆成了三份

1.BASE:表示基础aof,一般是子进程重写产生,最多一个

2.INCR:表示增量aof,在aofrw执行时创建,可能有多个

HISTORY:表示历史aof,会被redis自动删除

3.manifest:跟踪管理这些aof

一、正常恢复

进行写操作时通通写入到incr.aof文件中,只记录写操作

二、异常恢复

可能文件值写入了一半,此时redis挂掉,此时文件被破坏,连接redis服务器会提示连接被拒绝,此时可以通过/usr/local/bin下的redis-check-aof进行修复,命令为:redis-check-aof --fix appendonly.aof.1.incr.aof

(4)优点

使用 AOF Redis 更加持久：您可以拥有不同的 fsync 策略：完全没有 fsync，每秒 fsync 一次，每次查询时 fsync。使用每秒 fsync 的默认策略，写入性能仍然很高。fsync 是使用后台线程执行的，当没有 fsync 正在进行时，主线程将努力执行写入，因此您只能丢失一秒钟的写入。
AOF 日志是仅追加日志，因此在断电时不会有寻道或损坏问题。即使由于某种原因（磁盘已满或其他原因）日志以半写命令结束，redis-check-aof 工具也可以轻松修复它。
Redis 能够在 AOF 变得太大时在后台自动重写它。重写是完全安全的，因为当 Redis 继续追加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，Redis 就会切换两者并开始追加到新文件。
AOF 以易于理解和解析的格式包含所有操作一个接一个的日志。您甚至可以轻松导出 AOF 文件。例如，即使您使用 FLUSHALL 命令意外刷新了所有内容，只要在此期间没有重写日志，您仍然可以通过停止服务器、删除最新命令并重新启动 Redis 来保存数据集。

(5)缺点

AOF 文件通常大于同一数据集的等效 RDB 文件。
AOF 可能比 RDB 慢，具体取决于确切的 fsync 策略。一般来说，将 fsync 设置为每秒性能仍然非常高，并且在禁用 fsync 的情况下，即使在高负载下，它应该与 RDB 一样快。尽管如此，RDB仍然能够提供更多关于最大延迟的保证，即使在巨大的写入负载的情况下也是如此。

(6)AOF重写机制

aof持久化是不断将命令记录到aof文件中,随着redis进行,aof文件越来越大,占用服务器内存大且恢复要求时间变长,为了解决这个问题redis新增了重写机制,当aof文件大小超过设定的峰值,redis会自动启动aof的内容压缩,只保留可以恢复数据的最小指令集

举例:set k1 v1,set k1 v2, set k3 v3只需要最后一条