Apache HTTP Server 作为反向代理时，常通过 mod_proxy 将请求转发到后端应用服务器，并借助 mod_cache 及 mod_cache_disk 模块缓存响应内容。缓存机制可以显著降低后端负载，但当缓存条目过期后，默认的同步刷新方式可能导致多个并发请求同时回源，造成后端压力瞬间升高。理解这一过程并配置合理的刷新策略，是保证代理服务稳定性的关键。
一、缓存过期后的默认同步刷新行为
在 Apache 中启用代理缓存通常需要同时加载 mod_proxy、mod_cache 和 mod_cache_disk 模块，并使用 CacheEnable 指令指定缓存类型和路径。例如，针对反向代理的响应可以配置如下。
LoadModule cache_module modules/mod_cache.so LoadModule cache_disk_module modules/mod_cache_disk.so LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so CacheRoot /var/cache/apache2/mod_cache_disk CacheEnable disk / CacheDefaultExpire 3600 CacheMaxExpire 86400
上述配置将根路径下的所有响应缓存到磁盘，默认过期时间为一小时。当某个 URL 的缓存条目达到过期时间后，Apache 会将其视为失效。此时如果有新请求到达，mod_cache 需要向后端重新获取响应并更新缓存。问题在于，如果同一 URL 在过期瞬间收到大量并发请求，而 CacheLock 又处于关闭状态（默认值 off），那么这些请求都会尝试回源。后端应用会同时收到多份相同的请求，这就是典型的缓存击穿。
缓存击穿的影响取决于后端处理能力和请求并发量。对于计算密集或数据库查询较慢的页面，几个并发请求就可能让后端响应时间显著增加，进而导致代理层请求排队，形成雪崩效应。因此，理解默认行为后，下一步需要利用 Apache 提供的锁机制来减少这种冲击。
二、用 CacheLock 实现过期后的串行化刷新
Apache mod_cache 提供 CacheLock 指令，用于在缓存条目过期后的重新验证过程中加锁。启用 CacheLock 后，当多个请求同时命中同一个已过期的缓存条目时，只有第一个请求会获得锁并向后端发起请求，其余请求会等待锁释放，或者等待指定的时间后返回陈旧缓存。这个机制可以将同步刷新中的并发回源改为串行回源，大幅降低后端瞬时压力。
配置 CacheLock 时需要同时指定 CacheLockPath 和 CacheLockMaxAge。CacheLockPath 用于存放锁文件，需要保证 Apache 运行用户具有写权限。CacheLockMaxAge 定义其他请求等待锁释放的最长时间，单位为秒。一个典型的配置如下。
CacheLock on CacheLockPath /var/lock/apache2/mod_cache_disk CacheLockMaxAge 5
假设一个缓存条目过期后，有 100 个并发请求同时到达。启用 CacheLock 后，第一个请求获得锁并回源，其余 99 个请求会等待最多 5 秒。如果回源在 5 秒内完成并更新缓存，则这 99 个请求可以直接使用新缓存；如果回源超过 5 秒，等待的请求可能返回 503 错误或继续使用旧缓存，具体取决于其他指令如 CacheStaleOnError 的配置。由此可见，CacheLock 并非真正的异步刷新，它只是把并发回源变成了排队等待，用户请求仍然可能被阻塞。
为了在锁等待期间提供更好的用户体验，可以结合 CacheStaleOnError 指令。当启用该指令后，如果后端返回错误状态码，Apache 会使用已过期的缓存内容作为响应，而不是直接返回错误。这样可以避免因后端短暂故障导致用户看到错误页面，但需要注意该行为可能掩盖真实问题。示例配置如下。
CacheLock on CacheLockPath /var/lock/apache2/mod_cache_disk CacheLockMaxAge 5 CacheStaleOnError on
另外，CacheLock 的锁文件会保留在 CacheLockPath 目录中。正常情况下，Apache 会自动清理失效的锁，但在某些异常情况下可能留下残留文件。管理员应定期检查该目录，避免大量锁文件占用磁盘空间。
三、结合外部定时任务实现真正的异步预热刷新
CacheLock 只能缓解缓存过期瞬间的并发回源，并不能完全消除用户请求的等待。要实现真正的异步刷新，即在缓存过期前由后台任务完成更新，需要引入外部定时机制。常见做法是利用系统 cron 或类似的计划任务，在业务低峰期或缓存即将过期时，主动请求热点 URL，让 Apache 提前更新缓存。这样当真实用户访问时，缓存通常已经处于新鲜状态，根本不会触发过期后的同步刷新。
假设后端有一个需要频繁访问的商品列表接口，缓存有效期设置为 3600 秒。可以在缓存过期前 10 分钟使用脚本批量预热。例如，使用 curl 请求该接口，并丢弃输出结果。下面是一个简单的 Shell 脚本示例。
#!/bin/bash
# 预热热门商品列表地址
URLS=(
"http://127.0.0.1/api/products?page=1"
"http://127.0.0.1/api/products?page=2"
"http://127.0.0.1/api/products?page=3"
)
for url in "${URLS[@]}"; do
curl -s -o /dev/null "$url"
done
将该脚本添加到 crontab 中，每 50 分钟执行一次，即可在缓存过期前主动刷新。比如：
*/50 * * * * /usr/local/bin/warm_cache.sh > /dev/null 2>&1
这种外部预热方案的优势在于完全异步：用户请求不需要等待缓存重建，因为重建任务已经在后台提前完成。但它也有局限性，例如需要维护预热 URL 列表，且对于动态参数较多的接口很难全面覆盖。因此，在实际生产环境中，通常将 CacheLock 与外部预热结合使用：CacheLock 作为兜底防止突发击穿，外部定时任务则保证绝大多数请求能够命中新鲜缓存。
此外，还可以使用 Apache 的 mod_proxy 配合后端缓存控制头来精细化缓存行为。例如，后端响应中设置 Cache-Control: max-age=3600，Apache 会遵循该值管理过期时间。预热脚本可以通过设置请求头模拟用户访问，确保缓存键一致。需要注意的是，如果缓存键包含 Cookie 或协商头，预热请求也必须携带相同的头信息，否则可能生成无效的缓存副本。
四、配置调优与常见陷阱
在配置 Apache 代理缓存异步刷新时，有几个参数和细节值得深入调优。首先是 CacheIgnoreCacheControl 指令。如果后端响应带有 no-cache 或 no-store 头，默认情况下 mod_cache 不会缓存这些响应。某些应用框架可能对所有响应统一发送 no-cache，导致代理缓存完全失效。此时可以在 Apache 中设置 CacheIgnoreCacheControl on 来忽略这些头，但需要谨慎评估后端内容是否确实适合缓存。示例配置：
CacheIgnoreCacheControl on CacheIgnoreNoLastMod on
其次是缓存存储的维护。mod_cache_disk 使用磁盘存储缓存条目，长时间运行后可能产生大量文件。Apache 提供了 htcacheclean 工具来清理缓存，支持定期删除过期条目或限制缓存总大小。例如，每小时执行一次清理，限制缓存大小为 2GB：
htcacheclean -d30 -p/var/cache/apache2/mod_cache_disk -l2048M
第三，如果使用 CacheLock，需要确保 CacheLockPath 目录与缓存目录不在同一个文件系统上可能导致锁竞争性能下降，但通常影响不大。更重要的是，CacheLockMaxAge 不宜设置过大，否则等待请求会长时间占用连接资源。一般建议设置在 3 到 10 秒之间，结合后端响应时间确定。
最后，生产环境中建议监控缓存命中率。可以通过 Apache 的 mod_status 查看缓存相关统计，或者结合日志分析。当命中率下降而回源请求增加时，可能是缓存过期策略过于激进或预热任务失败，需要及时调整。
通过合理组合 CacheLock 与外部异步预热机制，Apache 代理缓存可以在过期后平滑过渡，既避免后端压力突增，又能保证用户请求的快速响应。