Redis混合持久化策略

Redis 的五种数据结构各有特色，用对了才能发挥它的优势。很多人只用到了 String 和 Hash，却不知道 List、Set、ZSet 在特定场景下更合适。本文从应用场景出发，讲什么时候用什么类型。

一、为什么需要混合持久化

#

1.1 RDB和AOF的痛点

RDB的问题：

• 可能丢失最后一次save后的数据
• 频繁BGSAVE影响性能

AOF的问题：

• 文件大，恢复慢
• 重放所有命令耗时

# 仅AOF恢复100GB数据可能需要数小时
# 需要逐条执行命令

#

1.2 混合持久化的思想

AOF文件格式（混合持久化）：
┌─────────────────┬─────────────────────┐
│  RDB格式前缀     │  AOF格式增量命令     │
│  (全量快照)      │  (重写后的增量)      │
└─────────────────┴─────────────────────┘

恢复时：
1. 加载RDB前缀 → 快速恢复大部分数据
2. 执行AOF命令 → 恢复最新增量数据

优势：

• 恢复速度接近RDB
• 数据安全性接近AOF
• 文件大小比纯AOF小

二、混合持久化配置

#

2.1 开启配置

# redis.conf (Redis 4.0+)

# 开启AOF
appendonly yes

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

# AOF重写触发条件
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# RDB同时保存
save 900 1
save 300 10
save 60 10000

#

2.2 验证配置

# 查看混合持久化是否开启
redis-cli CONFIG GET aof-use-rdb-preamble
# 1) "aof-use-rdb-preamble"
# 2) "yes"

# 查看AOF文件信息
redis-cli INFO persistence
# aof_enabled:1
# aof_rewrite_in_progress:0
# aof_rewrite_scheduled:0

三、混合持久化的工作原理

#

3.1 AOF重写流程（混合模式）

触发AOF重写
    │
    ├── fork子进程
    │       │
    │       ├── 子进程：生成RDB格式数据
    │       │       └── 扫描内存，写入临时AOF文件
    │       │           （前部为RDB二进制格式）
    │       │
    │       └── 父进程：继续服务客户端
    │               └── 新命令写入AOF重写缓冲区
    │
    ├── 子进程完成写入
    │       │
    │       └── 通知父进程
    │
    ├── 父进程将重写缓冲区的命令追加到临时文件
    │       └── （后部为AOF文本格式）
    │
    ├── 原子替换旧AOF文件
    │
    └── 完成

#

3.2 生成的AOF文件格式

# 查看AOF文件头部（混合模式）
head -c 10 appendonly.aof | xxd

# 输出示例：
# 00000000: 5245 4449 5330 3031 30ff              REDIS0010.
# 
# 以"REDIS"开头，说明是RDB格式前缀

# 查看AOF文件中后部的文本命令
tail -20 appendonly.aof

# 输出示例：
# *2
# $6
# SELECT
# $1
# 0
# *3
# $3
# SET
# $4
# name
# $5
# Alice

#

3.3 文件结构详解

混合AOF文件：

┌─────────────────────────────────────────────────────────────┐
│ RDB前缀（二进制）                                            │
│ ┌─────────┬─────────┬─────────────────┬─────────┐          │
│ │ REDIS   │ VERSION │ SELECT DB 0     │ KEY-VALUE PAIRS │  │
│ │ magic   │ 0009    │                 │ (RDB编码)       │  │
│ └─────────┴─────────┴─────────────────┴─────────┘          │
│                                                             │
│ AOF后缀（文本）                                              │
│ ┌───────────────────────────────────────────────────────┐  │
│ │ *3\r
$3\r
SET\r
$4\r
name\r
$5\r
Alice\r
      │  │
│ │ ...                                                   │  │
│ └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

四、恢复机制

#

4.1 启动恢复流程

Redis启动
    │
    ├── 检查AOF文件是否存在
    │       │
    │      是
    │       │
    │       ├── 检查文件头是否为"REDIS"
    │       │       │
    │       │      是 → 混合AOF文件
    │       │       │
    │       │       ├── 加载RDB前缀
    │       │       │       └── 使用RDB加载机制（快速）
    │       │       │
    │       │       └── 加载AOF后缀
    │       │               └── 逐条执行命令（精确）
    │       │
    │       │      否 → 纯AOF文件
    │       │       └── 逐条执行所有命令
    │       │
    │      否
    │       └── 检查RDB文件
    │               └── 加载RDB文件
    │               └── 无文件则空启动

#

4.2 恢复速度对比

数据量	纯RDB	纯AOF	混合持久化
1GB	数秒	数分钟	数秒
10GB	数十秒	数十分钟	数十秒
100GB	数分钟	数小时	数分钟

混合持久化的恢复速度接近RDB！

五、生产环境配置建议

#

5.1 推荐配置

# redis.conf

# 基础配置
bind 0.0.0.0
port 6379
daemonize yes
pidfile /var/run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

