redis 进阶 - Redis 持久化

Redis 持久化

概述

Redis 是内存数据库，数据存储在内存中，但内存中的数据在服务器重启后会丢失。持久化就是将内存中的数据保存到磁盘，实现数据永久保存。

为什么需要持久化？

• 数据备份和恢复

• 防止服务器宕机数据丢失

• 支持数据归档和分析

• 灾备和容灾

Redis 持久化方式

RDB（Redis Database）

快照式持久化，在指定时间间隔内将内存数据快照写入磁盘。

工作原理

时间点快照，二进制压缩格式
主进程 → fork子进程 → 子进程写入RDB文件 → 替换旧文件

配置

# Redis配置文件中的RDB配置
save 900 1      # 900秒内至少有1个key被修改
save 300 10     # 300秒内至少有10个key被修改
save 60 10000   # 60秒内至少有10000个key被修改

dbfilename dump.rdb    # RDB文件名
dir ./                 # 保存路径
stop-writes-on-bgsave-error yes  # 备份出错时停止写入
rdbcompression yes     # 压缩RDB文件
rdbchecksum yes        # 校验RDB文件

RDB触发时机：

 配置文件中的save规则满足时
 执行SAVE命令（阻塞，生产环境慎用）
 执行BGSAVE命令（后台异步）
 主从复制时，主节点会自动触发
 执行SHUTDOWN命令时
 执行DEBUG RELOAD时

RDB优缺点：

# 优点
 二进制压缩格式，文件小，恢复速度快
 适合备份和灾难恢复
 最大程度减少持久化对性能的影响（fork子进程处理）

# 缺点
 数据安全性较低，可能丢失最后一次保存后的数据
 fork子进程时，如果数据集很大，可能导致服务短暂停顿（毫秒到秒级）

AOF（Append Only File）

日志式持久化，记录每个写操作命令。

工作原理

记录每个写操作命令 → 追加到AOF文件 → 重启时重放命令重建数据

配置

# Redis配置文件中的AOF配置
appendonly yes                  # 开启AOF
appendfilename "appendonly.aof" # AOF文件名

# 同步策略
appendfsync everysec
# 可选值：
# always: 每个写命令都同步，最安全，性能最差
# everysec: 每秒同步一次，折中方案（默认）
# no: 由操作系统决定，最快，最不安全

auto-aof-rewrite-percentage 100  # 当前AOF文件比上次重写后大一倍时重写
auto-aof-rewrite-min-size 64mb   # AOF文件最小重写大小

aof-load-truncated yes          # AOF文件损坏时是否继续加载
aof-use-rdb-preamble yes        # 混合持久化（Redis 4.0+）

AOF重写机制：

# 手动触发AOF重写（后台执行）
redis-cli BGREWRITEAOF

# 查看AOF文件信息
redis-cli info persistence

AOF优缺点：

# 优点：
数据安全性高，最多丢失1秒数据（appendfsync everysec）
AOF文件易于理解和解析
重写机制可以压缩AOF文件大小

# 缺点：
文件通常比RDB大
恢复速度比RDB慢
对性能有一定影响（尤其是always模式）

混合持久化（RDB + AOF，Redis 4.0+）

配置

# 开启混合持久化
aof-use-rdb-preamble yes
# 当同时开启RDB和AOF时，Redis重启会优先加载AOF文件

工作原理

AOF文件 = RDB格式的全量数据 + AOF格式的增量命令
恢复时：先加载RDB部分，再执行AOF命令

混合持久化优点

 1. 快速加载 使用RDB部分快速恢复
 2. 数据安全 使用AOF部分保证最新数据
 3. 文件较小 比纯AOF文件小

持久化策略选择建议

场景	推荐策略	原因
缓存系统	RDB only 或 无持久化	数据可重建，追求最高性能
会话存储	RDB + AOF (everysec)	平衡性能和数据安全
金融交易	AOF always	数据绝对不能丢失
大数据集	RDB	恢复速度快

持久化策略选择指南

# 决策树：
是否需要持久化？
├── 否 → 关闭所有持久化（纯缓存）
├── 是 → 
    ├── 能接受多少数据丢失？
    │   ├── 几分钟 → RDB（配置合适时间间隔）
    │   ├── 1秒 → AOF（appendfsync everysec）
    │   └── 0秒 → AOF（appendfsync always）
    ├── 恢复速度要求？
    │   ├── 快 → RDB 或 混合持久化
    │   └── 不要求 → AOF
    ├── 磁盘空间？
    │   ├── 紧张 → RDB
    │   └── 充足 → AOF 或 混合
    └── 写入频率？
        ├── 高 → RDB 或 混合
        └── 低 → AOF

监控和告警

# 监控关键指标 查看AOF文件信息
redis-cli info persistence

# 重要指标：
# rdb_last_save_time      # 上次RDB保存时间
# rdb_last_bgsave_status  # 上次bgsave状态
# aof_last_write_status   # 上次AOF写入状态
# aof_current_size        # AOF当前大小
# aof_base_size           # AOF基础大小

备份策略

# 多级备份方案
1. 本地持久化（RDB/AOF）
2. 定时远程备份
3. 跨区域灾备

# 备份脚本示例
#!/bin/bash
# 1. 执行BGSAVE
redis-cli BGSAVE
# 2. 等待完成
sleep 60
# 3. 复制到备份目录
cp /data/redis/dump.rdb /backup/redis/dump_$(date +%Y%m%d).rdb
# 4. 上传到云存储
aws s3 cp /backup/redis/dump_$(date +%Y%m%d).rdb s3://mybucket/

容灾恢复

# 恢复流程
1. 停止Redis服务
2. 备份当前数据文件
3. 复制备份文件到数据目录
4. 启动Redis服务
5. 验证数据完整性

# AOF文件损坏恢复
redis-check-aof --fix appendonly.aof

性能优化

# RDB优化
1. 避免在业务高峰期触发BGSAVE
2. 使用独立磁盘存储RDB文件
3. 适当调整save参数

# AOF优化
1. 使用everysec策略平衡性能和安全
2. 定期监控AOF重写
3. 使用混合持久化减少文件大小

常见问题与解决方案

AOF文件过大

# 解决方案：
1. 手动触发重写
   redis-cli BGREWRITEAOF

2. 调整重写参数
   auto-aof-rewrite-percentage 70
   auto-aof-rewrite-min-size 1gb

3. 使用混合持久化
   aof-use-rdb-preamble yes

Fork耗时过长

只要是RDB持久化的问题

# 解决方案：
1. 降低持久化频率
2. 增加服务器内存
3. 使用物理机或大内存机器
4. 使用AOF-only（避免RDB的fork）

磁盘I/O瓶颈

# 解决方案：
1. 使用SSD硬盘
2. 单独磁盘用于持久化
3. 调整appendfsync策略
4. 使用no-appendfsync-on-rewrite