Redis基础

上一篇我们吃透了Redis五大常用数据类型+实战命令，能熟练完成日常数据存取操作。但Redis核心是基于内存运行，一旦服务器重启、断电或服务崩溃，内存中的数据会全部丢失，这对于生产环境来说是致命风险。

这时候就需要Redis的持久化机制登场，它能把内存中的数据同步到硬盘，实现数据备份；重启时再从硬盘加载数据，避免数据丢失。本篇就详解Redis两大持久化方案：RDB（快照）和AOF（日志），从原理、配置、优缺点到实战选型，一篇讲透，帮你筑牢Redis数据安全防线。

核心结论先行：生产环境推荐RDB+AOF混合持久化，兼顾数据安全性、恢复速度和性能损耗，单机Redis必开持久化，集群模式也需按需配置。

一、什么是Redis持久化？为什么必须配置？

Redis持久化：将内存中的临时数据，写入硬盘永久保存的过程，目的是防止服务器异常导致数据丢失，实现数据恢复。

如果不配置持久化：

  • Redis重启/服务器断电，所有缓存数据、业务数据清零
  • 高并发场景下，缓存雪崩风险加剧，MySQL瞬间被打垮
  • 分布式锁、计数器、排行榜等数据丢失，业务逻辑错乱

Redis提供两种持久化方案，可单独使用，也可组合使用，适用不同业务场景。

二、RDB持久化：内存快照，快而精简

RDB（Redis Database Backup）：指定时间间隔内，对内存数据做全量快照，生成二进制dump.rdb文件保存到硬盘，相当于给内存数据拍“全身照”。

1. RDB核心原理

Redis通过fork子进程，单独完成快照写入，父进程继续处理客户端请求，不阻塞正常业务；满足配置的触发条件时，自动生成RDB文件，重启时直接加载RDB文件恢复数据。

2. RDB触发方式

（1）自动触发（配置文件控制）

修改redis.conf配置文件，设置快照触发规则：

# 编辑Redis配置文件
vim /usr/local/redis/redis.conf
# 默认配置：900秒内有1次修改、300秒内10次修改、60秒内10000次修改，触发RDB
save 900 1
save 300 10
save 60 10000

# RDB文件名
dbfilename dump.rdb

# RDB文件存储目录（上篇已创建）
dir /usr/local/redis/data

# 持久化失败是否停止写入（yes更安全）
stop-writes-on-bgsave-error yes

# 是否压缩RDB文件（yes节省空间）
rdbcompression yes

（2）手动触发（命令执行）

# 手动生成RDB快照（阻塞式，生产慎用）
save

# 后台异步生成RDB快照（推荐）
bgsave

3. RDB优缺点

优点缺点
RDB文件小，备份、传输、恢复速度极快定时快照，会丢失最后一次快照后的数据
子进程异步执行，对Redis性能影响小fork子进程时，内存翻倍占用，大内存实例会卡
适合大规模数据恢复、冷备场景数据安全性低，宕机易丢数据

三、AOF持久化：操作日志，细水长流

AOF（Append Only File）：记录Redis所有写操作命令，以文本形式追加到appendonly.aof文件，重启时重新执行AOF中的命令，恢复数据，相当于记录“操作流水账”。

1. AOF核心原理

客户端执行写命令（set、incr、hset等），Redis将命令写入AOF缓冲区，再根据配置策略同步到硬盘，避免每次写操作都刷盘，平衡性能与安全性。

2. AOF开启与配置

AOF默认关闭，需手动开启，修改redis.conf配置：

# 开启AOF持久化（yes为开启）
appendonly yes

# AOF文件名
appendfilename "appendonly.aof"

# AOF同步策略（核心配置）
# appendfsync always：每次写命令都刷盘，最安全，性能差
# appendfsync everysec：每秒刷盘一次，平衡安全与性能（推荐）
# appendfsync no：由操作系统决定刷盘，速度最快，不安全
appendfsync everysec

# AOF文件重写配置（压缩文件体积）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

3. AOF重写机制

AOF文件会随操作增多不断变大，Redis提供AOF重写，合并重复命令、删除无效命令，压缩文件体积，不阻塞主进程。

# 手动触发AOF重写
bgrewriteaof

4. AOF优缺点

优点缺点
数据安全性高，最多丢失1秒数据AOF文件大，恢复速度比RDB慢
命令可可读性强，可手动修改修复每秒刷盘会有轻微性能损耗
支持重写压缩，避免文件无限膨胀长期运行，文件体积远大于RDB

四、RDB vs AOF：核心对比

对比维度RDBAOF
存储方式二进制全量快照文本命令日志
数据丢失丢失快照间隔数据最多丢1秒数据
恢复速度极快较慢
文件体积小大
性能影响极小轻微
适用场景冷备、大规模恢复、追求性能核心业务、数据安全优先

五、生产环境最佳实践：混合持久化

Redis 4.0+支持RDB+AOF混合持久化，完美兼顾两者优势：

  • AOF重写时，将内存数据以RDB格式写入AOF文件头部
  • 后续写命令以AOF格式追加
  • 重启时，先加载RDB快照，再执行AOF增量命令，恢复快且数据安全

生产推荐配置

# 开启RDB
save 900 1
save 300 10
save 60 10000

# 开启AOF
appendonly yes
appendfsync everysec

# 开启混合持久化（Redis4.0+默认开启）
aof-use-rdb-preamble yes

# 文件存储目录
dir /usr/local/redis/data

六、持久化常见问题与避坑

1. RDB触发时Redis卡顿

原因：fork子进程占用内存，大内存实例阻塞明显 解决：避开高峰期执行bgsave，降低fork优先级，控制Redis实例内存不超过10G

2. AOF文件过大/恢复慢

解决：开启AOF自动重写，定期手动bgrewriteaof，采用混合持久化

3. 持久化文件备份

定期将dump.rdb和appendonly.aof文件拷贝到异地服务器，防止硬盘损坏

4. 关闭持久化场景

仅当Redis做纯缓存、数据可丢失、追求极致性能时，才可关闭持久化，生产核心业务严禁关闭

七、数据恢复实操

  1. 关闭Redis服务：systemctl stop redis
  2. 将备份的dump.rdb/appendonly.aof拷贝到配置的dir目录
  3. 启动Redis：systemctl start redis
  4. 连接客户端执行keys *，验证数据是否恢复

总结与下篇预告

持久化是Redis生产可用的核心前提，RDB适合快速备份恢复，AOF保证数据安全，生产环境务必开启混合持久化，既不浪费性能，又能杜绝数据丢失风险。

发表回复