Redis学习总结(一)

Redis的持久化包括RDB和AOF两种方式。RDB通过快照实现高效备份,AOF记录命令日志,实时性更强。RDB使用fork子进程生成快照,AOF通过fsync策略控制数据同步到磁盘。内核缓冲区在提高写入性能的同时,需注意数据安全性。AOF的fsync策略包括always、everysec和no,以平衡性能和数据完整性。
摘要由CSDN通过智能技术生成

Redis 持久化机制

RDB 持久化

Redis RDB(Redis DataBase)是Redis的一种持久化方式。它可以将Redis中的数据快照存储在硬盘上,并在需要时重构该数据快照。因为可以在磁盘上存储和重构数据快照,所以RDB是一种非常高效的Redis数据备份和恢复方式。具有灵活性和高效性的RDB在实际应用中被广泛使用。

RDB的工作原理是当Redis满足一定条件时,Redis会将数据写入到一个RDB文件中。这些条件通常是:

  • 指定的时间间隔内发生了指定数量的写操作,例如10000个键被修改等。
  • 指定的时间间隔内有指定数量的写操作,例如至少有5个键被修改,且至少过去了半小时等。

在创建RDB文件时,Redis会执行一个fork操作,它在Redis内部创建了一个子进程来执行实际的RDB文件生成工作。父进程继续处理客户端请求,而子进程则负责将数据写入到RDB文件中。由于使用了fork,所以这个过程是非常快速和效率的。

RDB文件是一个二进制文件,可以通过指定的配置选项控制其生成频率和命名规则。在需要恢复Redis数据时,可以使用RDB文件进行恢复。同时,Redis还支持AOF(Append Only File)持久化方式,它可以将每个Redis命令的执行记录写入到一个日志文件中,并在需要时回放这些命令来恢复数据。相比之下,RDB方式更加简单,且恢复速度更快。

Redis 提供了两个命令来生成 RDB 快照文件

  1. save : 同步保存操作,会阻塞 Redis 主线程;

  2. bgsave : fork 出一个子进程,子进程执行,不会阻塞 Redis 主线程,默认选项。

RDB 是默认的持久化方式吗?默认开启吗?如何设置?

RDB是Redis的默认持久化方式,并且在默认情况下开启。但是,您可以通过修改Redis的配置文件来启用或禁用RDB持久化,或者更改持久化频率和命名规则等参数。

以下是设置RDB持久化的示例代码:

# 启用RDB方式持久化
save 900 1     # 如果在900秒内,有至少1个键被修改,就执行持久化操作
save 300 10    # 如果在300秒内,有至少10个键被修改,就执行持久化操作
save 60 10000  # 如果在60秒内,有至少10000个键被修改,就执行持久化操作
 
# 禁用RDB方式持久化
# save ""

在这个示例中,我们通过修改配置文件中的 save 参数来调整RDB持久化的频率,它定义了在一定时间内,有多少个键被修改时需要执行持久化操作。在本例中,如果在900秒内至少有1个键被修改,则执行持久化操作,并将数据快照存储在硬盘上。在Redis中,每个持久化规则单独占一行,根据实际情况设置即可。

如果您想完全禁用RDB持久化,可以将所有 save 规则删掉,或者将它们全部注释掉。另外,您也可以通过在Redis的配置文件中设置 save "" 来禁用RDB持久化。

总之,Redis RDB持久化方式提供了非常有效的Redis数据备份和恢复方式,并且默认情况下已经开启。使用上面的示例代码,您可以轻松地更改RDB持久化的频率和规则,以满足您的实际需求。

AOF 持久化

与快照持久化相比,AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF(append only file)方式的持久化(Redis 6.0 之后已经默认是开启了),可以通过 appendonly 参数开启:

appendonly yes

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令,Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中,然后再写入到 AOF 文件中(此时还在系统内核缓存区未同步到磁盘),最后再根据持久化方式( fsync策略)的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

只有同步到磁盘中才算持久化保存了,否则依然存在数据丢失的风险,比如说:系统内核缓存区的数据还未同步,磁盘机器就宕机了,那这部分数据就算丢失了。AOF 文件的保存位置和 RDB 文件的位置相同,都是通过 dir 参数设置的,默认的文件名是 appendonly.aof。

AOF持久化配置与RDB类似,可以通过Redis配置文件进行设置,常见的配置方式有:

  • APPENDONLY yes:启用AOF持久化方式。
  • appendfsync always:每次写入都会立即将数据同步到硬盘,这是最安全的配置。
  • appendfsync everysec:每秒钟将数据同步一次到硬盘。
  • appendfsync no:数据异步写入磁盘,每次之间的数据可能会有一定的数据丢失风险。但性能也是最好的。

以下是通过Redis命令行设置AOF持久化的示例代码:

# 启用AOF持久化并将数据同步到硬盘
CONFIG SET appendonly yes
CONFIG SET appendfsync always

在这个示例中,我们使用 CONFIG SET 命令来修改Redis的配置并设置AOF持久化方式。启用AOF方式后,Redis会在每个写命令执行时将其写入一个AOF文件,并使用指定的 appendfsync 配置将数据同步到硬盘。

