Redis持久化存储
1、简介
Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。
Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。
2、RDB（定期快照式存储）
RDB方式的持久化是通过**快照**（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。
RDB是Redis默认采用的持久化方式（主从复制的时候默认使用的为RDB）。
生成的文件通常是：
dump.rdb工作原理
内存数据 → fork子进程 → 子进程写入RDB文件 → 替换旧文件
触发方式
自动触发
#1.自动触发（配置文件中设置） save9001#900秒内至少有1个key改变 save30010#300秒内至少有10个key改变 save6010000#60秒内至少有10000个key改变含义：
- 900 秒内有 1 次写 → 生成快照
- 300 秒内有 10 次写
- 60 秒内有 10000 次写
在redis.conf中：
- 配置dir指定rdb快照文件的位置
- 配置dbfilenam指定rdb快照文件的名称
手动触发
#2.手动触发 redis-cli>SAVE # 同步保存，阻塞其他操作 redis-cli>BGSAVE # 后台异步保存（推荐）RDB 优缺点
优点
- ✅ 文件紧凑，适合备份和灾难恢复
- ✅ 恢复大数据集时速度比AOF快
- ✅ 最大化Redis性能（父进程无需磁盘IO）
- ✅ 支持子进程写时复制（Copy-On-Write）（不阻塞线程主从复制的时候会遗漏一部分，最后通过offset补齐）
缺点
- ❌ 可能丢失最后一次快照后的数据
- ❌ fork子进程时，内存占用翻倍
- ❌ 大数据集时fork可能耗时较长
3、AOF（追加日志是存储）
工作原理
默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：
appendonly yes开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：appendfilename appendonly.aof。
AOF的工作流程：
- **命令追加（append）：**所有的写命令会追加到 AOF 缓冲区中。
- **文件写入（write）：**将 AOF 缓冲区的数据写入到 AOF 文件中。注意！！！此时并没有同步到磁盘。
- **文件同步（fsync）：**fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
- **文件重写（rewrite）：**随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
- **重启加载（load）：**当 Redis 重启时，可以加载 AOF 文件进行数据恢复
AOF 重写机制
# 解决AOF文件过大的问题 # 通过重写创建当前数据集的最小命令集合 # 触发重写： auto-aof-rewrite-percentage100# 文件增长100%时重写 auto-aof-rewrite-min-size64mb # 最小64MB才重写 # 手动重写： redis-cli>BGREWRITEAOFAOF 同步策略
# redis.conf 配置 appendonly yes # 开启AOF appendfilename"appendonly.aof"# AOF文件名 # 同步策略（重要！） appendfsync always # 每个写命令都同步，最安全但性能差 appendfsync everysec # 每秒同步一次（推荐，平衡安全与性能） appendfsync no # 由操作系统决定，最快但可能丢失数据| 策略 | 数据安全 | 性能 |
|---|---|---|
| always | 最安全 | 最慢 |
| everysec | 较安全 | 推荐 |
| no | 风险高 | 最快 |
AOF 配置详解
# redis.conf 完整AOF配置 appendonly yes appendfilename"appendonly.aof"appendfsync everysec # AOF重写配置 no-appendfsync-on-rewrite no # 重写时是否停止fsync auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb # 加载时处理损坏的AOF aof-load-truncated yes # 加载截断的AOF文件 aof-use-rdb-preamble yes # 混合持久化（Redis4.0+）AOF 优缺点
优点
- ✅ 数据安全性更高（最多丢失1秒数据）
- ✅ 可读的日志文件，便于分析
- ✅ 仅追加写入，无磁盘寻址开销
- ✅ 支持后台重写，不影响客户端
缺点
- ❌ 文件体积通常比RDB大
- ❌ 恢复速度比RDB慢
- ❌ 性能略低于RDB（取决于fsync策略）
- ❌ 可能遇到AOF重写bug
4、混合使用（RDB+AOF）
Redis支持两者同时开启：
工作原理
BGREWRITEAOF → 先写RDB快照到AOF文件 → 追加期间的AOF命令
不同场景推荐
#1.数据安全最重要 appendonly yes appendfsync always # 或 appendfsync everysec+频繁的RDB备份 #2.性能最重要 appendonly no save9001# 较少的RDB备份 #3.内存有限，需要快速重启 appendonly no dbfilename dump.rdb rdbcompression yes #4.推荐的生产配置（平衡型） appendonly yes appendfsync everysec auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb save9001save30010save6010000- 优先使用AOF 恢复数据
- RDB 作为备份手段
👉这是生产环境的推荐方案。
#4.推荐的生产配置（平衡型） appendonly yes appendfsync everysec auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb save9001save30010save6010000