Redis持久化：RDB与AOF

（1）执行bgsave，父进程判断当前是否存在其他子进程，如果存在bgsave命令直接返回

（2）父进程执行fork创建子进程，fork过程中父进程会阻塞

（3）父进程fork完成之后，bgsave不在阻塞父进程，继续响应其他命令

（4）子进程创建RDB文件，使用原子操作替换旧RDB文件

（5）进程发送消息给父进程表示完成

1.4、RDB文件处理

文件位置和命名

java 复制代码

# 配置文件示例
dir /var/lib/redis/      # 保存目录
dbfilename dump.rdb      # 文件名

# 运行时动态修改
CONFIG SET dir /new/path
CONFIG SET dbfilename newdump.rdb

压缩：默认使用LZF算法压缩(默认开启)，

java 复制代码

#可以动态修改
config set rdbcompression {yes|no}

虽然压缩RDB会消耗CPU，但可以大幅降低文件体积，方便保存在硬盘或者通过网络发送到从节点。

校验：Redis启动时加载到损坏文件会拒绝启动，可以通过redis-check-dump工具检测RDB文件并获取对应错误报告

1.5、RDB优缺点

优点：

RDB是紧凑的二进制文件，适合备份和传输；

恢复数据块

适合灾难恢复场景

缺点：

无法做到实时/秒级持久化(bgsave每次运行都要执行fork创建子进程)

版本兼容问题

二、AOF(Append Only File)持久化

2.1、工作原理：

AOF通过记录所写操作命令来持久化数据，重启时重新执行这些命令恢复数据

2.2 、开启AOF配置：

复制代码

# redis.conf配置
appendonly yes                    # 开启AOF
appendfilename "appendonly.aof"   # AOF文件名
appendfsync everysec              # 同步策略
dir /var/lib/redis/               # 保存目录

2.3、工作流程如下：

命令写入：所有写命令追加到aof_buf缓冲区(内容直接是文本协议格式，实现简答具备可读性)

文件同步：根据策略将缓冲区内容同步到硬盘

文件重写：定期压缩AOF文件

重启加载：启动时重新执行AOF文件中的命令

2.4、缓冲区文件同步策略对比

|----------|------------|---------|------------|
| 策略 | 说明 | 优点 | 缺点 |
| always | 每次写入后立即同步 | 数据最安全 | 性能差（几百TPS） |
| everysec | 每秒同步一次（默认） | 兼顾性能和安全 | 可能丢失1秒数据 |
| no | 由操作系统决定 | 性能最好 | 数据安全性低 |

总的来说，频率越高，数据可靠性最高，性能最差

2.5、重写机制

1、重写的原因：

删除无效命令(如已经过期的数据)；合并多条命令为一条；减小文件体积、提高恢复速度

2、触发条件：

手动触发：调用bgrewriteaof命令

自动触发：

复制代码

# 配置文件参数
auto-aof-rewrite-percentage 100   # 当前AOF文件比上次重写后大小增长100%时触发
auto-aof-rewrite-min-size 64mb    # AOF文件最小达到64MB

3、重写流程：

父进程执行fork创建子进程(父进程任然负责接受请求，子进程负责针对AOF文件进行重写，在创建子进程的一瞬间，子进程继承父进程的内存状态)

子进程基于当前内存数据生成新AOF文件(重写的时候不关心AOF文件中原来有什么，只关心内存中最终数据状态)，同时父进程不停接受新的请求，将新请求产生的数据先写入缓冲区在刷新到原有AOF文件中

父进程将重写期间的写命令存入重写缓冲区，子进程完成后，父进程追加缓冲区内容到新文件

原子替换旧AOF文件

2.6、数据恢复

当Redis启动时，会根据RDB和AOF文件的内容，进行数据恢复

三、RDB与AOF对比

特性	RDB	AOF
数据安全	可能丢失较多数据	最多丢失1秒数据
恢复速度	快	慢（需要重放命令）
文件大小	小（压缩）	大（可重写压缩）
对性能影响	fork时可能阻塞	写AOF文件影响IO
适用场景	灾难恢复、全量备份	实时持久化、主从复制

混合持久化：Redis4.0引入混合持久化，结合RDB和AOF优点：

复制代码

# AOF文件结构
[ RDB二进制数据 ] + [ AOF增量命令 ]