在实际应用中,AOF方式被广泛使用,并且可以与RDB持久化方式配合使用,以实现多层数据备份和恢复。使用AOF方式,可以更好地保护Redis数据不丢失,以及提高整个系统的可靠性。

AOF 工作基本流程

AOF 持久化功能的实现可以简单分为 5 步:

  1. 命令追加(append):所有的写命令会追加到 AOF 缓冲区中。

  2. 文件写入(write):将 AOF 缓冲区的数据写入到 AOF 文件中。这一步需要调用write函数(系统调用),write将数据写入到了系统内核缓冲区之后直接返回了(延迟写)。注意!!!此时并没有同步到磁盘。

  3. 文件同步(fsync):AOF 缓冲区根据对应的持久化方式( fsync 策略)向硬盘做同步操作。这一步需要调用 fsync 函数(系统调用), fsync 针对单个文件操作,对其进行强制硬盘同步,fsync 将阻塞直到写入磁盘完成后返回,保证了数据持久化。

  4. 文件重写(rewrite):随着 AOF 文件越来越大,需要定期对 AOF 文件进行重写,达到压缩的目的。

  5. 重启加载(load):当 Redis 重启时,可以加载 AOF 文件进行数据恢复。

这里对上面提到的一些 Linux 系统调用再做一遍解释:

write:写入系统内核缓冲区之后直接返回(仅仅是写到缓冲区),不会立即同步到硬盘。虽然提高了效率,但也带来了数据丢失的风险。
同步硬盘操作通常依赖于系统调度机制,Linux 内核通常为 30s 同步一次,具体值取决于写出的数据量和 I/O 缓冲区的状态。

fsync:fsync用于强制刷新系统内核缓冲区(同步到到磁盘),确保写磁盘操作结束才会返回。

在这里插入图片描述

内核缓冲区

内核缓冲区(Kernel Buffer)是操作系统内核为了提高磁盘 I/O 性能而设置的一种缓存区域,作为用户进程和磁盘之间的缓冲区。当用户进程执行文件写操作时,数据先被拷贝到内核缓冲区中,然后再由内核将其写入磁盘。内核缓冲区可以减少磁盘 I/O 操作的次数和时间,达到提高写性能的目的。

在Redis的AOF持久化过程中,内核缓冲区也扮演着非常重要的角色。Redis通过调用系统调用write将AOF缓冲区中的数据写入内核缓冲区,并返回给Redis进程。这样做有助于减少Redis进程对磁盘的访问次数,提高写入性能。

然而,这种做法也有一定的风险。如果系统在写入内核缓冲区后发生崩溃或断电等情况,内核缓冲区中的数据可能会丢失。为了避免这种情况,Redis在写入内核缓冲区后,还需要调用系统调用fsync将内核缓冲区中的数据写入磁盘中,并通过强制同步的方式保证数据的可靠性和持久化。

综上所述,内核缓冲区是提高磁盘 I/O 性能的关键因素之一,但同时也需要注意数据的安全性。在Redis的AOF持久化中,需要注意平衡写入性能和数据安全性之间的关系,以便为应用程序提供最高效的永久存储方式。

AOF 持久化策略

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式( fsync策略),它们分别是:

  1. appendfsync always:主线程调用 write 执行写操作后,后台线程( aof_fsync 线程)立即会调用 fsync 函数同步 AOF 文件(刷盘),fsync 完成后线程返回,这样会严重降低 Redis 的性能(write + fsync)。

  2. appendfsync everysec:主线程调用 write 执行写操作后立即返回,由后台线程( aof_fsync 线程)每秒钟调用 fsync 函数(系统调用)同步一次 AOF 文件(write+fsync,fsync间隔为 1 秒)

  3. appendfsync no:主线程调用 write 执行写操作后立即返回,让操作系统决定何时进行同步,Linux 下一般为 30 秒一次(write但不fsync,fsync 的时机由操作系统决定)。

可以看出:这 3 种持久化方式的主要区别在于 fsync 同步 AOF 文件的时机(刷盘)。

为了兼顾数据和写入性能,可以考虑 appendfsync everysec 选项 ,让 Redis 每秒同步一次 AOF 文件,Redis 性能受到的影响较小。而且这样即使出现系统崩溃,用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候,Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

从 Redis 7.0.0 开始,Redis 使用了 Multi Part AOF 机制。顾名思义,Multi Part AOF 就是将原来的单个 AOF 文件拆分成多个 AOF 文件。在 Multi Part AOF 中,AOF 文件被分为三种类型,分别为:BASE:表示基础 AOF 文件,它一般由子进程通过重写产生,该文件最多只有一个。INCR:表示增量 AOF 文件,它一般会在 AOFRW 开始执行时被创建,该文件可能存在多个。HISTORY:表示历史 AOF 文件,它由 BASE 和 INCR AOF 变化而来,每次 AOFRW 成功完成时,本次 AOFRW 之前对应的 BASE 和 INCR AOF 都将变为 HISTORY,HISTORY 类型的 AOF 会被 Redis 自动删除。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

路上阡陌

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值