内存中的数据保存到磁盘中
Redis持久化可以将内存中的数据保存到硬盘上， 保证Redis的数据持久性和可靠性 ， 以避免数据在异常情况下丢失和损坏 。持久化是保证Redis应用安全的重要手段。
redis持久化官网介绍
RDB（
Redis DataBase
）模式是Redis的默认持久化模式。它会将Redis在某个时间点上的数据生成一个快照，并将快照以二进制形式保存在磁盘上。RDB模式的优点在于快速且紧凑，适合用于备份和恢复数据。然而，由于定期生成快照的特性，可能会导致在两次快照之间的数据丢失。
适用场景： 对数据的实时性要求不高，可以接受一定程度的数据丢失，同时对于需要频繁备份和恢复数据的场景。
1.修改5秒2次变更
save 5 2
2.修改快照文件保存路径（需优先创建：dumpfiles目录）
dir /myredis/dumpfiles
3.修改快照名称
dbfilename dump6379.rdb
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>
flushall
也会产生dump文件，不过是空的
shutdown
也会产生dump文件，不过是空的
在主程序中执行会
阻塞
当前redis服务器，直到持久化工作完成执行save命令期间，Redis不能处理其他命令，
线上禁止使用
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
redis-check-rdb /myredis/dumpfiles/dump6379.rdb
redis-cli config set save ""
默认yes
如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，
也能确保redis继续接受新的写请求
默认yes
对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
默认yes
在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能
rdb-del-sync-files：在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。
AOF（
Append Only File
）模式是另一种常用的持久化模式。它会将每个写操作都追加到一个日志文件中，从而记录了Redis的所有操作命令。在恢复数据时，Redis会重新执行这些操作命令以还原数据。AOF模式的优点在于数据的持久化更加可靠，不会丢失任何写操作。然而，由于需要记录每一条写命令，相对于RDB模式，AOF模式的写入性能较差。
适用场景： 对数据的可靠性要求较高，需要最大程度地避免数据丢失的场景
| 序号 | 描述 |
|---|---|
| 1 | Client作为命令的来源，会有多个源头以及源源不断的请求命令。 |
| 2 | 在这些命令到达Redis Server以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。 |
| 3 | AOF缓冲会根据AOF缓冲区同步文件的 三种写回策略 将命令写入磁盘上的AOF文件。 |
| 4 | 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。 |
| 5 | 当Redis Server服务器重启的时候会从AOF文件载入数据。 |
| 配置项 | 写回时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步写回 | 可靠性高，数据基本不丢失 | 每个写命令都要落盘，性能影响较大 |
| Everysec(默认) | 每秒写回 | 性能适中 | 宕机时丢失1秒内的数据 |
| No | 操作系统控制 | 性能好 | 宕机时丢失数据较多 |
| 配置指令 | 描述 | 配置示例 |
|---|---|---|
| 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 |
Redis7.0 Multi Part AOF
的设计
顾名思义，MP-AOF就是将原来的单个AOF文件拆分成多个AOF文件(
redis6只有一个文件
)。在MP-AOF中，我们将AOF分为三种类型分别为:
它一般由子进程通过重写产生，该文件最多只有一个
// 如有下的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
其中
// 几种类型文件的前缀,后跟有关序列和类型的附加信息
appendfilename"appendonly.aof
//新版本增加的目录配置项目
appenddirname "appendonlydir"
采用
flushdb + shutdown
模拟redis异常终止，需要注意的是：
flushdb
也是写操作，也会写入aof文件，所以在执行
flushdb
之前备份aof文件，
flushdb
之后可以使用 备份的aof 覆盖掉aof文件
flushdb + shutdown
操作之后，手动删除增量文件中的最后
flushdb
命令
最后，重启reids便可加载aof文件进行数据恢复
故意破环aof增量文件
[root@Docker110 appendonlydir]# vim appendonly.aof.1.incr.aof
*2
$6
......
$1
0
jasitfgjwaior943q294r534jiosa(*(u
重启启动之后查看
居然启动失败，赶紧查看一下日志，日志文件
日志文件路径的配置
建议让我们修复一下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文件名称以及大小的变化
可以清晰的看到重写之后的变化：
更好的保护数据不丢失 、性能高、可做紧急恢复相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdbaof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
我们首先看看官网对混合模式的介绍：
一般来说，如果你想要一个与PostgreSQL相媲美的数据安全程度，你应该使用这两种持久化方法。RDB镜像做全量持久化，AOF做增量持久化
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据
设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用
先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样的话，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。
简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式(AOF包括了RDB头部+AOF混写)
在同时开启rdb 和aof 持久化时，重启时只会加载 aof 文件，不会加载 rdb 文件，rdb做为一个万一的策略
同时关闭RDB+AOF
save ""
)
save、bgsave
生成rdb文件
appendonly no
)
bgrewriteaof
生成aof文件
尚硅谷Redis零基础到进阶，最强redis7教程，阳哥亲自带练