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

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

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

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

先分清内存淘汰和持久化

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

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

按键集合选择 maxmemory-policy

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

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

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

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

把 RDB 和 AOF 放到持久化链路

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

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

# 用快照保留可恢复的数据时间点
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 记录写入操作，后台重写会生成更紧凑的当前数据集表示。无论如何，都不能把它当作“被淘汰键的回收站”；需要恢复历史状态应使用独立备份和明确的恢复流程。