【Redis持久化】

Redis作为内存数据库，其持久化机制是保证数据安全性的关键。Redis提供了两种主要的持久化方式： RDB（Redis Database）和 AOF（Append Only File）

RDB持久化

RDB是通过创建数据快照（snapshot）来实现持久化的二进制文件存储方式。

​​工作流程​​：

• Redis fork一个子进程
• 子进程将内存中的数据写入临时RDB文件
• 写入完成后替换旧的RDB文件

触发方式

自动触发

# redis.conf配置示例
save 900 1      # 900秒(15分钟)内至少有1个key被更改
save 300 10     # 300秒(5分钟)内至少有10个key被更改
save 60 10000   # 60秒内至少有10000个key被更改

手动触发

• SAVE命令：阻塞主进程直到RDB文件创建完成
• BGSAVE命令：后台异步执行快照生成
• Redis持久化机制深度解析
  Redis作为内存数据库，其持久化机制是保证数据安全性的关键。Redis提供了两种主要的持久化方式：RDB（Redis Database）和AOF（Append Only File），以及它们的混合模式。下面我将全面解析这些持久化机制的工作原理、配置方法和适用场景。

一、RDB持久化

1. 核心原理
   RDB是通过创建数据快照（snapshot）来实现持久化的二进制文件存储方式。

​​工作流程​​：

Redis fork一个子进程
子进程将内存中的数据写入临时RDB文件
写入完成后替换旧的RDB文件
2. 触发方式
自动触发

redis.conf配置示例

save 900 1 # 900秒(15分钟)内至少有1个key被更改
save 300 10 # 300秒(5分钟)内至少有10个key被更改
save 60 10000 # 60秒内至少有10000个key被更改
手动触发
SAVE命令：阻塞主进程直到RDB文件创建完成
BGSAVE命令：后台异步执行快照生成

​​优点​​：

文件紧凑，适合备份和灾难恢复
恢复大数据集时速度比AOF快
最大化Redis性能(fork子进程处理)

​​缺点​​：

可能丢失最后一次快照后的数据
大数据集时fork操作可能耗时较长(毫秒级)

AOF持久化

AOF记录所有写操作命令，以Redis协议格式追加到文件末尾。

工作流程

客户端命令 → 追加到AOF缓冲区 → 同步到AOF文件 → 定期重写压缩

配置选项

# 开启AOF
appendonly yes

# 同步策略
appendfsync always    # 每个命令都同步，最安全但性能差
appendfsync everysec  # 每秒同步(默认推荐)
appendfsync no        # 由操作系统决定

# 自动重写触发条件
auto-aof-rewrite-percentage 100  # 当前AOF文件大小超过上次重写大小的100%
auto-aof-rewrite-min-size 64mb   # AOF文件最小重写大小

AOF重写机制

• fork子进程扫描当前数据集
• 生成新的AOF文件写入临时文件
• 期间的新命令同时写入缓冲区和重写缓冲区
• 完成后追加重写缓冲区的命令
• 原子替换旧AOF文件

​​优点​​：

数据安全性更高(最多丢失1秒数据)
可读性强，易于理解和修复
后台重写不影响主进程

​​缺点​​：

文件体积通常比RDB大
恢复速度较慢
在高负载下可能影响性能

Redis持久化机制：AOF与RDB特性对比

维度	RDB	AOF
持久化方式	快照	命令日志
数据安全性	可能丢失最后一次快照后的数据（分钟级）	最多丢失1秒数据（everysec模式）
文件体积	小（二进制压缩）	大（文本命令）
恢复速度	快（直接加载二进制）	慢（需重放命令）
性能影响	Fork时有内存压力	持续写入开销
适用场景	可以容忍数分钟的数据丢失、快速重启	数据安全要求高