redis持久化

Redis 数据持久化

1. RDB（Redis Database）

1.1 基本原理

• 将某个时间点的所有数据快照（snapshot）写入磁盘
• 默认生成dump.rdb文件
• 适合备份和灾难恢复

1.2 触发方式

1. 手动触发

   • SAVE命令：同步保存，阻塞服务器
   • BGSAVE命令：异步保存，fork子进程执行

2. 自动触发

   • redis.conf中配置save规则
   • 如：save 900 1（900秒内有1个修改）
   • 主从复制时，从节点接收完整数据集

1.3 优缺点

优点：

• 文件紧凑，适合备份
• 恢复速度快
• fork子进程，影响主进程小

缺点：

• 可能丢失最后一次快照后的数据
• fork过程耗时，数据量大时影响性能
• 不适合实时持久化

2. AOF（Append Only File）

2.1 基本原理

• 记录服务器执行的所有写命令
• 默认生成appendonly.aof文件
• 类似MySQL的binlog

2.2 同步策略

1. always：每个写命令同步写入硬盘
2. everysec：每秒同步一次（默认）
3. no：由操作系统决定何时同步

2.3 重写机制

• 自动触发：配置auto-aof-rewrite-percentage和min-size
• 手动触发：BGREWRITEAOF命令
• 目的：减小文件体积，提高加载效率

2.4 优缺点

优点：

• 数据安全性高
• 支持秒级持久化
• 文件易读，可修复

缺点：

• 文件体积较大
• 恢复速度慢
• 性能略低于RDB

3. 混合持久化（Redis 4.0+）

3.1 基本原理

• AOF重写时，同时将RDB数据写入AOF文件
• 结合RDB和AOF的优点
• 默认开启

3.2 文件结构

• 前半部分是RDB格式的全量数据
• 后半部分是AOF格式的增量数据

3.3 优缺点

优点：

• 重启恢复快
• 数据安全性好
• 文件体积适中

缺点：

• 兼容性稍差
• 占用更多内存

4. 最佳实践

4.1 持久化策略选择

场景	推荐方案
纯缓存	不开启持久化
可靠性要求高	AOF（everysec）
大规模数据	混合持久化
备份恢复	RDB

4.2 配置建议

# RDB配置
################################ SNAPSHOTTING  ################################
#900s内，如果至少有一个1key进行了修改，就进行持久化操作
save 900 1
#300s内，如果至少有一个10key进行了修改，就进行持久化操作
save 300 10
#60s内，如果至少有一个10000key进行了修改，就进行持久化操作
save 60 10000
#持久化如果出错，是否还需要继续工作
stop-writes-on-bgsave-error yes
#是否压缩rdb文件，需要消耗一些cpu资源
rdbcompression yes
#保存rdb文件的时候,进行错误的检查校验
rdbchecksum yes
#持久化的文件名字
dbfilename dump.rdb
#rdb文件保存的目录
dir ./
# 数据恢复
127.0.0.1:6379> config get dir #获取redis的目录
1) "dir"
2) "/usr/local/bin" # 将dump.rdb文件放在这个目录下，重新启动redis，就可以自动将数据恢复

# AOF配置
############################## APPEND ONLY MODE ###############################
# 默认不开启aop持久化机制，因为RDB对于一般的业务已经够用了
appendonly no

# aof持久化文件名称
appendfilename "appendonly.aof"

# 不执行sync, 完全依赖操作系统的刷写，一般30秒一次。性能最好，但是持久化没有保障，不推荐
# appendfsync no
# 每次有写命令执行，就会执行一次sync，将命令追加到aof日志文件。保证完全持久化，不会丢数据，性能也是最差的，不推荐
# appendfsync always
# 每秒钟执行一次sync，将命令追加到aof日志文件。在性能和持久化之间做了折中，推荐。也是默认配置
appendfsync everysec

# 默认不会对aof文件使用BGREWRITEAOF命令进行重写（重写会合并命令，减小aof文件占用的空间）
no-appendfsync-on-rewrite no
# 当aof文件占用的空间超过上一次记录的100%时，并且aof文件每增加64M，就会执行重写（两个条件同时满足）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof文件时，如果文件本身有问题（如文件结尾），是否继续加载。yes:继续加载，no:加载出现错误，停止加载，需要修复aof文件后才能加载，这是不能重启redis
aof-load-truncated yes

# 混合持久化
############################## mix MODE ###############################
aof-use-rdb-preamble yes

4.3 运维建议

• 定期备份持久化文件
• 监控磁盘空间
• 合理配置重写参数
• 避免持久化与主业务同时高峰

5. 不使用 Redis 持久化的潜在问题

5.1 数据恢复时间

如果 Redis 数据量较大，从数据库中重新加载数据可能会耗费较长时间，导致 Redis 在这段时间内不可用。

在高并发场景下，这种延迟可能会影响用户体验或导致系统性能下降。

5.2 数据一致性

如果 Redis 中存储的是经过复杂计算或实时更新的数据（如计数器、排行榜等），直接从数据库恢复可能会导致数据不一致。

某些业务场景可能需要 Redis 的持久化机制来保证数据的一致性和完整性。

5.3 数据丢失风险

如果 Redis 实例意外崩溃且没有持久化机制，所有内存中的数据都会丢失。对于某些关键业务场景（如会话管理、分布式锁等），这可能会带来严重的后果。

5.4 数据库压力

如果频繁地从数据库中加载数据到 Redis，可能会增加数据库的压力，尤其是在 Redis 数据量较大或数据库性能较低的情况下。

6. 数据恢复

redis 启动时，首先判断 aof 功能是否开启，如果开启并且存在 aof 持久化文件，则只会使用 aof 文件进行数据恢复，而不会使用 rdb 文件进行数据恢复。

使用 aof 文件恢复时，AOF 文件可能存在结尾不完整的情况，比如机器突然断电导致 AOF 尾部文件命令写入不全。Redis 为我们提供了 aof-load-truncated 配置(默认开启)来兼容这种情况。加载 AOF 时，当遇到此问题时会忽略并继续启动。