登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  数据库 >  Redis

Redis 内存淘汰策略怎样与持久化配合

来源:17golang原创

时间:2026-11-07 21:53:50 240浏览 收藏

Redis 内存达到 maxmemory 后,是否删除键由 maxmemory-policy 决定;RDB 和 AOF 则负责把数据状态或写入记录保存到磁盘。两者解决的不是同一个问题:淘汰是“内存不够时保留谁”,持久化是“进程重启后怎样恢复”。

官方地址:https://redis.io/

缓存场景通常用 allkeys-lru 或 allkeys-lfu 控制内存;重要数据不能靠淘汰策略保护,应按可接受的数据损失选择 RDB、AOF 或两者组合。淘汰发生在当前内存数据集上,不能当作备份机制。

先分清内存淘汰和持久化

maxmemory 是内存上限,达到上限后 Redis 会依据 maxmemory-policy 找候选键。这个动作可能删除持久键,也可能只删除带过期时间的键,具体取决于策略。

持久化发生在另一条链路上。RDB 以时间点快照保存数据集,AOF 记录写入操作并在启动时重放。键被淘汰后,当前数据集已经改变;之后生成的快照或重写后的 AOF 会以这个新状态为基础。因此,淘汰不是“把键挪到磁盘”,而是改变 Redis 当前持有的数据。

Redis 内存淘汰策略与可淘汰键集合的关系结构图
图1:Redis 内存淘汰策略与可淘汰键集合的静态说明图,不是运行截图。

按键集合选择 maxmemory-policy

先回答一个业务问题:内存中的键是否都可以重新从后端数据源生成?如果答案是“是”,可以从所有键中选择淘汰;如果只有设置了 TTL 的键属于缓存,才适合 volatile-* 策略。

策略方向候选范围适合的边界
allkeys-lru所有键访问越近越应保留的通用缓存
allkeys-lfu所有键访问频率比最近访问时间更重要的缓存
volatile-ttl仅带 TTL 的键持久键必须留下、临时键可以被清理
noeviction不淘汰写入失败也比静默删除数据更可接受的场景

例如,一台 Redis 只保存可重建的页面缓存,可以把内存上限和淘汰策略写入配置:

# 限制 Redis 用于数据集的内存,实际部署还要为后台操作预留空间
maxmemory 2gb
# 从所有键中淘汰最近最少使用的键,适合可重新生成的缓存
maxmemory-policy allkeys-lru

如果使用 volatile-*,必须确保缓存键真的设置了过期时间;当候选集合为空时,写入仍可能失败。对于需要保留的业务数据,不要为了“让写入成功”随意改成全键淘汰。

把 RDB 和 AOF 放到持久化链路

RDB 适合定期备份和较快恢复,代价是两个快照之间的写入可能丢失。AOF 记录写入操作,通常能把数据恢复到更接近故障前的状态,但文件和重写开销会更高。两者同时开启时,Redis 重启通常使用更完整的 AOF 来重建数据集。

Redis 内存数据集、RDB、AOF 与重启恢复的边界结构图
图2:Redis 淘汰策略与持久化策略边界的静态结构图,不是运行截图。

最小配置示意如下,注释说明了每个设置的目的:

# 用快照保留可恢复的数据时间点
save 900 1
save 300 10
# 开启 AOF,让写入操作进入追加文件
appendonly yes
# 每秒同步一次,在数据安全与写入开销之间折中
appendfsync everysec

这段配置不是“淘汰后自动备份”。如果键已经因内存压力被删除,之后的持久化文件也可能不再包含它。需要备份时,应保留独立的 RDB 归档或符合恢复要求的 AOF 文件,并把磁盘空间、重写期间的额外开销纳入容量规划。

三类场景怎样组合

可重建缓存

使用 maxmemory 配合 allkeys-lru 或 allkeys-lfu。持久化可以关闭,或者只保留低频 RDB 作为运维辅助;关键是应用必须能从数据库、接口或对象存储重新构建缓存。

缓存与少量持久键共存

让可淘汰数据带 TTL,再考虑 volatile-lru 或 volatile-ttl。写入链路需要明确处理“没有可淘汰候选”的错误,不能假设设置了 TTL 就一定能写入。

重要写入数据

不要依靠任何淘汰策略保证数据不丢。可以使用 noeviction 让超限写入显式失败,再根据数据损失目标选择 RDB、AOF 或组合,并配合复制和异地备份。AOF 的 appendfsync 越偏向频繁同步,写入开销通常越高。

配置时别忽略这些额外内存

maxmemory 主要约束数据集,但 Redis 还要为客户端输出缓冲、复制积压、AOF 缓冲和后台 RDB/AOF 操作留出空间。把机器总内存全部分给 maxmemory,可能导致操作系统层面的内存压力。

因此上线前至少确认三件事:第一,淘汰的是可重建副本而不是唯一数据;第二,持久化文件所在磁盘能容纳快照、AOF 重写临时文件和历史备份;第三,应用能处理 OOM 或写入失败,而不是把错误吞掉。

结论

可以把 Redis 的决策记成一句话:淘汰策略决定内存里删谁,持久化策略决定重启时拿什么恢复;前者不能替代后者,后者也不能让被淘汰的键自动回来。缓存优先考虑 allkeys-lru 或 allkeys-lfu,带 TTL 的混合数据谨慎使用 volatile-*,重要数据则优先保证写入失败可见、持久化可恢复和备份可用。

相关问题

maxmemory-policy 默认就是 LRU 吗?

不要按默认值推断业务行为。部署时应显式设置策略,并结合 Redis 版本的官方配置说明确认实际取值。

开启 AOF 后还需要 RDB 吗?

如果需要更快恢复、定期备份或多一种恢复材料,可以保留 RDB;是否组合取决于可接受的数据损失、磁盘和恢复时间目标。

淘汰键会不会从 AOF 里永久保留?

AOF 记录写入操作,后台重写会生成更紧凑的当前数据集表示。无论如何,都不能把它当作“被淘汰键的回收站”;需要恢复历史状态应使用独立备份和明确的恢复流程。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>