Redis过期与持久化
过期机制自动清理数据，持久化机制保障数据安全，两者是Redis可靠运行的基础。
过期删除策略
三种策略
Bash
定时删除：创建定时器，到期立即删除
惰性删除：访问时检查过期，过期则删除
定期删除：周期性随机检查，删除过期键
Redis采用的策略
Bash
Redis采用：惰性删除 + 定期删除
- 惰性删除：每次访问key检查是否过期
- 定期删除：每秒10次随机抽查，删除过期键
定时删除消耗内存记录定时器，惰性+定期平衡内存和CPU。
惰性删除流程
Bash
客户端访问key → 检查是否过期 → 已过期则删除并返回nil → 未过期返回数据
Bash
SET mykey "value" EX 10
# 10秒后访问
GET mykey
# 检查过期 → 删除 → 返回
定期删除流程
Bash
1. 每100ms执行一次（hz默认10，每秒10次）
2. 随机抽查20个键
3. 发现过期则删除
4. 若超过25%过期，继续抽查
5. 限制每次执行时间不超过25ms
配置参数
Bash
# 每秒执行次数（默认10）
hz 10
# 增大hz可提高过期检查频率
hz 100 # 每秒100次检查
内存淘汰策略
当内存达到maxmemory时
Bash
# 设置内存上限
maxmemory 4gb
# 淘汰策略
maxmemory-policy volatile-lru
八种淘汰策略
| 策略 | 说明 | 适用场景 |
|---|---|---|
| noeviction | 不淘汰，写入报错 | 数据不能丢失 |
| allkeys-lru | 所有键LRU淘汰 | 缓存场景 |
| volatile-lru | 有过期时间的键LRU淘汰 | 缓存+持久数据 |
| allkeys-random | 所有键随机淘汰 | 无访问热点 |
| volatile-random | 有过期时间的键随机淘汰 | 缓存+持久数据 |
| volatile-ttl | 淘汰TTL最小的键 | 业务有TTL设置 |
| allkeys-lfu | 所有键LFU淘汰 | 有访问频率热点 |
| volatile-lfu | 有过期时间的键LFU淘汰 | 缓存+持久数据 |
LRU：最近最少使用，LFU：最不经常使用。
RDB持久化
RDB原理
Bash
将内存数据快照保存到磁盘
生成二进制文件dump.rdb
恢复时加载RDB文件到内存
触发条件
Bash
# 自动触发（save规则）
save 900 1 # 900秒内1次修改触发
save 300 10 # 300秒内10次修改触发
save 60 10000 # 60秒内10000次修改触发
# 手动触发
SAVE # 同步保存（阻塞）
BGSAVE # 后台保存（不阻塞）
RDB配置
Bash
# RDB文件名
dbfilename dump.rdb
# RDB文件目录
dir /var/lib/redis
# 压缩
rdbcompression yes
# 校验
rdbchecksum yes
RDB优点
Bash
- 文件紧凑，适合备份
- 恢复速度快，直接加载
- 对性能影响小（子进程fork）
- 适合灾难恢复
RDB缺点
text
- 可能丢失最后一次快照后的数据
- fork大内存进程可能阻塞
- 不适合实时持久化
AOF持久化
AOF原理
text
记录所有写命令到日志文件
追加写入，不修改已有内容
恢复时重新执行所有命令
AOF配置
text
# 开启AOF
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# 同步策略
appendfsync everysec
AOF同步策略
| 策略 | 说明 | 性能 | 安全性 |
|---|---|---|---|
| always | 每次写入同步 | 最差 | 最高 |
| everysec | 每秒同步 | 中等 | 较高 |
| no | 由系统决定 | 最佳 | 最低 |
everysec是推荐配置，最多丢失1秒数据。
AOF重写
text
# 自动重写条件
auto-aof-rewrite-percentage 100 # 文件增大100%触发
auto-aof-rewrite-min-size 64mb # 最小64MB触发
# 手动重写
BGREWRITEAOF
重写原理
text
1. Redis fork子进程
2. 子进程遍历内存生成新AOF
3. 主进程继续记录命令到旧AOF和缓冲区
4. 子进程完成后，主进程追加缓冲区命令
5. 替换旧AOF文件
AOF优点
text
- 数据安全，最多丢失1秒
- 日志可读，便于分析
- 支持重写，压缩文件
- 适合实时持久化
AOF缺点
text
- 文件比RDB大
- 恢复速度比RDB慢
- 写入性能略低
RDB与AOF对比
| 特性 | RDB | AOF |
|---|---|---|
| 文件大小 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全 | 可能丢失分钟数据 | 最多丢失1秒 |
| 系统资源 | fork消耗内存 | 持续写入磁盘 |
| 启动优先级 | 低 | 高（同时开启时） |
混合持久化
开启混合持久化
text
# Redis 4.0+支持
aof-use-rdb-preamble yes
混合持久化原理
text
AOF重写时：
1. 前半部分用RDB格式保存快照
2. 后半部分用AOF格式追加增量命令
3. 恢复时先加载RDB快照，再执行AOF命令
混合持久化优点
text
- RDB恢复快 + AOF数据安全
- 文件大小适中
- 推荐生产环境使用
持久化恢复
RDB恢复
text
# 将dump.rdb放到Redis数据目录
cp dump.rdb /var/lib/redis/
# 启动Redis自动加载
redis-server
AOF恢复
text
# 将appendonly.aof放到数据目录
cp appendonly.aof /var/lib/redis/
# 若AOF损坏，可修复
redis-check-aof --fix appendonly.aof
RDB校验
text
# 检查RDB文件
redis-check-rdb dump.rdb
要点总结
- 过期策略：惰性删除 + 定期删除
- maxmemory-policy配置内存淘汰策略，缓存常用allkeys-lru
- RDB适合备份和灾难恢复，可能丢失数据
- AOF数据安全，最多丢失1秒，推荐everysec
- appendfsync everysec是最佳平衡配置
- 混合持久化（Redis 4.0+）结合RDB和AOF优点
- 恢复时AOF优先级高于RDB
- redis-check-aof/redis-check-rdb用于修复损坏文件
📝 发现内容有误？点击此处直接编辑