4. 缓存一致性问题的根因分类：数据陈旧、缓存穿透、缓存雪崩、缓存与索引映射不一致

在 Elasticsearch 分布式集群中，缓存一致性故障并非单一诱因，而是由多个层面的根因交织而成。本章将四种核心根因——数据陈旧、缓存穿透、缓存雪崩、缓存与索引映射不一致——进行结构化拆解，帮助你在故障排查时快速定位问题源头。

4.1 数据陈旧 (Stale Data)

定义： 缓存中存储的文档版本早于 Lucene 段中最新的已提交数据，导致查询返回过时结果。

产生原因：

• refresh_interval 配置过大： 默认 1s，若调整为 30s 或更大，写入后查询可能读到旧缓存。
• Elasticsearch 节点级缓存未失效： shard request cache 或 filter cache 在索引更新后未自动清除。
• 外部缓存（如 Redis）TTL 过长： ES 数据已更新，但外部缓存未同步失效。
• 异步写入链路延迟： 写入 ES 成功但缓存更新任务尚未执行。

4.2 缓存穿透 (Cache Penetration)

定义： 查询请求直接绕过缓存层，每次请求都穿透到磁盘上的 Lucene 段，导致缓存形同虚设。

产生原因：

• 查询条件不命中缓存键： 每次查询使用不同的随机参数（如 ?timestamp=now），导致缓存无法复用。
• 缓存容量达到上限： ES 节点缓存使用 LRU 淘汰，热点数据被冷数据挤出。
• 缓存被手动或自动清空： 索引 setting 变更、节点重启、POST /_cache/clear 后未预热。
• 查询类型不支持缓存： 某些聚合或 script 查询默认不进入 request cache。

# 查看 request cache 命中率
GET /_stats/request_cache?human

# 查看节点级 query cache 使用情况
GET /_nodes/stats/indices/query_cache?human

# 检查缓存 evictions 指标
GET /_nodes/stats/indices/request_cache?human

缓存穿透的典型指标特征：

• request_cache.hit_count 极低，miss_count 极高。
• query_cache.evictions 持续增长，说明缓存被频繁淘汰。
• 磁盘 I/O 和 search 线程池队列深度同步上升。

4.3 缓存雪崩 (Cache Avalanche)

定义： 大量缓存键在同一时间或极短时间窗口内集中失效，导致请求全部穿透到后端 ES 集群，引发负载尖峰甚至服务不可用。

产生原因：

• 缓存统一过期时间： 所有缓存键设置相同的 TTL（如 3600s），到期时同时失效。
• 节点批量重启： 集群中多个节点同时重启，本地缓存全部清空。
• 索引重建或 mapping 更新： 导致关联缓存被批量失效。
• 外部缓存中间件故障： Redis 集群宕机或网络分区，所有请求回源到 ES。

4.4 缓存与索引映射不一致 (Mapping Mismatch)

定义： 缓存中存储的字段类型、分词方式或 doc_values 设置与当前索引 mapping 不一致，导致查询结果错误或聚合异常。

产生原因：

• 索引 mapping 动态更新： 新增字段或修改字段类型后，旧缓存未失效。
• 多索引别名切换： 查询指向新索引，但缓存仍使用旧索引的 mapping 结构。
• 跨集群搜索 (CCS) 映射差异： 不同集群对同一字段的定义不同，缓存无法对齐。
• 字段被标记为 "doc_values": false： 聚合查询无法使用缓存，但缓存仍保留旧映射信息。

映射不一致的典型表现：

• 聚合查询返回空 bucket 或错误类型异常。
• term 查询对 text 字段生效，但对 keyword 字段失效。
• 排序结果与预期不符，因为缓存中的 doc_values 结构与实际不匹配。

# 查看当前索引 mapping
GET /index/_mapping

# 查看缓存中字段的映射信息（需借助 profiling）
POST /index/_search
{
  "profile": true,
  "query": { "match_all": {} }
}

# 强制刷新缓存并重新预热
POST /index/_cache/clear
POST /index/_search?search_type=query_then_fetch
{
  "query": { "match": { "field_A": "test" } }
}

4.5 四类根因的快速对比矩阵