侧边栏壁纸
博主头像
Sakura 的小站

究竟从什么时候开始呢？

  • 累计撰写 95 篇文章
  • 累计创建 20 个标签
  • 累计收到 20 条评论

目 录CONTENT

文章目录
数据库

Redis持久化

Sakura
Sakura
2023-09-02 / 0 评论 / 0 点赞 / 26 阅读 / 0 字 / 正在检测是否收录...
温馨提示：
本文最后更新于105天前，若内容或图片失效，请留言反馈。 部分素材来自网络，若不小心影响到您的利益，请联系我们删除。

一: Redis 持久化基本介绍

官网 : 瑞迪斯持久性 |雷迪斯 (redis.io)

  • RDB ( Redis 数据库 ) : RDB 持久性以指定的时间间隔执行数据集的时间点快照。

  • AOF ( 仅追加文件 ) : AOF 持久性记录服务器收到的每个写入操作。然后可以在服务器启动时再次重播这些操作，重建原始数据集。命令的记录格式与 Redis 协议本身相同。

二: RDB

在指定的时间间隔，执行数据集的时间点快照

在指定的时间间隔内将内存中的数据集快照写入磁盘也就是行话讲的 Snapshot 内存快照，它恢复时再将硬盘快照文件直接读回到内存里

  • Redis的数据都在内存中，保存备份时它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中

Rdb 保存的是dump.rdb文件

1. Redis 6 和 7 的 RDB 规则

  • Redis6.0.16以下

  • Redis6.2 以及 Redis-7.0.0

2. RDB 自动触发

  1. 修改 5 秒 2 次修改自动触发

save 5 2

  1. 修改dump文件保存路径

  1. 修改 dump 文件名称

  1. redis 检查设置

127.0.0.1:6379> config get port
1) "port"
2) "6379"
127.0.0.1:6379> config get dir
1) "dir"
2) "/data"
127.0.0.1:6379> config get save
1) "save"
2) "5 2"

3. 备份恢复

在 Redis 执行FLUSHDB 或者 关闭的时候 , 会自动写入一份RDB数据

  • 执行FLUSHDB/FLUSHALL生成的 RDB 文件没有意义 , 因为里面是空的 ! ! !

  • 执行 SHUTDOWN 命令后会将当前的快照保存一次

Redis 启动后会从生成的 RDB 文件中读取文件 , 恢复原来的数据

3. RDB 手动触发

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

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

SAVE

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

BESAVE

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

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

127.0.0.1:6379> lastsave
(integer) 1693814041

-- 获取到时间戳后,在linux终端通过date获取时间
data -d @1693814041

4. 哪些操作会触发 RDB 快照

  1. 配置文件中默认的快照配置

  2. 手动save/bgsave命令

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

  4. 执行shutdown且没有设置开启 AOF 持久化

  5. 主从复制时，主节点自动触发

4. 如何禁用快照

redis-cli config set save ""

6. RDB 优化配置项

  • stop-writes-on-bgsave-error 默认为 YES

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

  • rdbcompression 默认是 YES

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

  • rdbchecksum 默认是 YES

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

  • rdb-del-sync-files 默认是 NO

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

三: AOF

以日志的形式来记录每个写操作，将 Rdis 执行过的所有写指令记录下来 ( 读操作不记录 ) ，只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

默认情况下，redis是没有开启AOF ( append only file ) 的。开启 AOF 功能需要设置配置 : appendonly yes

AOF 保存的是 appendonly.aof 文件

1. AOF 工作流程

1

Client 作为命令的来源，会有多个源头以及源源不断的请求命令。

2

在这些命令到达 Redis Server 以后并不是直接写入 AOF 文件，会将其这些命令先放入 AOF 缓存中进行保存。这里的 AOF 缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。

3

AOF 缓冲会根据 AOF 缓冲区同步文件的三种写回策略将命令写入磁盘上的 AOF 文件。

4

随着写入 AOF 内容的增加为避免文件膨胀，会根据规则进行命令的合并 ( 又称 AOF 重写 ) ，从而起到 AOF 文件压缩的目的。

