Redis7_02 基础篇第二章 Redis的持久化 (上)

孤尘Java

已于 2024-04-10 14:52:28 修改

阅读量838

点赞数 9

分类专栏： Redis从小白到精通文章标签： redis java 数据库

于 2024-04-09 00:49:35 首次发布

本文链接：https://blog.csdn.net/qq_33168558/article/details/137524040

版权

Redis从小白到精通专栏收录该内容

22 篇文章 6 订阅

订阅专栏

本文主要介绍

Redis持久化方式之一 RDB方式(也称SnapShot方式)

下篇会讲解另一种持久化方式 AOF

下篇链接 :

1 Redis持久化简介

1.1 什么是持久化?

Redis的持久化是指将Redis服务器中的数据持久化到磁盘上的过程，以确保数据在Redis重启或发生故障时不会丢失。持久化机制可以将内存中的数据写入磁盘，从而实现数据的持久化存储。

1.2 为什么要有持久化?

持久化的重要性体现在以下几个方面：

数据安全性：持久化可以确保即使在Redis服务器重启或发生故障时，数据也不会丢失。通过将数据写入磁盘，可以保证数据的持久性，防止数据丢失或损坏。
数据恢复：通过持久化机制，可以在Redis重启时将数据从磁盘加载到内存中，实现数据的恢复。这对于保证数据的持久性和可靠性非常重要。
高可用性：持久化可以帮助确保数据的高可用性。即使发生意外情况，如服务器宕机或断电等，数据也可以通过持久化机制进行恢复，保证系统的持续运行。
灾难恢复：持久化使得在灾难发生时可以更容易地恢复数据。通过定期备份数据到磁盘，可以减少数据丢失的风险，同时提高数据的安全性和可靠性。

总的来说，持久化是确保数据持久存储、保证数据安全、实现数据恢复和提高系统可靠性的重要手段。通过选择适合的持久化方式，并根据实际需求进行配置和优化，可以有效地保护和管理Redis中的数据。

1.3 Redis持久化概览

Redis提供了两种主要的持久化方式，分别是快照（Snapshot）和日志（Append-only file，AOF）。这两种方式可以确保在Redis重启时数据不会丢失。

快照（Snapshot）持久化：
- 在快照持久化中，Redis会将内存中的数据以快照的形式写入磁盘文件。这个过程是通过fork一个子进程，然后子进程负责将数据写入磁盘，主进程继续处理命令请求。
- 快照持久化的优点是可以在一个特定的时间点创建数据的备份，且备份文件是紧凑的二进制文件，适合用于全量恢复。
- 缺点是当数据量较大时，fork子进程可能会导致性能问题，而且如果发生故障，可能会丢失最后一次快照之后的数据。
日志（Append-only file，AOF）持久化：
- 在AOF持久化中，Redis会将写命令追加到一个文件中，记录了对数据的修改操作。这些写命令以追加的方式写入文件，形成一个操作日志。
- AOF持久化的优点是可以保证更高的数据安全性，因为可以通过重新执行AOF文件中的写命令来恢复数据。另外，AOF文件通常比快照文件更小。
- 缺点是AOF文件可能会变得很大，影响恢复速度，而且在Redis重启时，AOF文件需要重新加载并重新执行所有写命令，可能会影响性能。

除了以上两种主要的持久化方式，Redis还提供了混合持久化（Mixed persistence）的方式，即同时使用快照和AOF。在混合持久化中，Redis会先通过AOF文件进行恢复，然后再用快照文件进行全量恢复，以此来提高恢复速度。

用户可以根据自己的需求和应用场景选择适合的持久化方式，或者结合使用多种持久化方式来达到更好的数据保护和性能表现。

Redis默认开启了RDB持久化,而没有开启AOF持久化. AOF持久化的开启需要自行修改配置文件.

2 Redis持化双雄之一RDB(Redis DataBase)

RDB持久化也就是上面讲到的Snapshot持久化.

RDB 持久化即为: 以指定的时间间隔执行所有数据集的时间点快照,将快照写入磁盘中方式持久化数据。

当出现特殊情况,Redis丢失了数据时,通过持久化机制,Redis再重启后就可以把之前保存的快照文件再写回到redis内存中.

