本文面向对 Redis 有一定使用经验，并希望深入理解其内存管理与性能调优的中高级工程师。我们将从一个典型的业务问题出发，深入剖析缓存淘汰算法的计算机科学原理，然后直击 Redis 的工程实现，解构其近似 LRU 与 LFU 的内部机制，并最终给出一套从选型、配置到架构演进的实战策略。这不只是一份配置指南，更是一次深入 Redis 设计哲学的探索。
现象与问题背景
在一个典型的跨境电商系统中，我们使用 Redis 缓存商品详情、库存和汇率等热点数据。系统在常规运营下表现稳定，缓存命中率维持在 95% 以上。然而，在一次“黑五”大促预热活动中，运营部门通过后台批量扫码上架了数万个新品。几分钟后，监控系统开始告警：数据库主库 CPU 使用率飙升，API 延迟急剧增加，用户前端出现大量加载失败。经过紧急排查，发现 Redis 缓存命中率雪崩式地从 95% 跌至 20% 以下。
问题根源在于这次批量操作。后台任务遍历了大量商品，导致这些商品数据被一次性加载到 Redis 缓存中。由于我们配置的是默认的 LRU (Least Recently Used) 策略，这些“仅仅被访问一次”的数据污染了整个缓存，将真正需要被高频访问的“爆款”商品数据（如 iPhone、戴森吹风机）从内存中挤了出去。随后的用户流量涌入，请求的都是这些“爆款”，却无法在缓存中找到，导致大量请求穿透到后端的 MySQL 数据库，最终引发了连锁反应。
这个场景暴露了一个核心问题：当内存达到上限时，我们应该驱逐哪些数据？选择“最近最少使用”的，还是“访问频率最低”的？这个看似简单的配置选项背后，是深刻的数据结构、算法和业务场景的权衡。错误的策略选择，可能会让你的缓存系统在关键时刻形同虚设。
关键原理拆解
要理解 Redis 的淘汰策略，我们必须回到计算机科学的基础。缓存（Cache）技术的核心是利用程序的局部性原理（Principle of Locality）。该原理分为两个维度：
- 时间局部性（Temporal Locality）: 如果一个数据项被访问，那么它在不久的将来很可能再次被访问。这正是 LRU 算法的理论基础。
- 空间局部性（Spatial Locality）: 如果一个数据项被访问，那么与它地址相邻的数据项也很可能被访问。这在 CPU Cache Line 和磁盘预读中体现得更明显，对于 Redis 这种 Key-Value 存储，时间局部性是更核心的考量。
基于这些原理，学术界设计了多种经典的缓存替换算法，其中 LRU 和 LFU 是最广为人知的两种。
1. LRU (Least Recently Used)
LRU 的核心思想是：当缓存满时，优先淘汰最近最久未被使用的数据。它完美地诠释了时间局部性原理，认为“刚刚还被用到的，未来可能还会用到”。
经典数据结构实现：哈希表 + 双向链表 (Hash Map + Doubly Linked List)
这是一个教科书式的实现，也是面试中的高频考点。它通过两种数据结构的组合，实现了所有核心操作的 O(1) 时间复杂度。
- 哈希表 (HashMap): 用于存储 Key 到链表节点的映射。这使得我们可以在 O(1) 时间内定位到任意 Key 对应的节点。
- 双向链表 (Doubly Linked List): 用于维护数据的访问顺序。所有缓存数据都存在链表的节点中。我们将链表头部（Head）定义为“最新”端，尾部（Tail）定义为“最旧”端。
操作流程如下：
- 访问数据 (GET): 通过哈希表 O(1) 找到节点。将该节点从当前位置移动到链表头部。这个操作因为是双向链表，所以也是 O(1)。
- 插入新数据 (SET): 创建新节点，并将其放置在链表头部。同时在哈希表中建立映射。此为 O(1)。
- 淘汰数据 (EVICT): 当缓存满时，直接删除链表尾部的节点，并从哈希表中移除对应的 Key。此亦为 O(1)。
LRU 的致命弱点：正如我们开篇案例所示，LRU 无法处理“缓存污染”问题。一次性的、大规模的数据访问（如全表扫描、批量任务）会瞬间将热点数据全部替换出去，导致缓存失效。这是因为 LRU 只关心“最近访问”，而不关心“访问频率”。
2. LFU (Least Frequently Used)
LFU 的核心思想是：当缓存满时，优先淘汰访问频率最低的数据。如果频率相同，可以再结合 LRU，淘汰频率相同中最久未被访问的数据。它认为“被访问次数多的，才是真正有价值的”。
经典数据结构实现：两个哈希表 + N 个双向链表
LFU 的标准实现比 LRU 复杂得多。
- 第一个哈希表 (Key-Node Map): 存储 Key 到数据节点的映射，与 LRU 类似。
- 第二个哈希表 (Frequency-List Map): 存储访问频率（Frequency）到该频率下所有节点组成的双向链表的映射。
操作流程如下：
- 访问数据 (GET): 通过 Key-Node Map 找到节点。将其从当前频率的链表中移除，然后将其频率+1，再加入到新频率对应的链表中。如果新频率的链表不存在，则创建它。
- 插入新数据 (SET): 新数据的频率为 1。将其加入频率为 1 的链表中。
- 淘汰数据 (EVICT): 直接找到最小频率对应的链表，淘汰该链表尾部的节点。
LFU 的主要挑战：
- 实现复杂度高: 相比 LRU，LFU 的数据结构和操作逻辑都复杂得多，这在工程上意味着更多的代码和潜在的 bug。
- 空间开销大: 每个节点都需要额外的空间来存储频率计数器。
- “历史”问题: 一个曾经是热点但现在已不再被访问的数据，其频率计数可能非常高，导致它长时间无法被淘汰，反而挤占了新晋热点数据的空间。这个问题需要引入“频率衰减”（Aging/Decay）机制来解决。
Redis 的实现之道：近似算法的工程美学
讲完了理论，我们来看看 Redis 这位极客工程师是如何做的。如果 Redis 完全按照教科书的方式去实现 LRU/LFU，它将无法承受海量 Key 带来的元数据开销。试想一下，为每个 Key 维护额外的链表指针和频率计数器，在存储了数千万甚至上亿个 Key 的实例中，光是这些元数据就可能吃掉数百 MB 甚至数 GB 的内存。这违背了 Redis 作为高性能、内存效率高的 K-V 数据库的设计初衷。
因此，Redis 选择了一条更务实的道路：近似算法（Approximated Algorithm）。
在 Redis 的 `redisObject` 结构体中，有一个 24 bits 的字段 `lru`，它是一切魔法的关键所在。
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4;
unsigned lru:24; /* LRU time (relative to lru_clock) or LFU data */
int refcount;
void *ptr;
} robj;
1. 近似 LRU (Approximated LRU)
Redis 的 LRU 并不维护一个全局的链表，而是采用一种随机采样的方式。
工作流程：当需要进行内存淘汰时，Redis 会随机选取 `maxmemory-samples`（默认为 5）个 Key，然后在这 5 个 Key 中，淘汰 `lru` 字段值最小的那个（也就是空闲时间最长的那个）。`lru` 字段存储的是一个相对时间戳，记录了对象最后一次被访问时，全局时钟 `server.lruclock` 的值。
极客视角：这是一种典型的空间换时间、精确度换性能的思路。采样数量 `maxmemory-samples` 越大，结果越接近于理论上的 LRU，但消耗的 CPU 时间也越多。Redis 官方测试表明，当采样数为 10 时，其效果已经非常接近于严格的 LRU 实现。默认值 5 是一个在性能和效果之间取得的良好平衡。对于绝大多数场景，你根本不需要去动它。
2. 近似 LFU (Approximated LFU)
Redis 4.0 引入的 LFU 模式，同样是对 `lru` 字段的巧妙复用。这 24 bits 被分成了两部分：
- 16 bits: Last Decrement Time (ldt) – 用于记录上次计数器衰减的时间（以分钟为单位）。
- 8 bits: Logarithmic Counter (logc) – 用于记录访问频率，但它是一个对数增长的计数器。
工作流程：
- 访问 Key:
- 首先，根据当前时间和 ldt，计算需要衰减多少计数值。衰减的速率由参数 `lfu-decay-time` 控制（默认为 1，即每分钟衰减一次）。
- 然后，增加计数器。这个增加不是简单的 `++`，而是基于一个概率的对数增长。它会生成一个 0 到 1 之间的随机数 `r`，只有当 `r` 小于一个基于当前计数值计算出的概率 `p` 时，计数器才会加 1。这个 `p` 随着计数值的增大而减小，增长因子由 `lfu-log-factor` 控制。
- 淘汰 Key: 淘汰时，同样是采样 `maxmemory-samples` 个 Key，然后驱逐其中 `logc` 值最低的那个。
极客视角：这个设计简直是天才！
- 8 bit 对数计数器: 用区区 8 bit (0-255) 就模拟了巨大的访问频率范围。初始几次访问，计数器很快增长，但随着频率越来越高，再想增加就变得越来越难。这完美地模拟了热点数据的访问模式，同时节省了大量空间。
- 衰减机制: 通过 `ldt` 和 `lfu-decay-time`，巧妙地解决了 LFU 的“历史”问题。一个曾经的热点，如果长时间不被访问，它的计数值会随着时间慢慢衰减，最终给新的热点让路。
这套机制让 Redis 在不引入显著内存开销的前提下，实现了一个效果相当不错的、带衰减的 LFU 策略。
对抗与权衡：如何选择正确的策略？
理解了原理和实现，我们终于可以回答最初的问题：在我的业务场景中，到底该用哪个？
首先，你需要了解 Redis 提供的 8 种淘汰策略：
- noeviction: 默认策略。不淘汰任何数据，内存满时写入操作会报错。通常用于 Redis 不作为缓存，而作为数据库或消息队列的场景。
- allkeys-lru: 从所有 Key 中，使用近似 LRU 算法进行淘汰。当 Redis 完全用作缓存时，这通常是你的首选。
- volatile-lru: 从设置了过期时间（expire）的 Key 中，使用近似 LRU 算法进行淘汰。
- allkeys-lfu: 从所有 Key 中，使用近似 LFU 算法进行淘汰。Redis 4.0+ 提供。
- volatile-lfu: 从设置了过期时间的 Key 中，使用近似 LFU 算法进行淘汰。Redis 4.0+ 提供。
- allkeys-random: 从所有 Key 中随机淘汰。仅在你确信数据访问没有明显热点模式时使用（这种情况很少见）。
- volatile-random: 从设置了过期时间的 Key 中随机淘汰。
- volatile-ttl: 从设置了过期时间的 Key 中，淘汰剩余存活时间（TTL）最短的。
实战选型决策树
1. Redis 的角色是什么？
- 纯缓存：你的数据源在别处（如 MySQL、PostgreSQL），Redis 只是加速层。这种情况下，你应该选择 `allkeys-*` 族策略，因为任何数据都可以被牺牲。
- 混合存储：你同时用 Redis 做缓存和持久化存储（比如存储用户 session、购物车等）。这种场景下，必须使用 `volatile-*` 族策略，以保护那些没有设置过期时间的重要数据不被淘汰。这是一个非常常见的误区，错用 `allkeys-lru` 可能会导致你的持久化数据被当作缓存清掉！
2. 你的业务访问模式是怎样的？
- 符合典型时间局部性：比如新闻流、社交 Feed，用户更关心最新的内容。或者没有明显、固定的热点。`allkeys-lru` 或 `volatile-lru` 是一个安全、普适的选择。
- 存在稳定、高频的热点数据：比如我们案例中的电商爆款商品、配置信息、高频调用的基础服务数据。这类场景下数据的访问频率遵循幂律分布（Power-law distribution）。`allkeys-lfu` 或 `volatile-lfu` 是更优选择。 它可以有效防止批量任务造成的“缓存污染”，保护真正有价值的热点数据。
3. 关于 LFU 的精细化调优
如果你选择了 LFU，还有两个参数可以微调：
- `lfu-log-factor`: 控制计数器增长速度。值越大，计数器增长越慢。默认是 10。如果你希望更精确地反映高频访问，可以适当调大。
- `lfu-decay-time`: 控制衰减速度，单位是分钟。默认是 1。如果你的业务热点变化很快，可以把这个值调小，让它“遗忘”得更快。
极客警告：不要轻易调整这两个参数，除非你通过监控和压测，明确知道默认值不符合你的业务模型。99% 的情况下，默认值工作得很好。
架构演进与落地路径
一个成熟的技术团队，对于缓存策略的应用不是一次性的配置，而是一个持续演进和优化的过程。
第一阶段：基础建设与监控
无论选择何种策略，监控先行。你必须对你的 Redis 实例建立起码的监控体系，关注以下核心指标：
- `used_memory`: 已用内存，以及它距离 `maxmemory` 的距离。
- `evicted_keys`: 单位时间内被淘汰的 Key 的数量。如果这个值持续很高，说明你的内存严重不足，或者淘汰策略不合适。
- `keyspace_hits` 和 `keyspace_misses`: 用于计算缓存命中率。命中率的剧烈波动是问题的直接信号。
- `latest_fork_usec`: RDB/AOF fork 操作的耗时。高淘汰率可能伴随着频繁的写操作，进而影响后台持久化。
初始阶段，可以从 `volatile-lru` 开始，因为它最安全，不会误删你的持久化数据。通过监控观察系统行为。
第二阶段：角色分离与策略细化
当业务发展到一定规模，将所有数据混在一个 Redis 实例中是极其危险的架构。你应该进行服务拆分和 Redis 实例的物理隔离。
- 缓存专用实例：将纯缓存数据（如商品详情、用户信息）剥离到专门的 Redis 集群。这个集群可以大胆地配置 `maxmemory` 和 `allkeys-lru` 或 `allkeys-lfu` 策略，让它专注地做好缓存加速的工作。
- 业务数据实例：将需要持久化的数据（如分布式锁、计数器、Session）放在另一个 Redis 集群。这个集群应该配置为 `noeviction`，并配以更充足的内存和更高的数据可靠性保障（如开启 AOF）。
完成这个拆分后，你才能放心地在缓存实例上应用更激进的 `allkeys-*` 策略，并根据业务访问模式选择 LRU 还是 LFU。
第三阶段：多级缓存体系
对于金融交易、实时风控等极端场景，单一的分布式缓存可能无法满足全部需求。可以考虑构建多级缓存体系：
- L1 缓存：本地缓存（In-Process Cache）。在应用进程内部使用如 Guava Cache、Caffeine 等组件。这一层淘汰策略通常是基于容量和时间的混合策略（如 `expireAfterAccess`），响应速度在微秒级。
- L2 缓存：分布式缓存（Redis）。作为 L1 缓存的下一层，也是多进程间共享的缓存。在这里，LFU 策略的优势被进一步放大，因为能进入 L2 的数据，本身就是穿透了 L1 的“相对热点”，通过 LFU 能更精准地保留其中的“超级热点”。
在这样的架构下，缓存淘汰策略的选择变成了一个体系化的决策，每一层都根据其职责和访问特点选择最合适的策略，共同保障整个系统的性能和稳定性。
总而言之，Redis 的内存淘汰策略绝非一个简单的配置项。它背后是计算机科学的经典理论与顶尖工程实践的完美结合。作为架构师或资深工程师，我们需要做的，不仅仅是知道“有什么”，更要理解“为什么”，并基于对业务的深刻洞察和完善的数据监控，做出最适合当前阶段的架构决策。