外观
Redis 持久化原理
RDB持久化原理
RDB（Redis Database）是Redis的快照持久化方式，将内存中的数据以二进制格式保存到磁盘文件中。
RDB持久化的触发方式
自动触发
Redis配置文件中通过save指令定义自动触发条件：
txt
# 900秒内至少1个键被修改
save 900 1
# 300秒内至少10个键被修改
save 300 10
# 60秒内至少10000个键被修改
save 60 10000手动触发
通过Redis命令手动触发RDB持久化：
txt
# 同步执行，阻塞Redis服务器
SAVE
# 异步执行，不阻塞Redis服务器
BGSAVERDB持久化的工作流程
BGSAVE命令的执行流程
- 客户端发送BGSAVE命令：客户端向Redis服务器发送BGSAVE命令
- 主进程检查是否有正在执行的RDB/AOF操作：如果有，则直接返回，不执行新的BGSAVE
- 主进程fork()创建子进程：主进程通过fork()系统调用创建一个子进程，子进程继承主进程的内存数据
- 子进程生成RDB文件：子进程遍历内存中的数据，将数据以RDB格式写入临时文件
- 子进程完成RDB文件生成：子进程完成数据写入后，将临时文件重命名为正式的RDB文件
- 子进程通知主进程：子进程通过信号通知主进程RDB文件生成完成
- 主进程更新RDB文件信息：主进程更新统计信息，如lastsave时间
RDB文件格式
RDB文件采用二进制格式存储，包含以下几个部分：
- 魔数：文件开头的标识符，用于识别RDB文件格式
- 版本号：RDB文件格式的版本号
- 数据库选择器：用于切换不同的数据库
- 键值对数据：以特定格式存储的键值对数据
- 过期时间：带有过期时间的键的过期信息
- EOF标记：文件结束标记
- 校验和：用于验证文件完整性
RDB持久化的优缺点
优点
- 文件体积小：RDB文件采用二进制格式，体积比AOF文件小
- 恢复速度快：加载RDB文件的速度比重放AOF日志快
- 适合备份：便于进行定期备份和灾难恢复
- 对性能影响小：BGSAVE命令是异步执行的，主进程几乎不阻塞
缺点
- 数据安全性低：如果Redis服务器在两次RDB持久化之间崩溃，会丢失这段时间内的数据
- fork()开销大：在数据量大时，fork()操作可能会阻塞主进程，影响Redis性能
- 不适合实时备份：无法实现秒级别的数据持久化
AOF持久化原理
AOF（Append Only File）是Redis的日志持久化方式，将所有写命令追加到日志文件中。
AOF持久化的配置
AOF持久化通过以下配置项启用和配置：
txt
# 启用AOF持久化
appendonly yes
# AOF文件名
appendfilename appendonly.aof
# AOF同步策略
appendfsync everysecAOF同步策略
Redis支持三种AOF同步策略：
| 同步策略 | 描述 | 安全性 | 性能 |
|---|---|---|---|
| always | 每次写命令都同步到磁盘 | 最高 | 最低 |
| everysec | 每秒同步一次到磁盘 | 中等 | 中等 |
| no | 由操作系统决定何时同步 | 最低 | 最高 |
AOF持久化的工作流程
- 客户端发送写命令：客户端向Redis服务器发送写命令
- 命令追加到AOF缓冲区：Redis将写命令追加到AOF缓冲区
- 根据同步策略同步到磁盘：根据配置的同步策略，将AOF缓冲区的内容同步到磁盘
- AOF文件重写：定期对AOF文件进行重写，减少文件大小
AOF文件重写
AOF文件重写的原因
- AOF文件会随着时间增长而变得越来越大
- 包含大量冗余命令，如多次修改同一个键
- 影响Redis的恢复速度
- 占用过多磁盘空间
AOF文件重写的触发方式
自动触发
通过配置项自动触发AOF重写：
txt
# AOF文件大小增长到原来的100%时触发重写
auto-aof-rewrite-percentage 100
# AOF文件大小达到64MB时触发重写
auto-aof-rewrite-min-size 64mb手动触发
通过Redis命令手动触发AOF重写：
txt
BGREWRITEAOFAOF文件重写的工作流程
- 客户端发送BGREWRITEAOF命令：客户端向Redis服务器发送BGREWRITEAOF命令
- 主进程检查是否有正在执行的RDB/AOF操作：如果有，则直接返回，不执行新的BGREWRITEAOF
- 主进程fork()创建子进程：主进程通过fork()系统调用创建一个子进程
- 子进程生成新的AOF文件：子进程遍历内存中的数据，生成重写后的AOF文件
- 主进程继续处理写命令：主进程将新的写命令追加到原AOF文件和AOF重写缓冲区
- 子进程完成AOF重写：子进程完成AOF重写后，通知主进程
- 主进程合并AOF文件：主进程将AOF重写缓冲区的内容追加到新的AOF文件中
- 主进程替换AOF文件：主进程用新的AOF文件替换原有的AOF文件
AOF文件格式
AOF文件采用文本格式，记录Redis的写命令，例如：
txt
*3
$3
SET
$5
mykey
$7
myvalue
*3
$3
SADD
$4
myset
$1
1
*3
$3
SADD
$4
myset
$1
2AOF持久化的优缺点
优点
- 数据安全性高：可以实现秒级别的数据持久化
- 文件可读性好：AOF文件采用文本格式，便于查看和手动修改
- 支持增量备份：只记录新增的写命令
缺点
- 文件体积大：AOF文件体积通常比RDB文件大
- 恢复速度慢：加载AOF文件需要重放所有写命令，速度比RDB慢
- 对性能影响较大：特别是使用always同步策略时
混合持久化原理
Redis 4.0引入了混合持久化，结合了RDB和AOF的优点。
混合持久化的配置
txt
# 启用混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes混合持久化的工作流程
- 触发AOF重写：无论是自动触发还是手动触发，执行AOF重写
- 子进程生成混合格式的AOF文件：子进程首先将内存中的数据以RDB格式写入AOF文件，然后将AOF重写缓冲区中的写命令以AOF格式追加到AOF文件中
- 替换旧的AOF文件：重写完成后，用新的混合格式AOF文件替换旧的AOF文件
混合持久化的优缺点
优点
- 文件体积小：结合了RDB文件体积小的优点
- 恢复速度快：加载时先加载RDB部分，再重放AOF部分，比纯AOF快
- 数据安全性高：AOF部分记录了最近的写命令，数据安全性接近AOF everysec
缺点
- 文件可读性差：RDB部分是二进制格式，无法直接查看
- 需要Redis 4.0+版本：较旧的Redis版本不支持
Redis持久化的恢复流程
启动时的恢复流程
- Redis服务器启动：Redis服务器启动时，会检查是否存在持久化文件
- 优先加载AOF文件：如果同时存在RDB和AOF文件，Redis会优先加载AOF文件
- 加载RDB文件：如果只有RDB文件，或者AOF文件加载失败，则加载RDB文件
- 恢复数据：将持久化文件中的数据加载到内存中
- 开始处理客户端请求：数据加载完成后，Redis开始处理客户端请求
AOF文件损坏的处理
如果AOF文件损坏，可以使用Redis提供的修复工具：
bash
redis-check-aof --fix appendonly.aofRDB文件损坏的处理
如果RDB文件损坏，可以尝试使用以下方法：
bash
redis-check-rdb dump.rdb持久化机制的内部实现
copy-on-write机制
Redis使用copy-on-write（写时复制）机制来实现异步持久化：
- 主进程fork()创建子进程：子进程继承主进程的内存数据
- 主进程继续处理写命令：主进程修改数据时，会复制被修改的内存页，不影响子进程的内存数据
- 子进程生成持久化文件：子进程使用继承的内存数据生成持久化文件
持久化与内存管理
- RDB持久化：生成RDB文件时，会遍历整个内存中的数据，可能会触发内存页的写时复制
- AOF持久化：写命令追加到AOF缓冲区，不会立即触发磁盘I/O
- AOF重写：与RDB持久化类似，会遍历整个内存中的数据
持久化策略的选择
根据业务需求选择持久化策略
| 业务场景 | 推荐持久化策略 |
|---|---|
| 缓存场景，允许数据丢失 | 禁用持久化或使用RDB |
| 数据安全性要求高 | 启用混合持久化或AOF everysec |
| 对恢复速度要求高 | 使用RDB或混合持久化 |
| 大数据量场景 | 考虑使用RDB或混合持久化 |
实际部署建议
- 生产环境：推荐使用混合持久化，兼顾数据安全性和恢复速度
- 开发环境：可以根据需要选择合适的持久化策略
- 定期备份：无论使用哪种持久化策略，都应该定期备份持久化文件
- 监控持久化状态：监控持久化操作的执行情况，及时发现问题
常见问题（FAQ）
Q1: RDB和AOF持久化可以同时启用吗？
A1: 是的，Redis支持同时启用RDB和AOF持久化。在这种情况下，Redis启动时会优先加载AOF文件，因为AOF文件的数据完整性更高。
Q2: 为什么Redis在执行BGSAVE时会阻塞？
A2: Redis在执行BGSAVE时，主进程会执行fork()操作创建子进程。在fork()操作期间，主进程会暂时阻塞，阻塞时间取决于内存大小和系统性能。数据量越大，fork()操作的阻塞时间越长。
Q3: AOF文件重写会影响Redis的性能吗？
A3: AOF文件重写是由子进程执行的，不会直接阻塞主进程。但是，子进程在生成新的AOF文件时会消耗CPU和内存资源，可能会对Redis的性能产生一定影响。此外，主进程需要将新的写命令追加到AOF重写缓冲区，也会消耗一定的内存资源。
Q4: 如何选择合适的AOF同步策略？
A4: 选择AOF同步策略需要平衡数据安全性和性能：
- always：适合数据安全性要求极高的场景，如金融交易系统
- everysec：适合大多数场景，兼顾数据安全性和性能
- no：适合对性能要求极高，对数据安全性要求较低的场景
Q5: 混合持久化与纯AOF持久化相比，有什么优势？
A5: 混合持久化的优势包括：
- 文件体积更小：结合了RDB文件体积小的优点
- 恢复速度更快：加载时先加载RDB部分，再重放AOF部分，比纯AOF快
- 数据安全性高：AOF部分记录了最近的写命令，数据安全性接近AOF everysec
Q6: 如何监控Redis的持久化状态？
A6: 可以通过以下方式监控Redis的持久化状态：
- 使用
INFO persistence命令查看持久化相关统计信息 - 监控RDB和AOF文件的大小变化
- 监控持久化操作的执行时间
- 设置告警，当持久化操作失败时及时通知
Q7: 持久化文件的存储位置可以自定义吗？
A7: 是的，可以通过配置文件中的dir参数指定持久化文件的存储位置：
txt
dir /var/lib/redisQ8: Redis 7.0对持久化机制有什么改进？
A8: Redis 7.0对持久化机制的改进包括：
- 引入RDB版本7，支持更大数据集和更快恢复
- 改进AOF重写机制，减少磁盘I/O
- 优化混合持久化的性能
- 支持更灵活的RDB触发策略