Redis-数据持久化

Redis作为内存数据库，其持久化机制是保证数据安全性的关键。Redis提供了两种主要的持久化方式：RDB（Redis Database）和AOF（Append Only File），以及两者的混合模式。下面我将从原理、配置、优缺点和实际应用等方面进行全面解析。

RDB持久化机制

RDB基本原理

RDB是通过创建内存数据的快照来实现持久化的。它会将某一时刻Redis中的所有数据以二进制形式保存到磁盘上的dump.rdb文件中。当Redis重启时，可以通过加载这个文件来恢复数据。

RDB触发方式

RDB持久化有三种触发方式：

1. 手动触发：

   • save命令：会阻塞Redis服务器直到RDB文件创建完成，不推荐在生产环境使用。
   • bgsave命令：Redis会fork一个子进程来完成持久化，主进程继续处理请求，这是推荐的方式。

2. 自动触发： 在redis.conf中配置如：

   save 900 1      # 900秒内有1次修改就触发
   save 300 10     # 300秒内有10次修改就触发
   save 60 10000   # 60秒内有10000次修改就触发

3. 特殊场景触发：

   • 主从复制时主节点自动触发
   • 执行shutdown且未开启AOF时
   • 执行flushall/flushdb命令(但生成的是空文件)

RDB核心原理

当执行bgsave时：

1. Redis主进程fork一个子进程
2. 子进程将内存数据写入临时RDB文件
3. 写入完成后替换旧的RDB文件
4. 使用**写时复制(COW)**技术保证数据一致性 - 主进程修改数据时会创建副本，子进程继续写入原始数据

RDB配置参数

dbfilename dump.rdb       # RDB文件名
dir /var/lib/redis        # 保存路径
rdbcompression yes        # 启用压缩
rdbchecksum yes           # 启用校验
stop-writes-on-bgsave-error yes  # 持久化出错时停止写入

AOF持久化机制

AOF基本原理

AOF通过记录所有写操作命令来持久化数据，以文本形式追加到appendonly.aof文件中。Redis重启时重新执行这些命令来恢复数据。

AOF工作流程

1. 命令执行后追加到aof_buf缓冲区
2. 根据配置的刷盘策略同步到磁盘
3. 定期执行AOF重写压缩文件

AOF刷盘策略

appendfsync always    # 每个命令都同步，最安全但性能差
appendfsync everysec  # 每秒同步一次(默认)
appendfsync no        # 由操作系统决定，性能最好但可能丢失数据

AOF重写机制

为了解决AOF文件膨胀问题，Redis提供了重写功能：

• 自动触发：当AOF文件大小超过阈值(auto-aof-rewrite-percentage和auto-aof-rewrite-min-size)
• 手动触发：执行bgrewriteaof命令

重写原理：

1. 创建子进程遍历内存数据
2. 生成新的AOF文件只包含恢复数据的最小命令集
3. 重写期间的新命令写入缓冲区，最后追加到新文件

Redis 7.0 AOF改进

Redis 7.0将AOF文件分为三部分：

• 基本文件(base)：RDB格式的全量数据
• 增量文件(incr)：AOF格式的增量命令
• 清单文件(manifest)：管理文件顺序

混合持久化

Redis 4.0引入了混合持久化，结合了RDB和AOF的优点：

1. 使用RDB做全量快照
2. 两次快照之间使用AOF记录增量操作
3. 重启时先加载RDB再重放AOF

配置方式：

aof-use-rdb-preamble yes  # 开启混合持久化

RDB与AOF对比

特性	RDB	AOF
持久化方式	快照	日志
文件大小	较小	较大
恢复速度	快	慢
数据安全性	可能丢失最后一次快照后的数据	根据策略可做到几乎不丢数据
性能影响	fork子进程时有短暂阻塞	取决于刷盘策略
适用场景	可容忍分钟级数据丢失，需要快速恢复	数据安全性要求高，可接受较慢恢复