快照文件的后缀为rdb,例如dump.rdb.

2.1 RDB持久化的参数配置

6.0.16及以下的版本中

具体可以参考redis.conf文件第307行

6.0.16以后的版本(不包含6.0.16)

2.2 RDB持久化的实操

配置修改准备

注意修改的是自定义的配置文件,之前我们存放的位置是 /myredis/redis7.conf

为了更加容易的触发备份操作,我们修改了配置文件

在配置文件的434行加上我们自行定义的rdb策略 save 5 2 ,读者可以快速定位修改

此外,我们还应当修改快照文件的位置,和文件名,方便后期查看,定位,以及分辨该快照文件来自于哪一个端口下的redis服务

首先修改快照文件保存位置配置文件下的505行

注意,修改的文件位置要保证该文件夹存在

若需要自行创建,先退出客户端连接, 在/myredis文件夹下

执行 mkdir /myredis/dumpfiles 即可

再来修改快照文件的文件名在第482行

推荐修改为 dump+端口号的形式

自动触发快照

情况一

情况二

由情况二可知,自动快照的策略不是两次修改必须集中在同一个五秒内, 而是一个五秒只能快照一次, 每过五秒检查累计的 key修改次数, 达到两次立即快照.

结论 save 5 2

不是说 2次修改必须集中在同一个五秒内

而是说,每五秒检查一次key累计更新的次数,到达两次就立即快照.

如何从硬盘中恢复数据?

1.将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

2.备份成功后故意用flushdb清空redis，看看是否可以恢复数据

清空前,我们先把原rdb自行备份一下(通过改名的方式,不让它被覆盖实现备份)

可以发现,清空后在重启服务,redis没能恢复原来的数据,说明执行flushdb 或 flushall 命令生成的rdb文件是空的没有任何意义

把改名的原来有数据的rdb文件改回来, 再启动服务,发现数据自动恢复了!

结论

执行fulshdb/flushall命令,也会产生dump.rdb文件,但是这个文件是空的没有任何意义, 因此真实有数据的rdb文件我们一定要及时备份,最好的当然是分机备份,也就是使用物理恢复法. 言外之意就是把rdb文件备份到和redis服务不同的机器上去.

手动触发快照

触发方式,使用两大命令Save 或 BGSave触发,触发后,会开辟子进程来备份redis的所有数据,写入到一个缓存文件中, 备份完成后,将会用这个新的rdb文件替换旧的rdb文件

注意

生产中绝对禁止使用Save方法触发rdb,因为save 后开辟的子进程会直接阻塞 redis的主进程服务,会导致严重的生产危险!

而BGSave不会有这样的问题.BGsave 是异步的

BGsave执行流程

BGsave实操演示

RDB的优势

性能高效：RDB持久化是将数据以快照的形式保存到磁盘上，相对于AOF持久化来说，在数据恢复时速度更快，适合对性能要求较高的场景。
节省空间：RDB文件是一个二进制文件，相比AOF文件通常更小，可以节省磁盘空间。
适合灾难恢复：RDB文件是一个全量的数据快照，适合用于灾难恢复，能够快速恢复整个数据集。
灵活性：RDB持久化支持手动和自动触发，用户可以根据需要灵活配置持久化策略。
降低数据丢失风险：RDB持久化可以定期将数据写入磁盘，降低了数据丢失的风险，尤其是在发生意外故障时。

总的来说，RDB持久化适合对性能要求高、对数据恢复速度和灾难恢复能力有要求的场景，可以提供高效的数据持久化和保护。

RDB的劣势

数据丢失风险：RDB持久化并不是最适合需要最小化数据丢失风险的情况，因为RDB是周期性生成数据快照，如果Redis在未正确关闭的情况下停止工作，可能会丢失最新数据。
频繁fork操作：RDB持久化需要频繁进行fork操作以使用子进程在磁盘上持久化数据，当数据集很大时，这可能会耗费较多时间，并且可能导致Redis在服务客户端时出现短暂的停顿。相比之下，AOF持久化的fork操作频率较低，可以根据需要调整日志重写的频率，而无需进行持久性方面的权衡。