第2章 主动失效与被动失效：主动清理与惰性删除的架构对比
缓存失效策略是缓存系统的核心控制面，决定了过期数据何时被识别、标记和移除。从失效触发机制出发，所有策略可归为两类：主动失效（主动清理）与被动失效（惰性删除）。两者在系统边界、分层职责、数据流与控制流上存在本质差异，选型直接影响内存效率、请求延迟和运维复杂度。
2.1 核心概念定义
主动失效（主动清理）：缓存层通过独立的后台线程或定时器，周期性扫描全量或部分缓存条目，发现过期数据后立即删除。控制流完全位于缓存层内部，对外部请求路径无侵入。
被动失效（惰性删除）：缓存层在每次读请求访问缓存条目时，附带检查该条目的TTL/过期时间。若已过期则删除并返回空结果（或触发回源），否则正常返回数据。控制流嵌入在请求处理路径中。
| 对比维度 | 主动失效（主动清理） | 被动失效（惰性删除） |
|---|---|---|
| 触发机制 | 定时器 / 事件驱动 / 后台线程 | 每次读请求访问时触发 |
| 检查范围 | 全量或采样扫描 | 单条缓存项 |
| 执行时机 | 独立于请求路径 | 在请求路径中同步执行 |
| 内存释放时效 | 批次集中释放，有周期延迟 | 按需逐条释放，无延迟 |
| 对请求延迟的影响 | 无直接增加 | 增加一次过期判断（毫秒级） |
| 系统边界归属 | 缓存层内部自治 | 缓存层 + 应用层交互边界 |
2.2 架构对比：分层职责与系统边界
两种策略的架构本质区别在于控制流的归属层与数据流的触发源。主动清理将失效控制完全封装在缓存层内部，对应用层完全透明；惰性删除则将失效判断推迟到应用层访问缓存的那一刻，形成“访问时检测 → 按需失效 → 回源加载”的闭环。
分层职责对比
| 系统层 | 主动清理模式 | 惰性删除模式 |
|---|---|---|
| 应用层 | 无失效感知，只管读写 | 需处理缓存穿透（失效后回源） |
| 缓存层 | 负责扫描、判断、删除全流程 | 仅提供单条过期判断与删除能力 |
| 持久化层 | 被动提供回源数据 | 被动提供回源数据 |
架构选型要点：主动清理适合“缓存层自治、应用层无感”的场景，但需要额外的系统资源（CPU/线程）执行扫描任务；惰性删除轻量且无额外开销，但要求应用层具备回源和穿透处理能力。实际生产系统通常两者并用：以惰性删除为主体，辅以低频主动清理防止过期数据堆积。
2.3 适用场景分析
决策树可用于快速判断主导策略：
业务场景特征
├── 高并发、低延迟要求极严 → 惰性删除为主（避免定时扫描抖动）
├── 内存敏感、需严格控制占用 → 主动清理为主（及时释放过期条目）
├── 大量短TTL（秒级/分钟级） → 主动清理为主（防止过期数据堆积）
├── 读多写少、缓存命中率高 → 惰性删除为主（减少不必要扫描）
└── 混合负载 / 通用场景 → 惰性删除 + 低频主动清理（折衷方案）| 场景 | 推荐主导策略 | 关键理由 |
|---|---|---|
| 金融交易系统（低延迟） | 惰性删除 | 避免定时扫描引入延迟抖动 |
| 广告推荐（海量短TTL） | 主动清理 | 防止快速过期的无效条目占满内存 |
| 用户会话缓存 | 二者并用 | 惰性删除兜底 + 定时清理过期会话 |
| CDN边缘缓存 | 主动清理 | 批量失效控制，减少回源压力 |
| 微服务本地缓存 | 惰性删除 | 轻量无侵入，无需后台线程 |
2.4 优劣势评估矩阵
| 评估维度 | 主动清理 | 惰性删除 | 说明 |
|---|---|---|---|
| 内存效率 | ★★★★★ | ★★★☆☆ | 主动清理可集中释放过期条目，惰性删除可能产生临时堆积 |
| CPU开销 | ★★☆☆☆ | ★★★★★ | 主动清理需要周期性全量/采样扫描，惰性删除仅单条判断 |
| 请求延迟 | ★★★★★ | ★★★☆☆ | 主动清理不影响请求路径，惰性删除增加一次检查 |
| 实现复杂度 | ★★★☆☆ | ★★★★★ | 主动清理需要管理扫描线程与进度，惰性删除逻辑简单 |
| 数据一致性 | ★★★★☆ | ★★★★☆ | 两者都无法保证强一致，但副作用不同 |
| 运维监控 | ★★★☆☆ | ★★★★★ | 主动清理需要监控扫描效率与堆积量，惰性删除仅需关注命中率 |
2.5 数据流与控制流对比
下图展示了两种策略在数据流与控制流上的完整路径差异：左侧为主动清理，控制流完全在缓存层内部循环；右侧为惰性删除，控制流嵌入在每次请求路径中。
SVG 图解读：主动清理（左侧蓝）的控制流在缓存层内部闭环，不经过应用层；惰性删除（右侧橙）的控制流由请求触发，经过“请求 → 检查 → 删除 → 返回”完整路径。底部共享的缓存存储层与持久化层是两种策略的共同基础设施。
2.6 风险点与避坑
- 主动清理周期过短：扫描频率过高导致CPU飙升，尤其在缓存条目数超过千万级时。建议根据条目总量和TTL分布动态调整周期。
- 惰性删除堆积雪崩：大量短TTL条目同时过期且短时间内无访问，导致内存压力不释放，触发OOM风险。需配合主动清理兜底。
- 控制流干扰请求路径：惰性删除在请求路径中执行删除操作（尤其大值删除），可能阻塞请求线程。建议异步化删除或使用懒释放机制。
- 两种策略的互斥误解：并非二选一，实际生产系统通常是“惰性删除为主 + 主动清理为辅”的混合模式，两者互补而非替代。
典型踩坑案例：某广告系统仅使用惰性删除，大量秒级TTL的曝光记录堆积至内存阈值，触发Redis OOM 崩溃。事后增加每30秒一次的主动清理采样扫描，内存峰值下降62%，延迟无显著变化。
2.7 落地步骤
- 业务特征分析：统计缓存条目的TTL分布、读写比例、峰值QPS，确定主导策略方向。
- 缓存层配置：根据选型设置参数（如下示例），调整扫描周期或淘汰策略。
- 应用层适配：若以惰性删除为主，确保应用层正确处理缓存穿透（回源逻辑、空值缓存、布隆过滤器）。
- 监控部署：接入内存使用率、过期条目占比、扫描耗时、缓存命中率等指标。
- 灰度验证：先在低流量节点切换策略，对比延迟、内存、CPU变化，确认无负向影响后全量推广。
# Redis 配置示例：混合策略（惰性删除 + 主动清理）
maxmemory 6gb
maxmemory-policy volatile-ttl # 主动淘汰时优先移除TTL最近的条目
lazyfree-lazy-expire yes # 惰性删除使用异步线程释放内存
activedefrag yes # 主动碎片整理（辅助主动清理）
# 主动清理采样频率由内部算法自适应