3. 模板引擎缓存机制：模板编译缓存、片段缓存、数据缓存、缓存键设计模式

模板引擎缓存是 Web 应用中承载页面渲染性能的核心设施。在 Redis 集群故障场景下，模板缓存一旦失效，大量请求将直接穿透到后端编译与数据源，导致响应时间从毫秒级飙升到秒级，甚至引发级联雪崩。本章从缓存分层、键设计、失效策略三个维度，系统梳理模板引擎的缓存体系。

3.1 三层缓存架构

现代模板引擎（如 Jinja2、Thymeleaf、Handlebars、Velocity）通常将缓存划分为三个逻辑层次，每一层解决不同粒度的复用问题：

3.2 模板编译缓存

模板编译缓存存储的是模板文件解析后的中间表示（AST、指令集或字节码）。编译过程通常涉及词法分析、语法分析和优化，是 CPU 密集型操作。在 Redis 集群故障后，如果编译缓存丢失，每个请求都需要重新编译模板，CPU 会瞬间打满。

3.2.1 缓存键设计

模板编译缓存的键必须唯一标识一个模板版本。推荐采用 复合键 模式：

// 模板编译缓存键格式
template:compile:{template_name}:{locale}:{theme}:{file_hash}

// 示例
template:compile:product_detail:zh_CN:dark:v3a2f8c1e

// 字段说明
// template_name  : 模板逻辑名称，如 product_detail
// locale         : 语言区域，如 zh_CN、en_US
// theme          : 主题标识，如 dark、light
// file_hash      : 模板文件内容的 SHA256 前缀（8 位）

3.2.2 失效策略

• 文件变更驱动：监听模板文件系统的 inotify / fsnotify 事件，文件修改后立即删除对应编译缓存。
• 版本号兜底：在应用启动时生成全局模板版本号，每次部署递增；Redis 集群恢复后，版本号不匹配的编译缓存自动失效。
• 禁止 TTL：编译缓存原则上不设 TTL，避免运行时突然失效导致全站编译风暴。

3.3 片段缓存

片段缓存存储的是模板中某个区块渲染后的 HTML 输出。它是三层缓存中 性价比最高 的一层——既能大幅减少渲染时间，又不像数据缓存那样需要处理复杂的失效依赖。

3.3.1 典型使用场景

3.3.2 缓存键设计

// 片段缓存键格式
template:fragment:{template_name}:{block_name}:{locale}:{params_hash}

// 示例：商品详情页的推荐列表片段
template:fragment:product_detail:recommend_list:zh_CN:a1b2c3d4

// params_hash 包含：用户等级、设备类型、分页参数等影响片段内容的变量

3.4 数据缓存

数据缓存位于三层的最底层，缓存的是模板渲染所需的原始数据——数据库查询结果、RPC 响应、配置中心值等。它是整个缓存体系的 基石，Redis 集群故障后，数据缓存的重建速度和正确性直接决定系统恢复时间。

3.4.1 缓存键设计模式

数据缓存键设计遵循 领域驱动 + 防冲突 原则，常见模式如下：

3.4.2 缓存键设计最佳实践

• 命名空间前置：所有键以 data: 开头，避免与编译缓存、片段缓存或其他业务缓存冲突。
• 实体名使用单数：统一用 product 而非 products，减少命名不一致导致的缓存穿透。
• 参数哈希化：对于多条件查询，将参数排序后计算 MD5 或 SHA256 前缀，避免键过长。
• 版本号嵌入：在键末尾附加数据版本号（如时间戳或递增序列），支持优雅的缓存预热。

// 完整的数据缓存键示例（带版本号）
data:product:10086:v20240501

// 查询缓存键（参数哈希）
data:product:query:category=electronics&sort=price_asc&page=1 → md5 → a1b2c3d4
最终键：data:product:query:a1b2c3d4

3.5 缓存键设计模式总结

3.6 集群故障后的缓存恢复优先级

当 Redis 集群从故障中恢复时，三层缓存不能同时重建——必须按照 依赖顺序 逐层恢复，否则会导致缓存穿透叠加：

1. 第一优先：数据缓存——从数据库或上游服务回填最热门的 20% 数据（遵循二八原则），保障核心页面的数据可用。
2. 第二优先：片段缓存——依赖数据缓存重建后，触发片段缓存的异步渲染和回写。
3. 第三优先：编译缓存——编译缓存由请求按需重建，无需主动预热；但需确保编译缓存不设 TTL，避免重建后再次失效。