Redis持久化深度解析：数据安全与性能的平衡艺术

一、为什么需要持久化？

Redis作为内存数据库，数据存储在内存中带来极速性能的同时，也面临数据易失性风险：

• 服务器断电
• 进程崩溃
• 人为误操作

持久化核心目标：在磁盘上创建数据的副本，实现故障恢复与数据备份。

二、Redis持久化双雄

1. RDB（Redis Database）

工作原理：定时生成内存快照（Snapshot），存储某个时间点的全量数据
记录内容： 扫描内存中的所有数据，生成二进制数据
手动执行： Redis提供了两个命令来生成RDB文件

• save：主线程生成RDB 文件，阻塞主线程
• bgsave：创建子线程生成RDB文件，不阻塞主线程
  配置自动触发：

  # 自动触发配置示例
  save 900 1      # 15分钟至少1个key变化
  save 300 10     # 5分钟至少10个key变化
  save 60 10000   # 1分钟至少10000个key变化
  

  自动配置采用的是bgsave，通过创建子线程来生成RDB文件

核心优势：

• 紧凑的二进制文件（适合备份）
• 极快的恢复速度（大数据量场景优势明显）
• 最大化Redis性能（主进程不参与持久化）

潜在风险：
因为每次生成RDB文件都需要扫描内存的中全部数据并写入磁盘，所以不能太频繁写入，否则可能会对Redis性能造成影响。

• 可能丢失最后一次快照后的数据
• 大数据量时fork可能阻塞服务

2. AOF（Append Only File）

工作原理：记录每个写操作命令，先执行写命令，后写入日志

这个思路有没有感觉很熟悉，之前MySQL 的redo log 日志也是这种实现机制

配置项：
在 Redis 中 AOF 持久化功能默认是不开启的（Redis 6.0 之后已经默认是开启了），需要修改 redis.conf 配置文件

# 启用AOF
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# AOF配置写回策略
appendfsync always   # 每个命令都同步
appendfsync everysec # 每秒同步（默认）
appendfsync no       # 由操作系统决定

核心优势：

• 数据安全性更高（最多丢失1秒数据）
• 可读的日志文件（便于故障分析）
• 自动重写机制压缩文件大小

潜在风险：

• 执行写操作命令和记录日志是两个步骤，如果日志未同步到磁盘中时，服务宕机，则会丢失数据
• 写日志和写操作都是通过主线程中完成的，写日志到内存时会阻塞下一个写命令

AOF 重写机制：
因为AOF 会一直记录写的日志，长时间后，这个日志文件就会变得很大。此时就需要重写AOF 日志，去除已经失效的命令日志，来减少文件的大小。具体实现就是读取内存中所有数据，以写命令的方式重新生成一个AOF 日志，完成后用新文件替代旧文件

• 后台子进程完成，不阻塞主线程，可正常写入数据
• 采用写时复制，在发生写操作的时候，操作系统才会去复制物理内存，避免阻塞父线程

  # 重写触发条件
  auto-aof-rewrite-percentage 100  # 文件增长100%触发
  auto-aof-rewrite-min-size 64mb   # 最小文件大小
  

性能影响：

• AOF文件通常比RDB大
• 不同fsync策略对性能影响显著

写回策略总结：

选型建议

• 优先使用默认的 everysec 策略，除非有明确需求。
• 仅在极端一致性要求的场景中使用 always（需配合高性能SSD）。
• no 策略仅建议用于纯缓存场景。

三、混合持久化（Redis 4.0+）

创新方案：RDB快照 + 增量AOF日志

# 开启混合模式
aof-use-rdb-preamble yes

恢复流程：

1. 加载RDB快照基础数据
2. 重放后续AOF增量命令

优势：

• 兼顾启动速度与数据安全
• 显著减少AOF文件体积

结语：没有完美的方案，只有合适的策略

理解不同持久化机制的特性，结合业务场景：

AOF 部分其实涉及了好多操作系统相关的知识，比如重写时fork子进程，写时复制、这些在上文简单提到了，还有没提到的如用户态、内核态等。作者的知识储备也不够，愿意详细研究实现原理的自行学习一下，如果只是简单理解或者应付面试的话，说完这篇文章的知识点基本也就没问题了