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持久化
- 核心原理
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时有内存压力 | 持续写入开销 |
适用场景 | 可以容忍数分钟的数据丢失、快速重启 | 数据安全要求高 |