尚硅谷redis7 41-46 redis持久化之AOF异常恢复演示
AOF每一秒钟写入一次。当内容才写了一小半,没有写完整时，突然,redis挂了,导致aof文件错误。
故意乱写正常的AOF文件,模拟网络闪断文件写error
重启 Redis 之后就会进行AOF文件的载入,发现启动都失败
首先cd /usr/local/bin 异常修复命令:redis-check-aof -- fix 进行修复
不需要三个都修复，修复incr即可。
重新OK
42 redis持久化之AOF优缺点案例总结
AOF优势
1.使用AOF Redis更加持久:您可以有不同的fsync【写回】策略:根本不fsync、每秒fsync、每次查询时fsync。使用每秒fsync的默认策略。写入性能仍然很棒。fsync是使用后台线程执行的,当没有fsync正在进行时,主线程将努力执行写入,因此您只能丢失一秒钟的写入【最差的情况就是丢失1秒】。
2.AOF日志是一个仅附加日志,因此不会出现寻道问题,也不会在断电时出现损坏问题。即使由于某种原因(磁盘已满或其他原因)日志以当一半的命令结尾,redis-check-aof 工具也能够轻松修复它。
仅附加日志：AOF 文件在记录数据变更时是追加写入（append-only）的。每次执行写命令（如
SET,DEL,INCR等），Redis 都会把这个命令的文本形式写入到 AOF 文件的末尾。
不会修改已有的数据内容。
类似于一个不断增长的操作历史记录。
寻道问题：传统关系型数据库（如 MySQL、PostgreSQL）使用的是复杂的数据结构和存储策略，比如：B+树索引结构。写入一条记录可能要更新记录页，索引页等等，这些页通常分散在磁盘的不同位置，因此需要多次寻道来定位并修改。而AOF因为只做追加写入，文件指针总是在文件末尾，不需要频繁地移动文件指针来读写不同位置（这就叫“寻道”）。
为什么不会在断电时出现损坏问题？
由于 AOF 是顺序写，且每条写命令在写入前可以通过
fsync或fdatasync确保刷入磁盘，即使突然断电：
只可能丢失“最后一条命令”，而不是导致整个文件损坏。
不会出现“中间内容被破坏”的问题。
3.当AOF变得太大时,Redis能够在后台自动重写AOF,重写是完全安全的,因为当Redis继续附加到旧文件时,会使用创建当前数据集所需的最少操作集生成一个全新的文件,一旦第二个文件准备就绪,Redis就会切换两者并开始附加到新的那一个。
4.·AOF以易于理解和解析的格式依次包含所有操作的日志。您甚至可以轻松导出AOF文件。例
如,即便您不小心使用该FLUSHALL命令刷新了所有内容,只要在此期间没有执行日志重写,您
仍然可以通过停止服务器、删除最新命令并重新启动Redis来保存您的数据集。
进入aof文件存储的路径
vim appendonly.aof.1.incr.aof
删除最后一条FLUSHALL命令
总结：更好的保护数据不丢失，性能高，可做紧急恢复
AOF缺点
1.AOF文件通常比相同数据集的等效RDB文件大。
2.根据确切的fsync策略,AOF可能比RDB慢。一般来说,将fsync设置为每秒性能仍然非常高,并且在禁用fsync的情况下,即使在高负载下它也应该与RDB一样快。即使在巨大的写入负载的情况下,RDB仍然能够提供关于最大延迟的更多保证。
总结：
相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
43 redis持久化之AOF重写机制案例
由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断的进行,AOF的文件会越来越大。文件越大,占用服务器内存越大以及AOF恢复要求时间越长。
为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的峰值时,Redis就会自动启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重新。
自动触发
auto- aof- rewrite- percentage 100
auto- aof- rewrite-mil size 64mb
满足配置文件中的选项后,Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时才会自动触发
注意,同时满足,且的关系才会触发
1 根据上次重写后的aof大小,判断当前aof大小是不是增长了1倍
2 重写时满足文件大小
为什么需要压缩？
启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。
举个例子:比如有个key
一开始你 set k1 v1
然后改成 set k1 v2
最后改成 set k1 v3
如果不重写,那么这3条语句都在aof文件中,内容占空间不说启动的时候都要执行一遍,共计3条命令;
但是,我们实际效果只需要set k1 v3这一条,所以,开启重写后,只需要保存set k1 v3就可以了只需要保留最后一次修改值,相当于给aof文件瘦身减肥,性能更好。
AOF重写不仅降低了文件的占用空间,同时更小的AOF也可以更快地被Redis加载。
案例实施
前期配置
开启aof
appendonly yes
重写峰值修改为1k
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 1k
关闭redis和aof混合,设置为no
aof-use-rdb-preamble no
删除之前的全部aof和rdb,清除干扰项
PS：如果按照视频操作之后，并没有生成aof文件可以尝试如下操作
1.可以连接redis后 检查一下aof是否开启：config get appendonly
2.如果返回no就是开启失败。也可以不修改redis.conf文件。手动设置开启：redis-cli CONFIG SET appendonly yes 【这并不是永久开启aof。仅限于当前进程】
或者是因为重新启动redis.conf文件时还有redis进程在运行，所以开启失败。
1.查找reids运行的进程 ps aux | grep redis 或者 使用 pidof 查找 Redis 主进程 PID pidof redis-server
2.再kill 返回的PID
3.再redis-server redis.conf 【一般这个时候就会加载成功】
自动触发
完成上述正确配置,重启redis服务器,执行set k1 v1查看aof文件是否正常
查看三大配置文件
几种类型文件的前缀,又追有关序列和类型的附加信息
appendfilename "appendonly.aof"新版本端加的目录配置项目
appenddirname "appendonlydir"如有下的aof文件存在
1. 基本文件
appendonly.aof.1.base.rdb
2. 增量文件
appendonly.aof.1.incr.aof
appendonly.aof.2.incr.aof
3. 清单文件
appendonly.aof.manifestI
k1不停1111111111111111111暴张
重写触发 ：超过1k之后，发现文件压缩变小。
手动触发重写
客户端向服务器发送bgrewriteaof命令
总结
AOF文件重写并不是对原文件进行重新整理,而是直接读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件后去替换原来的AOF文件。
AOF文件重写触发机制:通过redis.conf 配置文件中的auto-aof-rewrite-percentage:默认值为100,以及auto-aof-rewrite-min-size:64mb配置,也就是说默认Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
44 redis持久化之AOF小总结
45 redis持久化之RDB+AOF混合持久化
rdb vs aof
问题
可否共存？AOF 和 RDB 持久化可以同时启用，不会有任何问题。如果在启动时启用了 AOF，Redis 会加载 AOF 文件，因为它提供了更好的数据持久性保障。
数据恢复顺序和加载流程【面试】
在同时开启rdb和aof持久化时，重启时只会加载aof文件不会加载rdb文件
怎么选？用哪个？
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
同时开启两种持久化的方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
作者建议不要,因为RDB更适合用于备份数据库(AOF在不断变化不好备份),留着rdb作为一种以防万一的手段
RDB+AOF混合持久化方式
结合了RDB和AOF的优点，既能快速加载又能避免丢失过多数据
1 开启混合方式设置
设置aof-use-rdb-preamble的值为yes yes表示开启,设置为no表示禁用
2 RDB+AOF的混合方式 --------- >结论:RDB镜像做全量持久化,AOF做增量持久化
先使用RDB进行快照存储,然后使用AOF持久化记录所有的写操作,当重写策略满足或手动触发重写的时候,将最新的数据存储为新的RDB记录。。这样的话,重启服务的时候会从RDB和AOF两部分恢复数据,既保证了数据完整性,又提高了恢复数据的性能。
简单来说:混合持久化方式产生的文件一部分是RDB格式,一部分是AOF格式。 ---- 》AOF包括了RDB头部+AOF混写
46 redis持久化之纯缓存模式only
在 Redis 的持久化配置中，“纯缓存模式”（persistence-only 模式 / cache-only 模式），通常是指 禁用所有持久化机制（RDB 和 AOF），让 Redis 只作为内存缓存来使用。
纯缓存的作用
| 作用 | 说明 |
|---|---|
| 更快的性能 | 无磁盘 I/O，适合对延迟极其敏感的应用。 |
| 节省磁盘资源 | 不产生 dump.rdb / appendonly.aof 等文件。 |
| 容器化部署 | 与容器生命周期一致，重启就清空数据，适合短生命周期或临时环境。 |
| 作为纯粹的缓存使用 | 比如配合数据库使用，仅缓存热点数据，宕机没关系，下次可重新加载。 |
关闭RDB和AOF
修改redis.conf配置文件
关闭rdb: save "" 禁用rdb。禁用rdb持久化模式下，我们仍然可以使用命令save,bgsave生成rdb文件。
关闭aof:appendonly no禁用aof。禁用aof持久化模式下，我们仍然可以使用命令bgrewriteao生成aof文件。