Redis持久化

✅作者简介：大家好，我是Leo，热爱Java后端开发者，一个想要与大家共同进步的男人
个人主页：Leo的博客
当前专栏： Java从入门到精通
✨特色专栏： Redis7从实战到高级
本文内容：Redis持久化
️个人小站 ：个人博客，欢迎大家访问
个人知识库：Leo知识库，欢迎大家访问

1. 总体介绍

官网地址： https://redis.io/docs/manual/persistence/

这里我做了一些简单的翻译

1.1 持久化双雄

1.2 为什么需要持久化

Redis是个基于内存的数据库。那服务一旦宕机，内存中的数据将全部丢失。通常的解决方案是从后端数据库恢复这些数据，但后端数据库有性能瓶颈，如果是大数据量的恢复，1、会对数据库带来巨大的压力，2、数据库的性能不如Redis。导致程序响应慢。所以对Redis来说，实现数据的持久化，避免从后端数据库中恢复数据，是至关重要的。

Redis持久化有哪些方式呢？为什么我们需要重点学RDB和AOF？

从严格意义上说，Redis服务提供四种持久化存储方案：RDB、AOF、虚拟内存（VM）和　DISKSTORE。虚拟内存（VM）方式，从Redis Version 2.4开始就被官方明确表示不再建议使用，Version 3.2版本中更找不到关于虚拟内存（VM）的任何配置范例，Redis的主要作者Salvatore Sanfilippo还专门写了一篇论文，来反思Redis对虚拟内存（VM）存储技术的支持问题。

至于DISKSTORE方式，是从Redis Version 2.8版本开始提出的一个存储设想，到目前为止Redis官方也没有在任何stable版本中明确建议使用这用方式。在Version 3.2版本中同样找不到对于这种存储方式的明确支持。从网络上能够收集到的各种资料来看，DISKSTORE方式和RDB方式还有着一些千丝万缕的联系，不过各位读者也知道，除了官方文档以外网络资料很多就是大抄。

最关键的是目前官方文档上能够看到的 Redis 对持久化存储的支持明确的就只有两种方案（https://redis.io/topics/persistence）：RDB 和 AOF。所以本文也只会具体介绍这两种持久化存储方案的工作特定和配置要点。

RDB 简称 Redis DataBase

AOF 简称 Append Only File

2. Redis DataBase

官网介绍

这里我对重点内容做了一些简单的翻译

RDB(Redis 数据库)：RDB持久化以指定的时间间隔执行数据集的时间点快照

2.1 RDB是什么

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

说人话就是 在指定的时间间隔，执行数据集的时间点快照，实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)其中，RDB就是Redis DataBase的缩写。

Redis也可以通过加载RDB文件，把数据从磁盘加载读取到Redis中。

2.2 RDB能做什么

• 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的snapshot内存快照，它恢复时再将硬盘快照文件直接读回到内存里。
• Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，一锅端。
• RDB保存的是dump.rdb文件。

3. RDB案例演示

3.1 需求说明

配置文件(6 VS 7)

Redis6.0.16及以下

Redis6. 以及 Redis-7.2.0

3.2 操作步骤

1. 自动触发

Redis7版本，按照redis.conf里配置的 save

本次案例5秒2次修改

修改dump文件保存路径

修改dump文件名称

触发备份

第一种情况，5秒内保存2次

第二种情况，两次保存间隔超过5秒

注：RDB 持久化是 Redis 的一种持久化机制，它会在 Redis 数据发生修改时对内存中的数据进行快照，然后保存到磁盘，以保证数据的持久性。通常情况下，RDB 保存快照的时间间隔由配置文件中的参数 save 决定，格式为 save ，表示在 秒内，如果数据有 次修改，则会进行一次快照。

在题目描述的情况下，RDB 设置了每 5 秒进行一次快照，但是如果在 5 秒内修改次数超过了 2 次，也会进行快照。这是因为在 Redis 中，保存快照并不是在规定的时间到达后才进行，而是在修改数据时和时间间隔条件的双重限制下才进行的。

