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

首页

数据库

热心网友

转载

2026-04-30

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

谈到Redis的日常运维，有两个话题总是绕不开：数据安全与内存管理。这两个点，可以说是用好Redis的基石。

Redis毕竟是将数据放在内存里的，内存的特性就是“断电即失”。所以，要想数据安全，必须有一套可靠的持久化机制，给内存数据做个“安全备份”。

另一方面，服务器的内存再大也是有限的。当数据量逼近甚至超过这个上限时，淘汰策略就得登场了，它决定了哪些“老”数据需要被请出去，给“新”数据腾地方。

持久化：解决的是数据“存得住”的问题，核心在于对抗意外丢失。
淘汰策略：解决的是内存“不够用”的问题，核心在于高效管理有限资源。

这两个机制一守一攻，共同保障了Redis服务的稳定与高效。

2.持久化机制

既然是内存数据库，那宕机就意味着数据全失。为了避免这种灾难性后果，Redis为我们提供了三种主流的持久化方案，各有侧重。

2.1 RDB(快照持久化)

你可以把RDB理解成给数据库“拍照片”。它会在特定时机，将内存中所有数据的状态，完整地保存到一个二进制文件（通常是dump.rdb）中。

触发方式

这张“照片”什么时候拍呢？主要有两种方式：

自动定时拍：通过在配置文件中设定规则，比如：

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

手动拍：通过命令随时执行：

SA VE       # 阻塞整个 Redis 服务，直到快照完成
BGSA VE     # 后台异步生成快照（生产环境推荐）

底层实现细节

重点说说推荐的BGSA VE，它的设计相当巧妙。

BGSA VE 流程

主进程通过 fork 系统调用，创建一个子进程。
这个子进程的任务，就是专心将 fork 时刻的内存数据写入磁盘。
与此同时，主进程完全不阻塞，继续正常服务所有客户端请求。

写时复制（Copy-On-Write, COW）

这里的关键技术是“写时复制”。fork之后，父子进程共享同一份内存物理页。听起来数据会乱？别急。

当主进程接收到新的写请求，需要修改某块数据时，操作系统会将被修改的那一页内存复制一份。这样一来：

子进程拿着复制前的“旧”数据页，安心地生成 RDB 文件，保证了快照数据的一致性。
主进程则在复制出的“新”数据页上进行修改，服务丝毫不受影响。

缓冲区机制

需要明确一点：子进程只“看到”并保存 fork 那一瞬间的内存数据。在它兢兢业业写盘的过程中，主进程新处理的所有写操作，都只存在于Redis的内存数据结构里。这意味着，RDB文件反映的是一个历史瞬间的状态，最后一次快照之后的所有数据修改，都有丢失的风险。

所以，它的优缺点非常鲜明：

优点：生成的压缩二进制文件体积小，恢复数据时直接载入内存，速度极快，非常适合做定期的全量备份。

缺点：根据备份周期，可能会丢失从上次快照到故障点之间的所有数据。

2.2 AOF(追加日志)

如果说RDB是“拍照片”，那AOF就是“记日记”。它的原理很直观：把每一次写命令都记录下来，追加到一个日志文件（appendonly.aof）里。重启时，只需把“日记”从头到尾执行一遍，数据就恢复了。

AOF重写：

日记记久了，难免冗长。比如对一个键累加100次，AOF会记录100条命令，但实际上只需一条set key 100就能恢复。因此，Redis提供了AOF重写机制，它能压缩日志，最终只生成恢复当前数据集所需的最简命令序列。

BGREWRITEAOF

使用方式：

首先需要开启它：

appendonly yes
appendfilename “appendonly.aof”

刷盘策略：这是AOF可靠性的关键

always：每执行一条写命令，立即同步到磁盘。安全性最高，但性能影响最大。
everysec：每秒批量同步一次。这是安全与性能的折中，也是生产环境的推荐选择，最多丢失1秒数据。
no：完全依赖操作系统自身调度同步，性能最好，但可能丢失一个时间段的数据。

2.3 混合持久化（RDB+AOF）

既然RDB恢复快但可能丢数据，AOF数据安全但恢复慢，能不能鱼与熊掌兼得？Redis 4.0引入的混合持久化，正是这个思路的完美答卷。

原理：在AOF重写时，不再只生成纯AOF格式日志，而是先将此刻的数据集以RDB格式写入文件头部，再将重写期间产生的增量写命令以AOF格式追加其后。
优点：重启恢复时，先快速加载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：淘汰访问频率最低的键。

对于纯缓存场景，通常使用allkeys-lru或allkeys-lfu。

3. LRU 与 LFU 的算法细节

LRU（最近最少使用）：认为“很久没用的数据，将来也用不到”。非常适合热点数据分布明显的场景。
LFU（最不经常使用）：认为“过去访问次数少的数据，将来访问概率也低”。适合访问模式相对平均，需要区分冷热的长尾场景。

这里有个关键点：Redis实现的LRU/LFU并非全量精确计算，而是基于采样的近似算法。原因很简单，全局扫描所有键的访问信息，成本太高。

以LRU为例，其流程是：

当需要淘汰数据时，Redis从键空间中随机抽取一定数量的键（默认5个，通过maxmemory-samples配置）。
在这批“样本”中，淘汰那个最近一次访问时间最早的键。
如果释放的内存还不够，就重复这个抽样淘汰过程。

# 调整采样数量，越大越接近精确LRU，但CPU消耗也越高
maxmemory-samples 20

LFU的实现则更精细一些，它需要统计每个键的访问频率。Redis使用了一个基于对数递增的计数器，访问次数越多，计数器增长越缓慢，避免了无限增长。同时，它还有一个衰减机制，让长时间未访问的键的频率值能够逐渐降低。

# 控制访问频率计数器衰减速度的时间因子
lfu-decay-time 1

总结

把今天的核心要点梳理一下：

持久化

RDB：像定期拍全照，恢复快，备份文件小，但可能丢失两次拍照之间的“精彩瞬间”。
AOF：像写日记，记录每一步操作，数据安全性高，但文件体积大，恢复过程慢。
混合持久化：先拍一张RDB底片，再接着记AOF日记。取长补短，是当前生产环境的主流选择。

淘汰策略

noeviction：守门员策略，宁拒不错，适合非缓存的关键数据。
LRU / LFU：缓存系统的左膀右臂，根据数据访问模式（热点还是长尾）来选择合适的算法。

理解这些机制的原理与取舍，是在生产环境中稳定、高效使用Redis的必备功课。希望这次的梳理，能为你提供一个清晰的配置和选型思路。

来源:https://www.jb51.net/database/355675pmz.htm

免责声明：游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

上一篇：解决Access出现Microsoft JET Database Engine (0x80004005)未指定的错误下一篇：PEAR DB将数据库工作简化