企业官网建设流程全解析

1、简介

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。

Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。

2、RDB（定期快照式存储）

RDB方式的持久化是通过**快照**（snapshotting）完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

RDB是Redis默认采用的持久化方式（主从复制的时候默认使用的为RDB）。

生成的文件通常是：

dump.rdb

工作原理

内存数据 → fork子进程 → 子进程写入RDB文件 → 替换旧文件

触发方式

自动触发

#1.自动触发（配置文件中设置） save9001#900秒内至少有1个key改变 save30010#300秒内至少有10个key改变 save6010000#60秒内至少有10000个key改变

含义：

• 900 秒内有 1 次写 → 生成快照
• 300 秒内有 10 次写
• 60 秒内有 10000 次写

在redis.conf中：

• 配置dir指定rdb快照文件的位置
• 配置dbfilenam指定rdb快照文件的名称

手动触发

#2.手动触发 redis-cli>SAVE # 同步保存，阻塞其他操作 redis-cli>BGSAVE # 后台异步保存（推荐）

RDB 优缺点

优点

• ✅ 文件紧凑，适合备份和灾难恢复
• ✅ 恢复大数据集时速度比AOF快
• ✅ 最大化Redis性能（父进程无需磁盘IO）
• ✅ 支持子进程写时复制（Copy-On-Write）（不阻塞线程主从复制的时候会遗漏一部分，最后通过offset补齐）

缺点

• ❌ 可能丢失最后一次快照后的数据
• ❌ fork子进程时，内存占用翻倍
• ❌ 大数据集时fork可能耗时较长

3、AOF（追加日志是存储）

工作原理

默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：

appendonly yes

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数修改：appendfilename appendonly.aof。

AOF的工作流程：

• **命令追加（append）：**所有的写命令会追加到 AOF 缓冲区中。
• **文件写入（write）：**将 AOF 缓冲区的数据写入到 AOF 文件中。注意！！！此时并没有同步到磁盘。
• **文件同步（fsync）：**fsync 将阻塞直到写入磁盘完成后返回，保证了数据持久化。
• **文件重写（rewrite）：**随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩的目的。
• **重启加载（load）：**当 Redis 重启时，可以加载 AOF 文件进行数据恢复

AOF 重写机制

# 解决AOF文件过大的问题 # 通过重写创建当前数据集的最小命令集合 # 触发重写： auto-aof-rewrite-percentage100# 文件增长100%时重写 auto-aof-rewrite-min-size64mb # 最小64MB才重写 # 手动重写： redis-cli>BGREWRITEAOF

AOF 同步策略

# redis.conf 配置 appendonly yes # 开启AOF appendfilename"appendonly.aof"# AOF文件名 # 同步策略（重要！） appendfsync always # 每个写命令都同步，最安全但性能差 appendfsync everysec # 每秒同步一次（推荐，平衡安全与性能） appendfsync no # 由操作系统决定，最快但可能丢失数据

AOF 配置详解

# redis.conf 完整AOF配置 appendonly yes appendfilename"appendonly.aof"appendfsync everysec # AOF重写配置 no-appendfsync-on-rewrite no # 重写时是否停止fsync auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb # 加载时处理损坏的AOF aof-load-truncated yes # 加载截断的AOF文件 aof-use-rdb-preamble yes # 混合持久化（Redis4.0+）

AOF 优缺点

优点

• ✅ 数据安全性更高（最多丢失1秒数据）
• ✅ 可读的日志文件，便于分析
• ✅ 仅追加写入，无磁盘寻址开销
• ✅ 支持后台重写，不影响客户端

缺点

• ❌ 文件体积通常比RDB大
• ❌ 恢复速度比RDB慢
• ❌ 性能略低于RDB（取决于fsync策略）
• ❌ 可能遇到AOF重写bug

4、混合使用（RDB+AOF）

Redis支持两者同时开启：

工作原理

BGREWRITEAOF → 先写RDB快照到AOF文件 → 追加期间的AOF命令

不同场景推荐

#1.数据安全最重要 appendonly yes appendfsync always # 或 appendfsync everysec+频繁的RDB备份 #2.性能最重要 appendonly no save9001# 较少的RDB备份 #3.内存有限，需要快速重启 appendonly no dbfilename dump.rdb rdbcompression yes #4.推荐的生产配置（平衡型） appendonly yes appendfsync everysec auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb save9001save30010save6010000

• 优先使用AOF 恢复数据
• RDB 作为备份手段

👉这是生产环境的推荐方案。

#4.推荐的生产配置（平衡型） appendonly yes appendfsync everysec auto-aof-rewrite-percentage100auto-aof-rewrite-min-size64mb save9001save30010save6010000