3、分片请求缓存（Shard Request Cache）：适用场景、参数配置与失效机制
分片请求缓存（Shard Request Cache）是 Elasticsearch 中针对非实时、重复性查询的二级缓存。它缓存的是每个分片级别的查询结果（hits.total、聚合桶、建议结果等），当相同查询再次到达同一分片且索引数据未发生变化时，直接返回缓存结果，避免重复执行查询和聚合计算。
3.1 适用场景与不适用场景
| 场景类型 | 典型用例 | 缓存效果 |
|---|---|---|
| 强烈推荐 | 仪表盘聚合查询、固定时间范围的趋势分析、日志统计报表 | 命中率极高，延迟降低 80% 以上 |
| 谨慎使用 | 包含 now 的日期范围查询、每次带不同随机参数的搜索 |
缓存几乎无法命中，浪费内存 |
| 不适用 | 关键字全文搜索、实时数据写入后的即时查询 | 缓存频繁失效，甚至产生负收益 |
最佳实践：分片请求缓存最适合读多写少、查询模式固定的场景。如果业务中索引每秒都有写入，缓存会在每次 refresh 后失效，此时建议关闭该缓存或设置极小的缓存大小。
3.2 核心参数配置：indices.requests.cache.size
该参数控制每个节点上所有分片请求缓存的总内存上限，属于节点级别的静态配置，必须在 elasticsearch.yml 中设置，且需要重启节点生效。
# elasticsearch.yml
indices.requests.cache.size: 5% # 占节点堆内存的百分比（默认 1%）
# 或使用绝对值
indices.requests.cache.size: 2gb| 配置方式 | 示例值 | 说明 |
|---|---|---|
| 百分比 | 5% |
按堆内存动态计算，推荐用于内存不固定的容器环境 |
| 绝对值 | 2gb |
固定上限，适合物理机或内存规划明确的集群 |
| 关闭缓存 | 0 |
完全禁用分片请求缓存，适用于实时写入场景 |
注意：缓存大小设置过大不会提升命中率，反而会挤占 JVM 堆内存，增加 GC 压力。建议从
2% 起步，通过监控 node_stats.indices.request_cache 指标（命中率、内存使用）逐步调整。
3.3 缓存失效机制
分片请求缓存的失效由 Elasticsearch 自动管理，主要触发条件如下：
- 索引写入（Index/Update/Delete）：当数据写入后，分片执行 refresh 操作（默认每秒一次），该分片的请求缓存全部清空。
- 分片迁移或重分配：分片从一个节点移动到另一个节点后，原节点上的缓存自动失效。
- 索引设置变更：修改 mapping、analysis 等索引级别设置会触发缓存失效。
- 手动清除：通过 API 主动清除指定索引或全部索引的缓存。
# 清除指定索引的请求缓存
POST /my_index/_cache/clear?request=true
# 清除集群所有缓存（谨慎使用）
POST /_cache/clear
关键理解：缓存失效粒度是整个分片，而非单条文档。只要分片内有一条文档发生变化，该分片的所有缓存条目都会被丢弃。因此，高写入频率的索引几乎无法从分片请求缓存中受益。
3.4 缓存生命周期与逐出策略
当缓存达到 indices.requests.cache.size 上限时，Elasticsearch 使用 LRU（最近最少使用） 策略逐出缓存条目。缓存条目没有 TTL（过期时间），完全依赖写入事件和 LRU 淘汰。
3.5 监控与调优建议
通过以下指标评估缓存效果：
request_cache.hit_count：缓存命中次数request_cache.miss_count：缓存未命中次数request_cache.evictions：LRU 逐出次数（过高说明缓存大小不足）request_cache.memory_size_in_bytes：当前缓存占用的内存
# 查看单个节点的请求缓存统计
GET /_nodes/stats/indices/request_cache
# 查看特定索引的缓存统计
GET /my_index/_stats/request_cache?human| 监控指标 | 健康范围 | 异常处理 |
|---|---|---|
| 命中率（hit/(hit+miss)） | > 80% | < 50% 时检查查询模式或关闭缓存 |
| 逐出率（evictions/秒） | < 10 | 持续高位时增大 indices.requests.cache.size |
| 缓存内存占比 | < 节点堆内存的 5% | 超过 10% 需评估是否缓存了过多无用查询 |
调优口诀：写入频繁关缓存，查询固定开缓存；命中率低查模式，逐出率高扩容量。