Redis 持久化
Redis 的持久化有两个策略
- RDB -> Redis DataBase
- AOF -> Append Only File
RDB
RDB 的触发时机有两种，一种是手动存储，一种是定时存储。将数据备份到数据库中，通常存在一个后缀名为 .rdb的文件
定时存储通过配置文件修改
主要讲手动存储，它有两个命令，save 和 bgsave
-
save：执行
save操作，Redis 会全力以赴的进行((20260421182031-owe9evp "快照"))生成的工作，此时就会阻塞 Redis 客户端的其他命令，达到类似keys *的效果 -
bgsave：bgsave 就是background save，在后台生成一个**++新的进程++**，来进行并发的编程。新的进程会 fork 一份父进程的完整数据（包括 pcb，内存中的虚拟地址，文件描述符表等...），将完整数据存入到 .rdb 文件中，当bgsave执行过程中，若有其他的数据插入，则可能会有迟滞性，因为新的数据不同步到子进程。
注意：由于子进程有着跟父类一样的文件描述符表，故子进程也可以对文件进行读写操作。
执行逻辑为：判定是否存在其他的子进程，若存在则将当前的bgsave返回，否则新建一个子进程。
此处的 fork 拷贝操作是"写时拷贝"的机制实现的------即如果父进程与子进程里的数据是一模一样的，父进程与子进程会共用同一份内存空间，当对内存数据做出修改后，才会触发真正的物理内存的拷贝。新的数据会插入到父进程中，子进程数据保持原有的数据不更新。
RDB 这个二进制文件默认通过二进制的方式将内存中的数据以压缩的形式保存
后续 Redis 重启，会重新加载这个 RDB 文件，若 RDB 损坏则可能启动失败。针对 RDB 损坏的问题，自带了一个 RDB 的检查工具
redis-check-rdb*RDB 的持久化操作是可以重复执行的，此时会生成一个 RDB 镜像文件，将快照数据先保存至一个临时的文件中，当快照生成完毕后，将旧的 RDB 文件删除，将临时的文件夹改名为
dump.rdb（默认文件名）
RDB 的优缺点：
- RDB 是紧凑压缩过的二进制文件，代表了 Redis 中某个时间点上的数据快照，非常适用于备份
- Redis 加载 RDB 恢复数据远远快于 AOP
- RDB 的这种方式存储就决定了它的数据备份无法达到数据的实时持久化，因为每次的 bgsave 操作都要 fork 一个子进程出来，这是一个重量级的操作
- RDB 使用的是特定的二进制格式保存，且随着时间迁移，Redis 会有多个 RDB 版本，可能会有兼容性问题
AOF
AOF 以日志形式记录 Redis 的写操作命令，重启时重新执行这些命令恢复数据，默认是后缀为 .aof的文件。
写入策略通过配置文件设置，有三种模式：
always：每次写命令都立即刷盘，数据最安全，但性能开销最大everysec：每秒刷盘一次（默认），最多丢失 1 秒数据，兼顾性能与安全no：由操作系统决定刷盘时机，性能最高，但数据安全性最低
AOF 重写
随着写操作增多，AOF 文件会持续膨胀。Redis 提供重写机制压缩文件体积，命令为 bgrewriteaof
- 类似
bgsave，fork 出一个子进程，基于当前内存数据生成最新且最精简的命令集 - 重写期间的新写入命令会同时写入旧的 AOF 文件和 AOF 重写缓冲区
- 子进程完成重写后，将缓冲区的增量命令追加到新文件，最后用新文件替换旧文件
- 同样利用"写时拷贝"机制，避免全量内存复制
AOF 文件以文本协议 存储，具备可读性，但体积通常比 RDB 大。若文件损坏，可使用自带的 redis-check-aof 工具修复。
Redis 重启时若同时存在 AOF 和 RDB，默认优先加载 AOF。
AOF 的优缺点：
- 数据安全性更高，通过合理的
appendfsync策略可实现近实时持久化 - 文件为文本格式，易读且兼容性好，没有 RDB 的版本兼容问题
- 文件体积通常大于 RDB，恢复速度比 RDB 慢（需逐条重放命令）
- 在高并发写入场景下，
always策略会显著影响性能；everysec模式下若发生故障仍可能丢失 1 秒数据