Redis基础系列-持久化

2023-12-13 08:59:13

Redis基础系列-持久化

1. 什么是持久化

内存中的数据保存到磁盘中

2. 为什么要持久化

Redis持久化可以将内存中的数据保存到硬盘上，保证Redis的数据持久性和可靠性，以避免数据在异常情况下丢失和损坏。持久化是保证Redis应用安全的重要手段。

3. 持久化的两种方式

redis持久化官网介绍

3.1 持久化方式1：RDB(redis默认持久化方式)

RDB（Redis DataBase）模式是Redis的默认持久化模式。它会将Redis在某个时间点上的数据生成一个快照，并将快照以二进制形式保存在磁盘上。RDB模式的优点在于快速且紧凑，适合用于备份和恢复数据。然而，由于定期生成快照的特性，可能会导致在两次快照之间的数据丢失。

适用场景： 对数据的实时性要求不高，可以接受一定程度的数据丢失，同时对于需要频繁备份和恢复数据的场景。

3.11 配置步骤-自动触发

操作步骤：

1.修改5秒2次变更

save 5 2

2.修改快照文件保存路径（需优先创建：dumpfiles目录）

dir /myredis/dumpfiles

3.修改快照名称

dbfilename dump6379.rdb

重启redis验证配置是否成功(略)

127.0.0.1:6379> config get save
1) "save"
2) "5 2"
127.0.0.1:6379> config get dir
1) "dir"
2) "/myredis/dumpfiles"
127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump6379.rdb"
127.0.0.1:6379>

触发配置

// 变更两次，查看是否会生产快照文件
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379>

备份恢复
- redis 执行flushall也会产生dump文件，不过是空的
- redis 执行shutdown也会产生dump文件，不过是空的
- redis 直接重启就会加载备份的快照文件

3.12 配置步骤-手动触发

save命令

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

bgsave(Background Save)命令(默认)

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

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

127.0.0.1:6379> lastsave
(integer) 1701683772
127.0.0.1:6379>

[root@Docker110]# date -d @1701683772
2023年 12月 04日 星期一 17:56:12 CST

3.12 优点

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

3.13 缺点

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

3.14 检查和修复RDB快照文件

redis-check-rdb /myredis/dumpfiles/dump6379.rdb

3.15 哪些情况会触发RDB快照

配置文件中默认的快照配置
手动save/bgsave命令
执行flushall/flushdb命令也会产生dump.rdb文件，但里面是空的，无意义
执行shutdown且没有设置开启AOF持久化
主从复制时，主节点自动触发

3.16 如何禁用快照

命令方式:

redis-cli config set save ""

修改配置文件：

3.17 RDB优化配置项详解

stop-writes-on-bgsave-error


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

rdbcompression

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

rdbchecksum

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

rdb-del-sync-files

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

3.2 持久化方式2：AOF

AOF（Append Only File）模式是另一种常用的持久化模式。它会将每个写操作都追加到一个日志文件中，从而记录了Redis的所有操作命令。在恢复数据时，Redis会重新执行这些操作命令以还原数据。AOF模式的优点在于数据的持久化更加可靠，不会丢失任何写操作。然而，由于需要记录每一条写命令，相对于RDB模式，AOF模式的写入性能较差。

适用场景： 对数据的可靠性要求较高，需要最大程度地避免数据丢失的场景

3.2.1 AOF持久化工作流程

序号	描述
1	Client作为命令的来源，会有多个源头以及源源不断的请求命令。
2	在这些命令到达Redis Server以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
3	AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
4	随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
5	当Redis Server服务器重启的时候会从AOF文件载入数据。

3.2.2 三种写回策略

配置项	写回时机	优点	缺点
Always	同步写回	可靠性高，数据基本不丢失	每个写命令都要落盘，性能影响较大
Everysec(默认)	每秒写回	性能适中	宕机时丢失1秒内的数据
No	操作系统控制	性能好	宕机时丢失数据较多

3.2.3 AOF配置说明

配置指令	描述	配置示例
appendonly	是否开启AOF	appendonly yes
appendfilename	AOF文件名称	appendfilename “appendonly.aof”
dir+appenddirname	AOF文件路径	dir /myredis+“appendonlydir”
appendfsync	AOF同步写回方式	everysec/always/no
no-appendfsync-on-rewrite	AOF重写期间是否同步写回	no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage auto-aof-rewrite-min-size	AOF重写触发配置，触发重写的比例阈值和最小文件大小阈值；满足配置文件中的选项后，Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍目文件大于64M时	auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

3.2.4 AOF文件说明

Redis7.0 Multi Part AOF的设计
顾名思义，MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件(redis6只有一个文件)。在MP-AOF中，我们将AOF分为三种类型分别为:
它一般由子进程通过重写产生，该文件最多只有一个

BASE: 表示基础AOF
INCR: 表示增量AOF，
它一般会在AOFRW开始执行时被创建，该文件可能存在多个。
HISTORY: 表示历史AOF，它由BASE和INCR AOF变化而来，每次AOFRW成功完成时本次AOFRW之前对应的BASE和INCR AOF都将变为HISTORY，HISTORY类型的AOF会被Redis自动删除为了管理这些AOF文件我们引入了一个manifest (清单) 文件来跟踪、管理这些AOF。同时，为了便于AOF备份和拷贝，我们将所有的AOF文件和manifest文件放入一个单独的文件目录中，目录名由appenddirname配置
(Redis 7.0新增配置项) 决定。

