Redis如何实现持久化

Redis如何实现持久化

Redis默认将所有数据存储在内存中，虽然读写效率极高，但存在两大风险

• 数据易失性：进程重启或服务器宕机导致内存数据丢失。
• 恢复成本高：无法直接通过内存重建大规模数据集。

Redis作为高性能的键值数据库，其核心特性之一是数据持久化——将内存中的数据持久保存到磁盘，防止服务宕机时数据丢失，持久化机制通过在磁盘中保存数据副本，为Redis提供了数据安全保障和灾难恢复能力

目前Reids有两种持久化机制

RDB

RDB全称Redis Database Backup file(Redis数据备份文件)，也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录

触发方式

1. 手动触发：

   • SAVE：阻塞主进程直至快照完成（生产环境慎用）
   • BGSAVE：fork子进程异步生成快照（主流方式）

2. 自动触发：
   在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文件。
• 恢复速度慢：重放所有命令耗时较长。
• 写入负载高：高频写入场景可能影响性能。

对比

如何选择持久化方案