缓存代理的性能表现，很大程度上取决于缓存空间被填满之后如何选择淘汰对象。Apache HTTP Server 的 mod_cache 模块在处理缓存过期时主要以对象 TTL 和最大缓存目录大小为依据，策略相对固定；而 Apache Traffic Server（ATS）作为独立的代理缓存层，则提供了更灵活的内存缓存淘汰算法，其中就包括 LFU。LFU 全称 Least Frequently Used，即优先淘汰访问频率最低的条目。它不像 LRU 那样只关心最近有没有被访问，而是记录每个对象在生命周期内被命中的次数，因此对访问模式偏向长期稳定的业务有天然优势。

在具体实现中，LFU 并不是一个简单的计数器那么简单。如果让计数器无限增长，历史热点对象会永远占据缓存，即使业务热点已经迁移，旧对象仍然不会被淘汰；如果只记录固定时间窗口内的计数，又会引入额外的时间复杂度和内存开销。理解这些细节，才能在 Apache 代理缓存体系中把 LFU 用在正确的场景。

Apache代理缓存体系中的淘汰策略

Apache HTTP Server 的 mod_cache 与 mod_cache_disk 组合，通常将缓存内容写入磁盘。它的淘汰逻辑主要围绕过期时间、缓存目录大小上限和后台清理线程展开。管理员可以通过 CacheRoot、CacheDirLength、CacheDirLevels 等参数控制目录结构，通过 CacheMaxExpire、CacheDefaultExpire 控制对象生命周期，通过 htcacheclean 工具或 mod_cache_disk 的清理线程删除过期文件。这种机制严格来说并不是基于访问频率的淘汰算法，而是时间驱动的过期清理。当磁盘空间不足时，清理线程往往会从目录中按文件 mtime 顺序删除，访问热度不会被考虑在内。

相比之下，Apache Traffic Server 把这个环节分成了两级：内存缓存和磁盘缓存。内存缓存（RAM Cache）保存热点对象的元数据和部分内容，磁盘缓存保存完整对象。RAM Cache 的淘汰算法可以通过 records.config 文件中的 proxy.config.cache.ram_cache.algorithm 项来指定。可选项通常包括 0 表示 LRU，1 表示 LFU，2 表示 CLFUS（Combined LFU and LRU with Size 的缩写）。因此如果要讨论 Apache 代理缓存中的 LFU，更准确的落点应该是 ATS 的 RAM Cache。

ATS 之所以同时提供 LRU、LFU 和 CLFUS，是因为不同的内容分发场景对缓存对象的访问分布差异巨大。静态资源通常呈现明显的长尾分布，少量热门文件贡献大部分流量；而动态接口或个性化内容则可能呈现随机访问。在这些场景中，淘汰策略的选择会比单纯增加缓存容量更有效。

LFU的计数机制与常见实现变体

基础 LFU 会为每个缓存项维护一个访问计数器。对象每次被命中时，对应计数器加一；当缓存空间不足需要腾出空间时，遍历所有条目，找出计数器值最小的一个或多个对象进行淘汰。如果多个对象计数相同，通常会结合插入时间或上次访问时间作为次级排序依据，以保证淘汰行为可预测。以下伪代码展示了最简单 LFU 的淘汰过程。

function evict_lfu(cache):
    min_count = INF
    victim = null
    for obj in cache.items:
        if obj.access_count < min_count:
            min_count = obj.access_count
            victim = obj
        elif obj.access_count == min_count:
            if obj.last_access_time < victim.last_access_time:
                victim = obj
    cache.remove(victim)
    return victim

这种朴素实现有两个明显问题。第一个问题是新对象歧视：一个新加入缓存的对象访问计数为零或很低，即使它未来会成为热点，也可能在计数增长前就被淘汰。第二个问题是历史热点锁定：一个曾经被大量访问的对象，即使业务已经切换到新内容，它的高计数值仍然会让它长期留在缓存中，挤占新对象的空间。为了解决这两个问题，LFU 出现了多种变体，包括 LFU-Aging、Window-LFU 和 LFU*。LFU-Aging 会在对象访问次数超过一定阈值或经过一个周期后，对所有计数器做衰减，通常是将计数右移一位或除以一个衰减因子，从而让老对象的热度随时间降低。Window-LFU 只统计最近一段时间窗口内的访问次数，窗口外的访问不参与计数。LFU* 则在访问计数的基础上额外考虑对象大小，避免大对象因为一次访问就占用过多缓存。

