Redis如何实现持久化
Redis如何实现持久化
Redis默认将所有数据存储在内存中，虽然读写效率极高，但存在两大风险
- 数据易失性：进程重启或服务器宕机导致内存数据丢失。
- 恢复成本高：无法直接通过内存重建大规模数据集。
Redis作为高性能的键值数据库，其核心特性之一是数据持久化——将内存中的数据持久保存到磁盘，防止服务宕机时数据丢失，持久化机制通过在磁盘中保存数据副本，为Redis提供了数据安全保障和灾难恢复能力
目前Reids有两种持久化机制
RDB
RDB全称Redis Database Backup file(Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。
快照文件称为RDB文件，默认是保存在当前运行目录
触发方式
-
手动触发：
SAVE：阻塞主进程直至快照完成（生产环境慎用）BGSAVE：fork子进程异步生成快照（主流方式）
-
自动触发：
在redis.conf中配置规则，例如：save 900 1 # 900秒内至少1次修改 save 300 10 # 300秒内至少10次修改 save 60 10000 # 60秒内至少10000次修改RDB的其他配置也可以在
redis.conf中配置# 是否压缩,建议不开启，压缩也会消耗cpu，磁盘的话不值钱 rdbcompression yes# RDB文件名称 dbfilename dump.rdb#文件保存的路径目录 dir ./
异步生成
在 Redis 生成 RDB 文件时是异步的(使用 bgsave 命令)采用了 fork 子进程的方式来进行快照操作。生成 RDB 文件的过程由子进程执行，主进程继续处理客户端请求，所以可以保证 Redis 在生成快照的过程中依然对外提供服务，不会影响正常请求
并且在生成过程中，主进程会正常处理客户端的请求，如果进行数据的修改，就会使用写时复制的技术：
- 当主进程执行读操作时，访问共享内存
- 当主进程执行写操作时，则会拷贝一份数据，执行写操作，后续主进程的读操作也会访问拷贝的数据
优缺点
优点
- 文件紧凑：二进制压缩格式，体积小，适合备份与迁移。
- 恢复速度快：直接加载快照文件到内存，效率极高。
- 性能影响小：异步生成快照，对主进程影响有限。
缺点
- 数据丢失风险：两次快照间的数据可能丢失。
- 大文件生成耗时：数据集较大时，fork子进程可能导致短暂延迟。
AOF
AOF全称为Append OnlyFile(追加文件)，Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。，AOF以日志形式记录所有写操作命令，重启时通过重放命令重建数据，AOF文件更注重数据安全性
比如说当执行写操作的时候：
SET name jack
这条命令会更改redis中的数据，并且在AOF文件中记录操作命令：
$3
SET
$3
name
$3
jack
AOF默认是关闭的，需要在配置文件中打开
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename"appendonly.aof"
文件同步策略：根据策略（appendfsync）将缓冲区内容写入磁盘：
always：每次写操作同步（安全，性能最低）everysec：每秒同步（平衡方案，推荐默认）no：由操作系统决定（性能最佳，风险最高）
可以redis.conf中配置：
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到A0F文件，是默认方案
appendfsync everysec#写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
优缺点
优点
- 数据安全性高：最多丢失1秒数据（
everysec配置）。 - 可读性强：AOF文件为文本格式，便于人工分析。
- 容错机制：支持崩溃后使用
redis-check-aof工具修复。
缺点
- 文件体积大：即使经过重写，通常仍大于RDB文件。
- 恢复速度慢：重放所有命令耗时较长。
- 写入负载高：高频写入场景可能影响性能。
对比
| RDB | AOF | |
|---|---|---|
| 持久化方式 | 定时对整个内存做快照 | 记录每一次执行的命令 |
| 数据完整性 | 不完整，两次备份之间会丢失 | 相对完整，取决于刷盘策略 |
| 文件大小 | 会有压缩，文件体积小 | 记录命令，文件体积很大 |
| 宕机恢复速度 | 很快 | 慢 |
| 数据恢复优先级 | 低，因为数据完整性不如AOF | 高，因为数据完整性更高 |
| 系统资源占用 | 高，大量CPU和内存消耗 | 低，主要是磁盘IO资源 但AOF重写时会占用大量CPU和内存资源 |
| 使用场景 | 可以容忍数分钟的数据丢失，追求更快的启动速度 | 对数据安全性要求较高常见 |
如何选择持久化方案
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 数据备份与快速恢复 | RDB | 文件小，加载速度快 |
| 高数据安全性要求 | AOF（everysec） | 最多丢失1秒数据 |
| 平衡安全与性能 | RDB + AOF（混合模式） | 兼顾恢复速度与实时性 |
| 容灾恢复 | RDB定期备份至云存储 | 防止物理损坏 |