Redis基础系列-持久化
文章目录
- Redis基础系列-持久化
- 1. 什么是持久化
- 2. 为什么要持久化
- 3. 持久化的两种方式
- 3.1 持久化方式1：RDB(redis默认持久化方式)
- 3.11 配置步骤-自动触发
- 3.12 配置步骤-手动触发
- 3.12 优点
- 3.13 缺点
- 3.14 检查和修复RDB快照文件
- 3.15 哪些情况会触发RDB快照
- 3.16 如何禁用快照
- 3.17 RDB优化配置项详解
- 3.2 持久化方式2：AOF
- 3.2.1 AOF持久化工作流程
- 3.2.2 三种写回策略
- 3.2.3 AOF配置说明
- 3.2.4 AOF文件说明
- 3.2.5 AOF恢复
- 3.2.6 AOF文件修复
- 3.2.7 AOF重写机制
- 3.2.8 总结
- 3.3 持久化方式3：混合模式RDB+AOF
- 3.3.1 混合模式介绍
- 3.3.2 开启混合方式设置
- 3.3.3 数据的加载流程
- 3.4 纯缓存模式
- 4. 参考和感谢
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 直接重启就会加载备份的快照文件
- 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教程，阳哥亲自带练
more命令)
)
