1. 缓存概述：Elasticsearch 缓存体系介绍
1.1 缓存的作用与价值
在 Elasticsearch 中，缓存是提升查询性能的核心手段。ES 集群的查询链路涉及磁盘读取、倒排索引合并、段合并等多个高延迟操作，缓存通过将热点数据或中间计算结果保存在内存中，大幅减少重复计算和 I/O 开销。
缓存的核心价值：
- 降低查询延迟：命中缓存时，响应时间可从几十毫秒降至微秒级。
- 减少磁盘 I/O：避免频繁读取 Lucene 段文件，延长磁盘寿命。
- 提升集群吞吐：相同硬件条件下，缓存命中率高的集群可支撑更多并发查询。
- 稳定查询性能：缓存吸收突发流量尖峰，防止查询抖动。
1.2 Elasticsearch 缓存体系全景
ES 的缓存体系分为三个主要层级：节点级缓存、分片级缓存和请求级缓存。每个层级服务于不同的查询阶段，共同构成多层缓存架构。
| 缓存层级 | 缓存名称 | 存储位置 | 生命周期 | 主要用途 |
|---|---|---|---|---|
| 节点级 | Node Query Cache (Filter Cache) | JVM Heap | 节点存活期间 | 缓存过滤查询（filter）的位集结果 |
| 分片级 | Shard Request Cache | JVM Heap | 分片存活期间，索引刷新时失效 | 缓存聚合、建议、命中数等请求结果 |
| 分片级 | Field Data Cache | JVM Heap | 字段被加载后常驻，LRU 淘汰 | 缓存字段的 doc_values 或 fielddata 用于排序/聚合 |
| 请求级 | Request Cache (Shard Level) | JVM Heap | 请求完成后保留，TTL 或手动清除 | 缓存整个搜索请求的完整响应 |
注意：ES 没有全局跨节点共享缓存。每个节点独立维护自己的缓存实例，因此缓存一致性主要发生在分片副本之间以及索引滚动更新时。
1.3 缓存一致性问题定义
缓存一致性（Cache Consistency）是指：当底层数据发生变化（写入、更新、删除）时，缓存中的数据与磁盘中持久化数据保持同步的程度。在 Elasticsearch 中，由于缓存分布在多个节点和分片上，且数据变更存在近实时（NRT）延迟，缓存一致性问题尤为突出。
核心矛盾：ES 的“近实时”特性（refresh_interval 默认 1s）意味着数据写入后不会立即对查询可见。缓存如果在这段时间内返回旧数据，就会产生“脏读”或“不一致”现象。缓存一致性优化的本质就是在性能和数据新鲜度之间寻找平衡点。
1.4 缓存一致性的典型场景
- 分片副本不一致：主分片写入新数据后，副本分片尚未同步完成，此时副本上的缓存仍返回旧数据。
- 索引滚动更新：reindex 或索引别名切换时，旧索引缓存未失效，新索引数据尚未被缓存。
- 字段映射变更：修改 mapping 后，Field Data Cache 中缓存的旧字段结构导致查询异常。
- 聚合结果过时：Shard Request Cache 缓存的聚合结果在数据更新后未及时失效。
1.5 缓存一致性的衡量指标
在实际运维中，我们通过以下指标评估缓存一致性状态：
| 指标名称 | 描述 | 理想值 | 监控方式 |
|---|---|---|---|
| 缓存命中率 | 查询命中缓存的比率 | > 80% | Node Stats API |
| 缓存失效率 | 单位时间内缓存被清除的次数 | < 5 次/分钟 | Cluster Stats API |
| 数据新鲜度延迟 | 数据写入到缓存可见的时间差 | < 1s | 自定义监控脚本 |
| 分片同步延迟 | 主分片与副本分片的数据差异时间 | < 500ms | Cat Shards API |
实践建议：在课程后续章节中，我们将深入讲解如何通过参数配置（如
indices.requests.cache.size、indices.fielddata.cache.size、index.refresh_interval）来平衡缓存性能与一致性，以及如何通过 _cache/clear API 和 search.max_open_files 等参数进行精细化调优。