如果限制只按时间间隔来进行保存快照，则会出现两个问题：

如果时间间隔太大，那么 Redis 持久化的数据可能会丢失，并且故障恢复时的数据可能会受到影响。

如果时间间隔太小，那么数据的保存成本就会过高，并可能导致 Redis 运行效率下降。

因此，Redis 引入了按时间和数据修改次数双重限制的快照保存机制，以在灵活性和效率之间取得平衡。如果在 5 秒内修改的次数超过 2 次，则说明数据的变化较快，在此情况下保存快照并不会带来明显的性能问题。因此，Redis 将其纳入保存快照的范围，以保证数据的安全和一致性

如何恢复

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

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

• 执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义

物理恢复，一定要将服务产生的RDB文件备份一份，然后分机隔离，避免生产上物理损坏后备份文件也挂了。

2. 手动触发

使用save或者bgsave命令

Redis提供了两个命令来生成RDB文件，分别是 save 和 bgsave

save：在主程序中执行会阻塞当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，线上禁止使用

bgsave(默认)：

• redis会在后台异步进行快照操作，不阻塞快照同时还可以相应客户端请求，该触发方式会fork一个子进程由子进程复制持久化过程

• 官网说明

  

• Redis会使用bgsave对当前内存中的所有数据做快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据。

• fork是什么？
  在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后会exec系统调用，处于效率考虑，尽量避免膨胀

• LASTSAVE

  可以通过 lastsave 命令获取最后一次成功执行快照的时间

bgsave流程图如下所示

4. RDB优缺点

4.1 优点

官网说明：

我这里进行了简单的翻译

• RDB是Redis 数据的一个非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望在最近的24小时内每小时归档一次RDB文件，并在30天内每天保存一个RDB快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。
• RDB非常适合灾难恢复，它是一个可以传输到远程数据中心或Amazon S3(可能已加密）的压缩文件。
• RDB最大限度地提高了Redis 的性能，因为Redis 父进程为了持久化而需要做的唯一工作就是派生一个将完成所有其余工作的子进程。父进程永远不会执行磁盘I/О或类似操作。
• 与AOF 相比，RDB允许使用大数据集更快地重启。
• 在副本上，RDB支持重启和故障转移后的部分重新同步。

总结：

• 适合大规模的数据恢复
• 按照业务定时备份
• 对数据完整性和一致性要求不高
• RDB文件在内存中的加载速度要比AOF快很多

4.2 缺点

官网说明：

我这里进行了简单的翻译

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

小总结：

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，快照之间的数据会丢失
• 内存数据的全量同步，如果数据量太大会导致IO严重影响服务器性能
• RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大致2倍的膨胀性，需要考虑

模拟数据丢失：

5. 有关RDB快照文件

5.1 如何检查修复dump.rdb文件？

cd /usr/local/bin			

进入到 redis 安装目录，执行 redis-check-rdb 命令 redis-check-rdb ./redisconfig/dump.rdb

5.2 哪些情况会触发RDB快照

1. 配置文件中默认的快照配置
2. 手动save/bgsave命令
3. 执行flushdb/fulshall命令也会产生dump.rdb文件，但是也会将命令记录到dump.rdb文件中，恢复后依旧是空，无意义
4. 执行shutdown且没有设置开启AOF持久化
5. 主从复制时，主节点自动触发

5.3 如何禁用快照

1. 动态所有停止RDB保存规则的方法：

   redis-cli config set value ""
   

2. 手动修改配置文件

5.4 RDB优化配置项详解

配置文件SNAPSHOTTING模块

• save ：配置快照保存条件

• dir：配置快照保存目录地址

• dbfilename：配置快照的文件名

• stop-writes-on-bgsave-error：

  

  默认yes，如果配置成no，表示不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的请求

• rdbcompression：

  

  默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，Redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能

• rdbchecksum：

  

  默认yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

• rdb-del-sync-files：

在没有持久化的情况下删除复制中使用的RDB文件。默认情况下no，此选项是禁用的。

总结：

AOF持续更新中。。。。。