Redis7持久化
1.Redis持久化的两种实现方式
redis提供两种持久化实现方式，分别是RDB（默认使用）和AOF
RDB,在不同的时间点，将存储的数据生成快照并存储到磁盘等介质中。
AOF，将redis所有的写指令记录下来，在下次重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
如果你没有数据持久化的需求，也完全可以关闭 RDB 和 AOF 方式，这样的话，redis 将变成一个纯内存数据库，就像 memcache 一样。
2.RDB
RDB持久性以指定的时间间隔执行数据集的时间点快照。是将 redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。
形成的快照文件（dump.rdb），恢复时再将硬盘快照文件直接都会内存。
一锅端，保存备份的时候它执行的是全量快照，将内存的所有数据都记录到磁盘。
注意：一定要备份文件和redis服务器分机隔离。
2.1RDB案例演示
2.1.1配置文件（6v7）
修改了触发时间频率。
2.1.2操作步骤
进入redis可以执行lastSave获取最后一次成功执行快照的时间。
1.自动触发
配置redis.conf
设置触发频率
save <seconds> <changes>
设置快照文件保存地址
dir /myredis/dumpfiles
（自己设置的可以进入reids看到）（CONFIG GET dir）
2.手动触发
redis提供两个命令手动触发，进行备份快照。
save
在主程序执行会阻塞当前redis服务器，不会创建子进程，直到持久化工作完成，执行save期间，redis不能处理其他命令，线上禁止使用
- 当 Redis 服务器正常关闭时，会自动执行一次
SAVE操作，以此确保数据不会丢失。
bgsave（默认）
redis会在后台异步进行快照操作，不阻塞。
快照的同时可以响应客户端请求，该触发模式会fork一个子进程由子进程复制持久化过程。
什么是fork？
1.常见的备份，复制
2.从操作系统的角度，fork（）会产生一个和父进程完全相同的子进程，但子进程在此后多会执行系统调用，出于效率考虑，尽量避免膨胀。
2.2RDB优势
适合大规模的数据恢复，能够按照业务定时备份，RDB文件在内存中加载速度要比AOF快得多。
2.3RDB缺点
1.如果你对数据的完整性非常敏感，那么 RDB 方式就不太适合你，因为即使你每 5 分钟都持久化一次，当 redis 故障时，仍然会有近 5 分钟的数据丢失。
2.如果数据集很大，fork（）可能会很耗时，如果CPU性能不是很好，可能会导致Redis停止位客户端服务几毫秒。
2.4RDB修复命令
redis-check- rdb
2.5触发事件
1.自动触发，2.手动触发3.执行flushdb/flushall也会产生4.执行shutdown且没有设置开启AOF持久化5.主从复制时，主节点自动触发。
2.6快照禁用
1.动态所有停止RDB保存规则的方法：（一次）
redis-cli config set save""
2.配置文件修改（永久）
2.7RDB优化配置
3.AOF
以日志的形式来记录每个写操作，AOF，英文是 Append Only File，即只允许追加不允许改写的文件。
我们通过配置 redis.conf 中的 appendonly yes 就可以打开 AOF 功能。如果有写操作（如 SET flushdb等），redis 就会被追加到 AOF 文件的末尾。
3.1AOF工作流程
3.2AOF三种写回策略
Always（同步写回），exerysec（默认每一秒写回），no
默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync 是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis 仍然可以保持很好的处理性能，即使 redis 故障，也只会丢失最近 1 秒钟的数据。
no ：操作系统的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
3.3案例演示
3.3.1配置文件（6v7）
redis6：配置文件生成dir设置路径。
文件保存名称
redis6，有且只有一个
redis7：
3.4数据恢复
如果在追加日志时，恰好遇到磁盘空间满、inode 满或断电等情况导致日志写入不完整，将不能够启动，也没有关系，redis 提供了 redis-check-aof 工具，可以用来进行日志修复。
3.5AOF优势与缺点
优势：
更好的保护数据不丢失，性能高，可做紧急恢复
缺点
相同的数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb，不同步效率和rdb相同。
3.6AOF重写机制
因为采用了追加方式，如果不做任何处理的话，AOF 文件会变得越来越大，为此，redis 提供了 AOF 文件重写（rewrite）机制，即当 AOF 文件的大小超过所设定的阈值时，
默认配置是当AOF文件大小是上次重写后大小的一倍，且文件大于64M时触发。
redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了 100 次 INCR 指令，在 AOF 文件中就要存储 100 条指令，但这明显是很低效的，完全可以把这 100 条指令合并成一条 SET 指令，这就是重写机制的原理。
可以手动使用命令bgrewriteaof来重写。
原理：
在重写即将开始之际，redis 会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的 AOF 文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的 AOF 文件中，这样做是保证原有的 AOF 文件的可用性，避免在重写过程中出现意外。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新 AOF 文件中。
当追加结束后，redis 就会用新 AOF 文件来代替旧 AOF 文件，之后再有新的写指令，就都会追加到新的 AOF 文件中了。
3.7AOF优化配置
4.RDB和AOF混合持久化
同时开启，AOF为话事人
4.1数据恢复顺序和加载流程
重启时只加载aof文件，不会加载rdb文件。（不存在aof文件就加载rdb）
开启混合方式设置
aof-use-rdb-preamble 设置为yes开启。
RDB做全量持久化，AOF做增量持久化
5.纯缓存模式
同时关闭RDB和AOF
禁用情况下，我们仍然可以手动使用命令生成文件。save，bgsave，bgrewriteaof。