【Redis经典面试题六】Redis的持久化机制是怎样的?

目录

一、Redis的持久化机制

[1.1 RDB](#1.1 RDB)

[1.2 AOF](#1.2 AOF)

[1.3 比较](#1.3 比较)

[1.4 混合持久化](#1.4 混合持久化)

[二、RDB 和 AOF 的写回策略分别是什么?](#二、RDB 和 AOF 的写回策略分别是什么?)

[2.1 RDB的写回策略](#2.1 RDB的写回策略)

定期触发

手动触发

[2.2 AOF 的写回策略](#2.2 AOF 的写回策略)

三、Redis能完全保证数据不丢失吗?


一、Redis的持久化机制

Redis提供了两种持久化的机制,分别是RDB和AOF。

1.1 RDB

RDB是将Redis的内存中的数据定期保存到磁盘上,以防止数据在Redis进程异常退出或服务器断电等情况下丢失。

RDB的优点是:快照文件小、恢复速度快,适合做备份和灾难恢复。

RDB的缺点是:定期更新可能会丢数据

1.2 AOF

AOF是将Redis的所有写操作追加到AOF文件(Append Only File)的末尾,从而记录了Redis服务器运行期间所有修改操作的详细记录。当Redis重新启动时,可以通过执行AOF文件中保存的写操作来恢复数据。

但是如果Redis刚刚执行完一个写命令,还没来得及写AOF文件就宕机了,那么这个命令和相应的数据就会丢失了。但是他也比RDB要更加靠谱一些。

AOF的优点是:可以实现更高的数据可靠性、支持更细粒度的数据恢复,适合做数据存档和数据备份。

AOF的缺点是:文件大占用空间更多,每次写操作都需要写磁盘导致负载较高。

1.3 比较

RDB 和 AOF 在数据可靠性、性能、存储空间占用等方面都有不同的优缺点,具体可以根据实际业务需求和硬件条件来选择合适的持久化机制,或者同时使用两种持久化机制来实现更高的数据可靠性。

特性 RDB AOF
数据可靠性 可能会丢失最后一次快照之后的数据 保证最后一次写操作之前的数据不会丢失
性能 读写性能较高,适合做数据恢复 写性能较高,适合做数据存档
存储空间占用 快照文件较小,占用空间较少 AOF 文件较大,占用空间较多
恢复时间 从快照文件中恢复数据较快 从 AOF 文件中恢复数据较慢

1.4 混合持久化

AOF 和 RDB 各自有优缺点,为了让用户能够同时拥有上述两种持久化的优点,Redis 4.0 推出了 RDB-AOF 混合持久化。

在开启混合持久化的情况下,AOF 重写时会把 Redis 的持久化数据,以 RDB 的格式写入到 AOF 文件的开头,之后的数据再以 AOF 的格式追加到文件的末尾。

aof-use-rdb-preamble 是开启混合模式的参数。

混合持久化结合了 RDB 和 AOF 持久化的优点,开头为 RDB 的格式,使得 Redis 可以更快地启动,同时结合 AOF 的优点,又减低了大量数据丢失的风险。

但是,在 AOF 文件中添加了 RDB 格式的内容,使得 AOF 文件的可读性变得很差;如果开启混合持久化,那么此混合持久化 AOF 文件,是不能用在旧版本中的,不向下兼容的。

二、RDB 和 AOF 的写回策略分别是什么?

写回策略是指将数据从内存写入到持久化存储(如磁盘)的方式和时机。在 Redis 中,不同的持久化机制有着不同的写回策略。

2.1 RDB的写回策略

在 Redis 中,RDB 的写回策略主要包括以下几个方面:

定期触发

Redis 通过配置文件中的 save 参数定义了 RDB 的自动保存条件。以下是默认配置的示例:

复制代码
save 900 1    # 如果 900 秒内至少有 1 个键发生变化,则保存快照
save 300 10   # 如果 300 秒内至少有 10 个键发生变化,则保存快照
save 60 10000 # 如果 60 秒内至少有 10000 个键发生变化,则保存快照

策略

  • Redis 会定期检查这些条件,如果满足,触发 RDB 的保存操作。

  • 条件可以通过修改 redis.conf 文件自定义,也可以通过命令动态设置,例如:

    CONFIG SET save "300 10 60 10000"

手动触发

在 Redis 中,我们可以通过以下命令手动生成 RDB 文件:

  • SAVE:会阻塞 Redis 服务器,直到快照完成。
  • BGSAVE:在后台异步生成 RDB 文件,不会阻塞 Redis。

SAVE 操作直接在主线程完成,不适合生产环境。BGSAVE 会 fork 一个子进程生成快照,更高效,但需要一定的系统资源(如内存和 CPU)。

2.2 AOF 的写回策略

AOF 有三种数据写回策略,分别是 Always、Everysec 和 No。

  • Always:同步写回。每个写命令执行完,立马同步地将日志写回磁盘。
  • Everysec:每秒写回。每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,每隔一秒把缓冲区中的内容写入磁盘。
  • No:操作系统控制的写回。每个写命令执行完,只是先把日志写到 AOF 文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘。

"同步写回"可靠性肯定是最高的,但是它在每一个写命令后都有一个落盘操作,而且还是同步的,这和直接写磁盘类型的数据库有啥区别?

"操作系统控制的写回"这种是最不靠谱的,谁知道操作系统啥时候帮你做持久化,万一没来及持久化就宕机了,不就 gg 了。

"每秒写回"是在二者之间折中了一下,异步的每秒把数据写会到磁盘上,最大程度的提升效率和降低风险。

三、Redis能完全保证数据不丢失吗?

Redis提供了两种持久化的机制,分别是RDB和AOF。AOF和RDB各自有优缺点,为了让用户能够同时拥有上述两种持久化的优点,Redis 4.0推出了RDB-AOF混合持久化。

在开启混合持久化的情况下,AOF重写时会把Redis的持久化数据,以RDB的格式写入到AOF文件的开头,之后的数据再以AOF的格式追加到文件的末尾。

那么,有了这个机制之后,能保证Redis的数据一定不丢吗?

不能!

首先Redis是基于内存存储的,虽然有了RDB和AOF的持久化机制,当Redis进程异常退出或服务器断电等情况发生时,内存中的数据可能会丢失。

有一种极端情况,那就是AOF这个持久化方案中,有一种Always的写回策略,即同步写回。也就是说每个写命令执行完,立马同步地将日志写回磁盘。

但是即使是在 always 策略下,也不能保证 100% 不丢失数据的,主要出于以下原因:

  1. 磁盘和系统故障:如果在写入操作和同步到磁盘之间发生硬件故障或系统崩溃,可能会丢失最近的写操作。

  2. 操作系统缓冲区:即使 Redis 请求立即将数据同步到磁盘,操作系统的 I/O 缓冲区可能会导致实际写入磁盘的操作延迟发生。如果在写入缓冲区之后,没写磁盘前,机器挂了,那么数据就丢了。

    操作系统缓冲区,通常指的是操作系统用于管理数据输入输出(I/O)的一种内存区域。当程序进行文件写入操作时,数据通常首先被写入到这个缓冲区,而不是直接写入到硬盘。

  3. 磁盘写入延迟:磁盘的写入并非实时完成,特别是在涉及到机械硬盘时,写入延迟主要由磁盘旋转速度(RPM)和寻道时间决定。如果在这个延迟过程中,机器挂了,那么数据也就丢了。

归根结底,Redis 就不是用来干持久化的。要持久化,就用关系型数据库。

相关推荐
西岭千秋雪_22 分钟前
Redis性能优化
数据库·redis·笔记·学习·缓存·性能优化
chuanauc25 分钟前
Kubernets K8s 学习
java·学习·kubernetes
极限实验室35 分钟前
INFINI Labs 产品更新 | INFINI Console 1.29.6 发布 – 优化监控图表异常毛刺等
数据库·产品
先睡38 分钟前
优化MySQL查询
数据库·sql
一头生产的驴42 分钟前
java整合itext pdf实现自定义PDF文件格式导出
java·spring boot·pdf·itextpdf
YuTaoShao1 小时前
【LeetCode 热题 100】73. 矩阵置零——(解法二)空间复杂度 O(1)
java·算法·leetcode·矩阵
zzywxc7871 小时前
AI 正在深度重构软件开发的底层逻辑和全生命周期,从技术演进、流程重构和未来趋势三个维度进行系统性分析
java·大数据·开发语言·人工智能·spring
小张是铁粉1 小时前
oracle的内存架构学习
数据库·学习·oracle·架构
专注API从业者1 小时前
构建淘宝评论监控系统:API 接口开发与实时数据采集教程
大数据·前端·数据库·oracle
Uluoyu1 小时前
redisSearch docker安装
运维·redis·docker·容器