Apache 的 mod_cache 模块在代理场景下承担响应缓存职责，它并不会把上游返回的原始字节流原样写入磁盘，而是先通过一套序列化逻辑把响应状态行、头字段和正文内容封装为内部结构。这个序列化过程决定了缓存文件在被读取时需要经历多少解析步骤，也直接影响缓存命中后的响应速度以及缓存目录的可维护性。因此，理解并选择合适的序列化格式，是配置 Apache 反向代理缓存时容易忽略却至关重要的环节。
从实现角度看，mod_cache 将缓存对象拆分为头部文件和正文文件，头部文件记录元数据与响应头，正文文件保存实际内容。不同格式的序列化策略会改变头部文件中字段的编码方式、长度标识和校验信息的存放位置。下面从格式本身、性能差异和选择依据三个层面展开。
一、序列化格式在 Apache 代理缓存中的角色
代理缓存的核心动作是把一次上游响应保存下来，后续相同的请求直接由缓存响应，避免重复回源。保存过程涉及两个阶段：序列化和持久化。序列化负责把内存中的响应对象转换成可存储的字节序列，持久化则把这些字节写入文件系统或共享内存。Apache 的 mod_cache_disk 使用基于磁盘的缓存后端，其序列化格式默认采用二进制结构，头部信息以固定字节长度、类型标记和长度前缀的方式紧凑排列。这种格式的优势是解析时无需进行复杂的文本扫描，模块可以直接按照偏移量读取字段，CPU 开销较低。
然而，二进制格式也带来可读性差的问题。当缓存内容出现异常或需要手动检查某个对象的响应头时，直接打开缓存头文件看到的往往是一堆不可打印字符。相比之下，如果序列化时采用文本格式，例如用换行分隔的键值对表示响应头，虽然会增加存储体积，但运维人员可以轻松用 less 或 grep 查看缓存内容。Apache 官方模块并没有提供直接切换文本格式的配置指令，但了解序列化格式的差异有助于评估是否需要在 Apache 之外引入自定义缓存层，或者在修改模块源码时做出合理决策。
此外，序列化格式还影响缓存失效和清理逻辑。二进制格式需要在文件中写入校验和、对象大小和过期时间等元数据，这些字段的顺序和长度一旦变化，旧版本的 Apache 就可能无法识别新格式。因此，在执行 Apache 升级或迁移缓存目录时，序列化格式的兼容性是一个重要考量。
二、二进制格式与文本格式的性能差异
为了更直观地比较两种序列化格式，可以从缓存写入和读取两条路径观察。二进制格式在写入时通常直接拷贝结构体或按照紧凑协议编码，不需要把数字转换成十进制字符串，也不需要为每个字段添加分隔符。以缓存响应头为例，二进制格式可以用两个字节表示字段名长度，再用两个字节表示字段值长度，随后按字节写入内容；文本格式则需要写入字段名、冒号、空格、字段值以及换行符。对于大量小对象缓存，文本格式增加的字节数和解析时间会随请求量线性放大。
读取阶段的差距更加明显。二进制格式可以直接将文件映射到内存，通过偏移量读取固定位置的字段，解析成本几乎可以忽略。文本格式则需要逐字节扫描换行符，再根据冒号拆分键值，必要时还要处理空格和大小写归一化。在缓存命中率较高、每秒需要从磁盘缓存响应数百个请求的代理场景中，二进制格式的 CPU 和 IO 优势会转化为更低的延迟和更高的吞吐量。
下面的配置块展示了 Apache 启用磁盘缓存的标准方式，缓存文件默认采用二进制结构：
<VirtualHost *:80>
ServerName www.ippipp.com
ProxyPass / http://backend/
ProxyPassReverse / http://backend/
CacheEnable disk /
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDirLevels 2
CacheDirLength 1
</VirtualHost>
可以通过 xxd 查看缓存头文件的二进制内容，了解序列化后的实际布局。例如执行 xxd -l 128 /var/cache/apache2/mod_cache_disk/.../header，能看到版本标识、状态码和头字段长度等数据。文本格式则更适合用 grep 和 awk 进行分析，但 Apache 默认不会生成文本缓存，因此如果团队强烈依赖文本可读性，需要评估自定义模块或使用支持文本缓存的替代方案。
三、选择序列化格式的核心考量
序列化格式的选择不是非黑即白的二进制或文本，实际决策中可以从以下维度评估。首先是对象大小分布。如果代理缓存主要服务于 REST API 或小图片，对象平均体积在几 KB 到几十 KB，文本格式增加的元数据开销占比会更高，二进制格式更能节省空间。如果缓存对象大多是 HTML 页面或文档，单个对象体积较大，文本格式多出的几十到上百字节相对影响较小，此时可读性的收益可能超过存储成本。
其次是运维排障频率。二进制格式虽然解析快，但出现问题时定位难度高。例如需要确认某个 URL 的缓存是否携带了错误的响应头，二进制缓存需要借助专门工具或编写解析程序；文本格式则可以直接查看。对于业务迭代频繁、需要经常排查缓存不一致问题的团队，牺牲少量性能换取可读性是值得的。反之，如果缓存层稳定运行、极少需要人工介入，二进制格式的紧凑和高效是更合理的选择。
第三是 Apache 版本升级和迁移计划。Apache 的二进制缓存头结构理论上会保持向后兼容，但并不能保证所有小版本之间完全一致。如果计划在短时间内多次升级 Apache，建议在升级前清理缓存目录或做好缓存重建准备。文本格式虽然也可能变化，但由于其结构简单，解析器更容易兼容不同版本。在企业环境中，可以将缓存目录视为可丢弃的临时数据，通过 CDN 或独立的缓存服务器统一管理，从而降低序列化格式兼容性带来的风险。
四、验证与调优序列化行为
无论最终选择哪种格式，都需要在测试环境中验证序列化行为是否满足预期。验证可以从缓存文件大小、命中率和响应时间三个指标入手。使用 ab 或 wrk 对反向代理进行压测，分别统计冷缓存和热缓存下的延迟分布。二进制格式的优势在热缓存场景下表现最明显，因为此时请求基本不经过上游，响应时间接近磁盘读取加反序列化开销。文本格式则可能在高并发下因为解析消耗而出现 CPU 使用率上升。
配置层面，Apache 的 mod_cache_disk 提供了 CacheDirLevels 和 CacheDirLength 两个指令用于控制缓存目录的层级和名称长度。合理的取值可以减少单个目录下的文件数量，降低文件系统查找开销。例如 CacheDirLevels 2 和 CacheDirLength 1 表示两级子目录，每级目录名长度为 1 个字符。这虽然不直接改变序列化格式，但会影响缓存文件的组织方式和 IO 性能。
如果希望进一步优化序列化和反序列化速度，可以考虑将缓存后端从磁盘切换到共享对象缓存，使用 mod_cache_socache 搭配 CacheSocache memcache 或 CacheSocache shmcb。共享对象缓存通常采用内存友好的数据结构，序列化格式会针对内存访问模式优化。不过这种方式会牺牲缓存持久性，重启后缓存丢失。因此，适合对缓存冷启动不敏感、但需要极高热缓存吞吐的场景。
最后，序列化格式的选择需要与整体架构匹配。如果在 Apache 之前已经部署了 Varnish 或 Nginx 缓存，Apache 的磁盘缓存可能只是兜底或局部使用，此时格式选择的优先级会降低。反之，如果 Apache 直接面向公网承担主要缓存职责，那么二进制格式的紧凑性、文本格式的可读性以及共享对象缓存的高性能，都需要结合具体流量特征做出取舍。
Apache代理缓存序列化格式磁盘缓存修改时间：2026-08-20 01:56:25