// 如有下的aof文件存在
1.基本文件
appendonly.aof.1base .rdb
2.增量文件
appendonly.aof.1.incr.aof
appendonly.aof.2.incr.aof
3.清单文件
apendonly.aof.manifest

AOF路径说明

redis7.0 AOF文件路径：dir + appenddirname 其中

dir是RDB和AOF共用配置参数
appenddirname 是redis7新增的aof独特配置

// 几种类型文件的前缀,后跟有关序列和类型的附加信息
appendfilename"appendonly.aof
//新版本增加的目录配置项目
appenddirname "appendonlydir"

3.2.5 AOF恢复

采用 flushdb + shutdown模拟redis异常终止，需要注意的是：

flushdb也是写操作，也会写入aof文件，所以在执行flushdb之前备份aof文件，flushdb之后可以使用备份的aof 覆盖掉aof文件
也可以不备份，在执行完flushdb + shutdown操作之后，手动删除增量文件中的最后flushdb命令
为了防止RDB文件的干涉，重启之前删除RDB文件，或者模拟整个过程中关闭RDB持久化

最后，重启reids便可加载aof文件进行数据恢复

3.2.6 AOF文件修复

故意破环aof增量文件

[root@Docker110 appendonlydir]# vim appendonly.aof.1.incr.aof 
*2
$6
......
$1
0
jasitfgjwaior943q294r534jiosa(*(u

重启启动之后查看

居然启动失败，赶紧查看一下日志，日志文件

日志文件路径的配置

建议让我们修复一下aof文件

再次启动，成功恢复

3.2.7 AOF重写机制

AOF 文件的不断增长可能会导致性能问题。为了解决这个问题，Redis 实现了 AOF 重写机制。AOF 重写是一种优化技术，通过在后台进程中重构 AOF 文件的数据，来减小 AOF 文件的大小。
启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集

也就是说 AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，
然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。
AOF 文件重写触发机制: 过 redis.conf 配置文件中的 auto-aofrewrite-percentage: 默认值为100，以及auto-aofrewritemin-size: 64mb 配置，
也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍目文件大于64M时触发

重写机制的配置

注意 ，同时满足，且的关系才会触发
1 根据上次重写后的aof大小，判断当前aof大小是不是增长了1倍
2 重写时满足的文件大小

触发方式

1. 自动触发：满足重写机制配置条件，就会自动后台执行重写，也就是压缩aof
2. 手动触发: 客户端向服务器发送 bgrewriteaof 命令

重写原理

1.AOF 重写机制的原理是根据 Redis 进程内的数据生成一个新的 AOF 文件，只包含当前有效和存在的数据的写入命令，而不是历史上所有的写入命令 。
2.AOF 重写机制是通过 fork 出一个子进程来完成的，子进程会扫描 Redis 的数据库，并将每个键值对转换为相应的写入命令，然后写入到一个临时文件中 。
3.在子进程进行 AOF 重写的过程中，主进程还会继续接收和处理客户端的请求，如果有新的写操作发生，主进程会将这些写操作追加到一个缓冲区中，并通过管道通知子进程 。
4.子进程在完成 AOF 重写后，会将缓冲区中的写操作也追加到临时文件中，然后向主进程发送信号，通知主进程可以切换到新的 AOF 文件了 。
5.主进程在收到子进程的信号后，会将缓冲区中的写操作再次追加到临时文件中（以防止在此期间有新的写操作发生），然后用临时文件替换旧的 AOF 文件，并关闭旧的 AOF 文件

验证

文件大小调整为 1k 方便验证

反复多次设置k1

查看增量aof内容的的变化、aof文件名称以及大小的变化

可以清晰的看到重写之后的变化：

base基础aof由0变成130、增量aof由384变成0、清单aof没有变化，整体大小进行了压缩
文件序号由1变成了

3.2.8 总结

更好的保护数据不丢失、性能高、可做紧急恢复相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdbaof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

3.3 持久化方式3：混合模式RDB+AOF

3.3.1 混合模式介绍

我们首先看看官网对混合模式的介绍：

一般来说，如果你想要一个与PostgreSQL相媲美的数据安全程度，你应该使用这两种持久化方法。RDB镜像做全量持久化，AOF做增量持久化
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据

3.3.2 开启混合方式设置

设置aof-use-rdb-preamble的值为 yes   yes表示开启，设置为no表示禁用

先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。
简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式(AOF包括了RDB头部+AOF混写)

3.3.3 数据的加载流程

在同时开启rdb 和aof 持久化时，重启时只会加载 aof 文件，不会加载 rdb 文件，rdb做为一个万一的策略

3.4 纯缓存模式

同时关闭RDB+AOF

禁用RDB(save "")
禁用RDB持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
禁用AOF(appendonly no)
禁用AOF持久化模式下，我们仍然可以使用命令bgrewriteaof生成aof文件

4. 参考和感谢

尚硅谷Redis零基础到进阶，最强redis7教程，阳哥亲自带练

文章来源:https://blog.csdn.net/CSDN_LJK/article/details/134881185
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！

Redis基础系列-持久化