3. 缓存失效机制与触发条件：Refresh、Flush、Merge 操作如何导致缓存失效，以及 Translog 的作用

在 Elasticsearch 中，缓存一致性并非自动保证，而是由一系列底层操作（Refresh、Flush、Merge）的触发条件与副作用共同决定。理解这些操作如何使缓存失效，以及 Translog 如何作为“安全网”保障数据不丢失，是构建可观测性与故障排查能力的基础。

3.1 核心操作概述与缓存失效全景

下表总结了三个关键操作对缓存的影响，以及 Translog 的补偿角色：

3.2 Refresh 操作：近实时搜索的代价

Refresh 操作将内存缓冲区（Buffer）中的数据写入一个新的段（Segment），并打开该段使其可被搜索。但此过程不保证数据已落盘，仅写入文件系统缓存（Page Cache）。

缓存失效机制

• Filter Cache 不受影响： Refresh 不改变已有段的过滤结果，因此 Filter Cache 中的条目仍然有效。
• Field Data Cache 不受影响： 新段加入后，Field Data 仅在首次对该段执行聚合或排序时才会加载，不会主动驱逐旧缓存。
• Request Cache 部分失效： 如果 Refresh 改变了索引的元数据（如新增字段映射），可能导致部分查询缓存失效，但通常影响较小。

3.3 Flush 操作：持久化与 Translog 的截断

Flush 操作执行一次完整的提交（commit）：将文件系统缓存中的数据 fsync 到磁盘，生成一个新的提交点，并清空 Translog。Flush 本身不直接导致 Filter Cache 或 Field Data Cache 失效，但它会触发以下连锁反应：

1. Translog 截断： 清空已提交的 Translog 文件，释放磁盘空间。
2. 段文件落盘： 所有未 fsync 的段数据写入磁盘，此时段变为“安全”状态。
3. 可能触发 Merge： Flush 后如果段数量超过阈值，Merge 进程会被唤醒，进而导致缓存失效。

Translog 的作用

Translog（事务日志）是 Elasticsearch 保证数据不丢失的核心机制。它记录所有尚未落盘的索引/删除操作，类似于数据库的 WAL（Write-Ahead Log）。

3.4 Merge 操作：缓存失效的“主犯”

Merge 操作将多个小段合并为一个大段，以减少段数量、提升查询性能。但合并过程直接且彻底地导致缓存失效，是缓存一致性问题的最大来源。

缓存失效的详细过程

1. 段被标记为删除： 被合并的旧段不再用于查询，但仍在内存中。
2. 新段创建并打开： 新段替换旧段，查询路由切换到新段。
3. 缓存条目失效：
   • Filter Cache： 所有基于旧段的位集（bitset）被逐出。
   • Field Data Cache： 所有基于旧段的字段值被逐出，新段需要重新加载。
   • Request Cache： 如果查询涉及被合并的段，缓存结果被标记为无效。
4. 缓存预热： 后续查询触发缓存重新加载，导致查询延迟突增。

3.5 缓存失效链路与 Translog 的补偿角色（SVG 图）

下图展示了从数据写入到缓存失效的完整链路，以及 Translog 如何作为安全网保障数据不丢失：

3.6 缓存失效的触发条件总结

以下列表归纳了各操作触发缓存失效的具体条件，便于在故障排查时快速定位：

• Refresh 触发缓存失效的条件：
  • 几乎不直接触发缓存失效，但频繁 Refresh 会导致段数量增长，间接加速 Merge。
  • 如果 Refresh 伴随映射更新，可能导致 Request Cache 部分失效。
• Flush 触发缓存失效的条件：
  • 不直接失效缓存，但 Flush 后如果段数量超过 index.merge.policy.segments_per_tier 阈值，会触发 Merge。
  • Flush 清空 Translog，释放内存，但不会影响 Filter/Field Data Cache。
• Merge 触发缓存失效的条件：
  • 任何 Merge 操作都会导致被合并段的缓存失效。
  • 大段合并（如 max_merged_segment 达到 5GB）会导致大量缓存被逐出。
  • 强制合并（Force Merge）会一次性失效所有相关段的缓存，影响最大。

3.7 可观测性视角：如何监控缓存失效

在链路追踪与故障排查中，以下指标是判断缓存失效是否由 Refresh/Flush/Merge 引起的直接依据：