# RDB配置
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb

# AOF配置
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no

# 混合持久化（核心）
aof-use-rdb-preamble yes

# AOF重写配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载截断AOF（防止AOF损坏导致无法启动）
aof-load-truncated yes

# 内存配置
maxmemory 4gb
maxmemory-policy allkeys-lru

#

5.2 不同场景的配置

场景一：数据安全优先

# 金融、电商订单等
appendonly yes
appendfsync always          # 每次写入都fsync
aof-use-rdb-preamble yes
save ""                     # 禁用RDB自动save（减少fork）

场景二：性能优先

# 纯缓存场景
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
save 900 1
save 300 10

场景三：大数据量

# 100GB+ 数据
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
auto-aof-rewrite-percentage 50    # 增长50%就重写
auto-aof-rewrite-min-size 1gb     # 最小1GB

六、监控和维护

#

6.1 监控指标

# AOF文件大小
redis-cli INFO persistence | grep aof_current_size

# AOF重写状态
redis-cli INFO persistence | grep aof_rewrite

# RDB最后一次保存时间
redis-cli LASTSAVE

# 查看持久化统计
redis-cli INFO persistence

#

6.2 AOF重写监控脚本

#!/bin/bash
# monitor_aof.sh

AOF_SIZE=$(redis-cli INFO persistence | grep aof_current_size | cut -d: -f2)
AOF_BASE=$(redis-cli INFO persistence | grep aof_base_size | cut -d: -f2)

# 计算增长百分比
if [ $AOF_BASE -gt 0 ]; then
    PERCENTAGE=$(( (AOF_SIZE - AOF_BASE) * 100 / AOF_BASE ))
    echo "AOF增长: ${PERCENTAGE}%"
    
    if [ $PERCENTAGE -gt 150 ]; then
        echo "AOF增长过快，建议触发重写" | mail -s "Redis AOF告警" admin@company.com
    fi
fi

#

6.3 定期维护

# 1. 手动触发AOF重写（低峰期）
redis-cli BGREWRITEAOF

# 2. 监控重写进度
redis-cli INFO persistence | grep aof_rewrite_in_progress

# 3. 验证AOF文件完整性
redis-check-aof --fix appendonly.aof

# 4. 备份AOF文件
cp appendonly.aof /backup/redis/$(date +%Y%m%d)/

# 5. 备份RDB文件
cp dump.rdb /backup/redis/$(date +%Y%m%d)/

七、常见问题

#

7.1 AOF重写时内存暴涨

现象：BGREWRITEAOF期间内存使用翻倍

原因：

• fork子进程的COW机制
• 父进程持续写入，大量页面被复制

解决：

# 1. 控制Redis内存使用（不超过物理内存50%）
# 2. 关闭透明大页
echo never > /sys/kernel/mm/transparent_hugepage/enabled

# 3. 监控并重写时机选择
# 在低峰期触发重写

#

7.2 AOF文件损坏

现象：Redis无法启动，报错 “Bad file format”

解决：

# 1. 备份损坏的AOF文件
cp appendonly.aof appendonly.aof.corrupt

# 2. 修复AOF文件
redis-check-aof --fix appendonly.aof

# 3. 如果修复失败，从RDB恢复
# 删除AOF文件，从RDB启动
rm appendonly.aof
redis-server /etc/redis/redis.conf

# 4. 重新开启AOF
redis-cli CONFIG SET appendonly yes

#

7.3 混合持久化不生效

排查：

# 1. 检查Redis版本
redis-cli INFO server | grep redis_version
# 需要 >= 4.0

# 2. 检查配置
redis-cli CONFIG GET aof-use-rdb-preamble

# 3. 检查AOF文件头
head -c 5 appendonly.aof
# 应该输出 "REDIS"

八、总结

持久化方式	恢复速度	数据安全	文件大小	推荐
RDB	快	低	小	备份
AOF	慢	高	大	数据安全
混合	快	高	中	生产推荐

混合持久化的核心价值：

1. 快速恢复：RDB前缀秒级加载
2. 数据安全：AOF后缀保证不丢数据
3. 文件紧凑：比纯AOF小很多
4. Redis 4.0+默认开启：开箱即用

生产环境最佳实践：

1. 开启混合持久化（aof-use-rdb-preamble yes）
2. AOF使用everysec模式
3. 同时配置RDB作为额外备份
4. 定期验证备份可用性
5. 监控AOF文件增长和重写状态

核心要点

1. String：简单的键值对，适合缓存、计数器

2. Hash：存储对象属性，适合用户信息、配置

3. List：有序列表，适合消息队列、最新列表

4. Set：无序去重，适合共同好友、抽奖

5. ZSet：有序集合，适合排行榜、积分系统

总结

选择合适的数据结构是使用 Redis 的关键。在实际项目中，根据业务需求选择合适的类型，可以提升性能和开发效率。