代理缓存是提升Web服务响应速度的常用手段，但很多运维人员发现一个现象：Apache重启之后，原本命中率高企的缓存突然全部失效，所有请求都回源到后端服务器，造成短暂的性能低谷。根本原因在于缓存元数据和索引默认保存在内存中，进程退出即丢失。要解决这个问题，就需要引入持久化机制，而持久化领域最经典的设计之一就是WAL（Write-Ahead Logging，预写式日志）。本文将把这两条线索结合起来，讲清楚Apache代理缓存的持久化实现思路，以及WAL日志在其中扮演的角色。
一、Apache代理缓存的存储模型与丢失问题
Apache实现代理缓存主要依赖mod_cache、mod_cache_disk或mod_cache_socache这几个模块。以磁盘缓存为例，响应体确实会写到磁盘上，但缓存条目的组织结构、头信息、过期时间等元数据，其查找索引在运行时构建于内存之中。这意味着虽然文件还在磁盘上，但重启后Apache需要重新扫描目录重建索引，大型缓存目录的扫描可能耗时数分钟，期间缓存基本不可用。
一个典型的磁盘缓存配置如下：
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
<IfModule mod_cache.c>
CacheEnable disk /
CacheRoot "/var/cache/apache2/proxy"
CacheDirLevels 2
CacheDirLength 1
CacheMaxFileSize 10000000
CachePersistOff Off
</IfModule>
配置中的CacheRoot指定缓存落盘目录，CacheDirLevels和CacheDirLength控制目录分层，避免单目录文件过多。需要注意的是，这种落盘只解决了响应体的持久化，元数据索引的重建成本依然存在。如果对重启后的秒级可用有要求，就需要在架构上引入外部存储，例如把缓存索引导入支持WAL的嵌入式数据库（如SQLite或LevelDB），由数据库负责持久化与恢复。
这种方案的思路是：Apache层只做缓存的读写决策，索引和元数据的存取全部交给后端存储引擎。存储引擎通过WAL日志保证事务提交后即使进程崩溃，数据也能完整恢复，重启时只需回放日志即可重建内存状态，速度远快于全量扫描目录。
二、WAL日志的核心原理：先写日志，再改数据
WAL的全称是Write-Ahead Logging，它的核心规则只有一条：对数据的任何修改，必须先把变更内容以追加方式写入日志文件，然后再去修改磁盘上的数据页。这条规则带来两个关键收益：一是日志写入是顺序IO，远快于数据页的随机IO；二是崩溃恢复时，只需从头扫描日志，重放尚未应用到数据文件的记录，即可恢复一致性状态。
对比另一种回滚日志方案，差异更明显。回滚日志记录的是修改前的旧值，用于出错时撤销操作；WAL记录的是修改后的新值，用于崩溃后重做操作。回滚日志要求先改数据再记日志以保证原子性，而WAL天生就把最脆弱的写日志环节放在最前面，一旦日志落盘成功，这次修改就被认为是已提交的，后续的数据页刷盘可以异步慢慢来。
以SQLite为例，启用WAL模式非常简单：
# 打开数据库后执行 PRAGMA journal_mode=WAL; PRAGMA synchronous=NORMAL; PRAGMA wal_autocheckpoint=1000;
journal_mode=WAL将数据库切换到WAL模式，之后所有写操作都会先写入-wal后缀的日志文件。synchronous=NORMAL表示日志写入后不强制立刻fsync，由checkpoint阶段统一保证持久性，吞吐量可以提升数倍，代价是极端断电时可能丢失最近几毫秒的事务。wal_autocheckpoint设置每写入1000个页就自动触发一次checkpoint，把WAL日志中的应用回数据主文件。
三、Checkpoint机制与WAL文件膨胀治理
WAL日志不能无限增长，必须周期性地把日志中已提交的修改真正应用到数据文件，然后截断或复用日志文件，这个过程称为checkpoint。checkpoint的性能特征决定了整个系统的写放大水平：执行时需要把WAL中的脏页逐个写回主数据文件，属于比较重的随机IO操作。
实际运维中最常见的两个问题都与checkpoint有关。第一个是WAL文件膨胀：如果存在一个长时间运行的事务持有旧快照，checkpoint就不能推进超过该事务的开始位置，WAL文件会持续增长，严重时占满磁盘。排查方法是检查活跃连接中是否有未提交的长事务，及时提交或终止。第二个是checkpoint阻塞写入：checkpoint期间新写入仍可追加到WAL尾部，一般不会阻塞，但如果checkpoint频率过高（比如每次事务都触发），吞吐会明显下降，需要调大checkpoint间隔或改用手动checkpoint策略。
对于Apache缓存索引这类读写都极其频繁的场景，推荐的做法是：开启WAL模式，synchronous设为NORMAL，设置合理的自动checkpoint阈值，并配置定时任务在业务低峰期执行PRAGMA wal_checkpoint(TRUNCATE)，主动回收WAL文件空间。同时要注意WAL文件与主数据库文件必须放在同一块磁盘上，跨文件系统移动WAL文件会导致数据库损坏。
四、在代理缓存架构中落地持久化的整体方案
综合来看，一套可用的持久化代理缓存架构分为三层。最上层是Apache的mod_cache，负责根据响应头判断是否缓存、何时过期；中间层是自定义的索引管理模块或外部守护进程，通过mod_rewrite或Lua钩子与存储引擎交互；最底层是支持WAL的存储引擎，保证元数据的崩溃安全和快速恢复。
部署时需要重点验证两个指标：一是重启恢复时间，即从Apache启动到缓存命中率恢复到正常水平的耗时，理想情况下应在秒级；二是写入延迟，引入持久化后每次缓存写入会多一次WAL追加，通常增加零点几毫秒，对代理场景基本无感，但要通过压测确认。此外，务必做好备份策略——WAL模式下备份不能简单复制主文件，必须使用.backup命令或保证复制时WAL文件一并包含，否则备份会缺失最近的提交记录。
总结一下，Apache代理缓存的持久化本质上是把易失的内存索引交给可靠的存储引擎管理，而WAL日志正是存储引擎实现高吞吐持久化的关键技术。理解了先写日志、再刷数据、周期checkpoint这三步，再面对缓存丢失、WAL膨胀、恢复缓慢等问题时，就能快速定位到具体环节并对症处理。
Apache代理缓存持久化WAL日志修改时间：2026-08-31 17:28:41