5

当 Redis Server 服务器重启的时候会从 AOF 文件载入数据。

2. 三种写回策略

  • Always : 同步写回，每个写命令执行完立刻同步地将日志写回磁盘

  • Everysec : 默认策略 , 每秒写回，每个写命令执行完，只是先把日志写到八OF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘

  • no : 操作系统控制的写回，每个写命令执行完，只是先把日志写到八OF文件的内存缓冲区，由操作系统

    决定何时将缓冲区内容写回磁盘

3. AOF 配置

  1. AOF 启动

Reidis 默认开启的持久化策略是 RDB , AOF 需要手动开启

appendonly yes

  1. AOF 文件-保存路径

Redis6

dir /data : ADB 和 ROF 公用这个文件夹

Reids 7

dir /data : 若使用 ROF , 则会在该目录下新建一个文件夹用于保存 AOF 文件

  1. AOF 文件-保存名称

Redis6 有且仅有一个文件

Redis7 Multi Part AOF的设计 , 三个文件

只记录写操作命令 , 读操作命令不记录 , 并且记录到 incr 文件

4. AOF 修复

  1. 故意在 incr 文件尾部追加一行错误数据

  1. 重启 Redis 发现启动不了

  1. redis-check-aof --fix 进行修复

redis-check-aof --fix 文件路径

5. AOF 优缺点

  • 优点 :

    • 更好的保护数据不丢失、性能高、可做紧急恢复

  • 缺点 :

    • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

    • aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

6. AOF 重写机制 ( 重点 )

由于 AOF 持久化是 Redis7 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大 , 文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

Redis7 新增了重写机制

  1. 当 AOF 文件的大小超过所设定的峰值时，Redis 就会自动启动 AOF 文件的内容压缩 , 只保留可以恢复数据的最小指令集

  2. 可以手动使用命令 bgrewriteaof 来手动压缩

比说 redis 历史命令中又 set k1 v1 set k1 v2 set k1 v3 那么压缩完之后就会留下最后一条 set , 写入的文件是 bash 文件

  • 自动触发

注意 ，同时满足且的关系才会触发

  1. 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍

  1. 重写时满足的文件大小

-- 1. 开启AOF
appendonly yes

-- 2. 将重写峰值设置为1k 
auto-aof-rewrite-min-size 1k

-- 3. 关闭混合
aof-use-rdb-preamble no

-- 4. 删除之前全部的AOF和RDB

-- 5. 重启Redis服务器

-- 6. 反复写入 set k1 111111111
直到incr大小到1024

-- 7. 触发重写

  • 手动触发 bgrewriteaof

bgrewriteaof

7. AOF 重写原理

  1. 在重写开始前，redis 会创建一个 “ 重写子进程 ” ，这个子进程会读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

  2. 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。

  3. 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中

  4. 当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中

  5. 重写 aof 文件的操作，并没有读取旧的 aof 文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似

四: ROF + ADB 混合持久化

1. 同时开启两种持久化

在这种情况下 , 当 Redis 重启的时候会优先载入 AOF 文件来恢复原始的数据 , 因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整

2. ADB + RDB 混合模式

RDB 镜像做全量持久化 , AOF 做增量持久化

aof-use-rdb-preamble:yes

先使用 RDB 进行快照存储，然后使用 AOF 持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的 RDB 记录

这样的话，重启服务的时候会从 RDB 和 AOF 两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是 RDB 格式，一部分是 AOF 格式。--> AOF 包括了 RDB 头部 + AOF 混写

3. 纯缓存模式

同时关闭 RDB + AOF

  1. 关闭 RDB

禁用 rdb 持久化模式下，我们仍然可以使用命令 save 、bgsave 生成 rdb 文件

save ""

  1. 关闭 AOF

禁用 aof 持久化模式下，我们仍然可以使用命令 bgrewriteaof 生成 aof 文件

appendonly no

0
Redis
版权归属： Sakura
本文链接： https://www.sakurasss.top/archives/redischi-jiu-hua-rdb
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区