redis内存持久化机制和淘汰策略使用详解

1.为什么需要持久化和淘汰策略

在日常使用redis的过程中，数据安全与内存管理是必须重点考虑的问题。

redis是基于内存的数据库，内存断电即失，所以需要持久化保证数据安全。

• 持久化：

解决数据断电丢失的问题；

redis内存有限，但数据超出阈值时，需要淘汰策略来决定哪些数据被清理。

• 淘汰策略：

解决内存不足时如何存放新数据的问题。

2.持久化机制

redis作为内存数据库，如果不做持久化，宕机后数据会全部丢失，为此redistribution提供了三种持久化方案。

2.1rdb(快照持久化)

原理：周期性将内存数据快照写入磁盘，生成dump.rdb文件。

触发方式

• 配置触发：

save 900 1     # 900 秒内有 1 次写操作则触发
save 300 10    # 300 秒内有 10 次写操作则触发
save 60 10000  # 60 秒内有 10000 次写操作则触发

• 手动触发：

save       # 阻塞 redis，生成快照
bgsave     # 后台 fork 子进程生成快照（推荐）

底层实现细节

bgsave 流程

• 主进程执行 fork，生成子进程；
• 子进程负责将快照写入磁盘文件；
• 主进程继续处理客户端请求。

写时复制（copy-on-write, cow）

fork后，父子进程共享内存页；

如果有写请求修改数据，操作系统会复制出新内存页：

• 子进程使用旧数据页生成 rdb；
• 主进程在新数据页上继续服务。
• 保证了快照的一致性，同时不会阻塞主进程。

缓冲区机制

• 在快照生成过程中，新的写操作会写入 redis 的正常数据结构；
• 子进程只写fork时刻的内存数据，不包含之后的新写入；
• 因此，rdb 只反映快照时刻的数据，可能丢失最近一次快照之后的数据。

优点：文件体积小，恢复速度快，适合做全量备份。

缺点：最后一次快照之后的数据可能会丢失。

2.2aof(追加日志)

原理：记录每条写命令，追加到日志文件 appendonly.aof，redis 重启时重放日志恢复数据。

aof重写：

 文件过大时，redis会进行aof重写：压缩日志，值保留恢复当前数据集的必要命令。

bgrewriteaof

使用方式：

• 开启方式

appendonly yes
appendfilename "appendonly.aof"

刷盘策略：

• always：每次写操作立即写盘（最安全，最慢）。
• everysec：每秒写一次盘（推荐）。
• no：完全交由操作系统（可能丢几秒数据）。

2.3混合持久化（rdb+aof）

• 原理：redis 4.0 引入，将 rdb 快照与增量 aof 结合。
• 优点：rdb提供基线数据，恢复快；aof记录快照之后的写操作，减少数据丢失。

配置：

aof-use-rdb-preamble yes

推荐：生产环境普遍采用混合持久化。

3.淘汰策略

1. 配置方式

maxmemory 512mb
maxmemory-policy allkeys-lru

2. 淘汰策略分类

不淘汰：noeviction，直接拒绝写入（默认）

 仅淘汰过期键：

• volatile-lru：淘汰最近最少使用的过期键。
• volatile-ttl：淘汰即将过期的键。
• volatile-random：随机淘汰过期键。
• volatile-lfu：淘汰访问频率最低的键。

 淘汰所有键：

• allkeys-lru：淘汰最近最少使用的键。
• allkeys-random：随机淘汰一个键。
• allkeys-lfu：淘汰访问频率最低的键。

3. lru 与 lfu

• lru：最近最少使用，适合热点数据场景。
• lfu：最少使用频率，适合长尾访问场景。

lru 并不是全局精确淘汰，而是近似算法：

• redis 不会扫描所有 key，而是每次 随机取出一部分 key（默认 5 个，可配置）；
• 在采样的这批 key 中，选择 最久未使用的一个 淘汰；
• 如果内存还是不足，就继续随机采样，直到释放出足够的内存。

# 默认采样 5 个 key
maxmemory-samples 5
# 可以调大，比如 20，提高淘汰的准确度，但 cpu 开销也会增加
maxmemory-samples 20

lfu 需要记录每个 key 的访问频率，redis 使用的是 对数递增计数器（log counter），避免计数无限增长。淘汰机制类似lru。

# 访问频率递减的时间因子（越大，计数越快衰减）
lfu-decay-time 1

总结

持久化

• rdb：快照，全量备份，快速恢复，但可能丢数据；
• aof：日志，数据更安全，但文件更大；
• 混合：结合两者优点，推荐生产使用。

淘汰策略

• noeviction：安全，但可能拒绝服务；
• lru / lfu：常用，适合缓存业务；
• 选择合适的策略，避免 oom。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。