在 ATS 的实现中，LFU 同样维护访问计数，但通过与 RAM Cache 的目录结构和锁机制配合，尽量避免全局遍历带来的性能开销。计数并不是无限增长的，ATS 会根据缓存容量和对象数量对计数做归一化或限幅，具体行为在不同版本中有所调整。理解这些变体设计有助于判断 LFU 是否适合自己的业务，而不是简单认为访问次数最少的对象就应该被淘汰。

在Apache Traffic Server中启用LFU

要在 ATS 中启用 LFU，需要修改 ATS 安装目录下的 etc/trafficserver/records.config 文件。找到 proxy.config.cache.ram_cache.algorithm 这一项，将其值设置为 1。该配置项是整数类型，不同取值对应的算法如下：0 表示 LRU，1 表示 LFU，2 表示 CLFUS。默认值在多数发行版中是 2，也就是 CLFUS。如果文件中没有这一项，可以手动添加，但要注意必须放在配置文件的正确作用域内。

# 编辑 records.config
proxy.config.cache.ram_cache.algorithm: 1

保存配置后，可以通过 traffic_ctl config reload 让 ATS 重新加载配置，而不需要完全重启服务。不过 RAM Cache 中已有的对象可能仍然沿用旧算法的计数状态，建议在业务低峰期执行，或直接重启 ATS 进程以确保全新的计数起点。执行以下命令可以确认当前生效的配置值。

traffic_ctl config get proxy.config.cache.ram_cache.algorithm

除了切换算法，还应当关注 RAM Cache 的容量配置。proxy.config.cache.ram_cache.size 决定了内存缓存的最大字节数。如果 RAM Cache 太小，LFU 计数器还没有积累出有意义的差异，对象就会被频繁淘汰，反而会降低命中率。通常建议根据热点数据总量来设置 RAM Cache 容量，例如热点对象总大小的 1.2 到 1.5 倍。此外，LFU 会为每个缓存对象额外保存计数信息，可以结合 proxy.config.cache.ram_cache.compress 等参数观察内存占用的变化。

LFU与LRU、CLFUS的对比及调优建议

LRU 的假设是最近访问过的对象未来也更容易被访问，因此它只关心访问时间，不关心访问次数。LRU 对访问模式的变化响应很快，新对象可以因为最近被访问而迅速获得保留地位。LFU 则相反，它看重累计访问次数，对长期稳定的热点更友好，但对新对象和访问模式切换不够敏感。CLFUS 是 ATS 默认算法，它在 LFU 的基础上加入 LRU 和对象大小的综合考量，试图兼顾频率和新鲜度。下面表格列出了三者在几个维度上的差异。

如果你的 Apache 代理缓存主要服务于静态资源、软件下载、镜像仓库或 CDN 边缘节点，访问分布通常比较稳定，LFU 能带来更明显的命中率提升。反之，如果缓存内容包含大量一次性请求、动态接口响应或用户个性化数据，LFU 可能因为新对象计数过低而频繁淘汰刚写入的内容，命中率反而下降。此时 LRU 或默认的 CLFUS 会更稳妥。

调优 LFU 时，不要只切换一个配置项就结束。建议先在测试环境或低流量节点上对比三个算法的命中率和字节命中率。ATS 提供了缓存统计接口，可以通过 traffic_ctl metric get 查看 proxy.process.cache 相关指标，重点关注 ram_cache.hits、ram_cache.misses 和 ram_cache.evictions。如果开启 LFU 后 evictions 仍然很高，说明 RAM Cache 容量不足或访问分布不适合 LFU；如果命中率改善明显，再逐步推广到更多节点。还可以根据业务热点周期，考虑在未来版本或自定义模块中引入计数衰减机制，让 LFU 在保持热点优势的同时降低旧数据锁定风险。