分片请求缓存

当针对一个或多个索引运行搜索请求时，每个相关分片会在本地执行搜索，并将其本地结果返回给协调节点，协调节点再将这些分片级的结果组合成一个全局结果集。

分片级请求缓存模块会缓存每个分片上的本地结果。这使得频繁使用（且可能很重的）搜索请求能够几乎瞬间返回结果。请求缓存非常适合日志记录用例，在这些用例中，只有最新的索引在被积极更新 —— 来自较旧索引的结果将直接从缓存中提供。

您可以使用分片请求缓存设置在节点级别控制缓存的大小和过期时间。

该缓存很智能 —— 它保持了与未缓存搜索相同的近实时承诺。

每当分片刷新以获取对文档的更改时，或者当您更新映射时，缓存的结果会自动失效。换句话说，您从缓存中获得的结果将始终与未缓存的搜索请求获得的结果相同。

刷新间隔越长，即使文档发生了更改，缓存条目保持有效的时间也越长。如果缓存已满，最近最少使用的缓存键将被逐出。

可以使用 clear-cache API 手动使缓存过期

				POST /my-index-000001,my-index-000002/_cache/clear?request=true
		

缓存默认是启用的，但在创建新索引时可以按如下方式禁用

				PUT /my-index-000001
					{
  "settings": {
    "index.requests.cache.enable": false
  }
}
		

也可以使用 update-settings API 在现有索引上动态启用或禁用它

				PUT /my-index-000001/_settings
					{ "index.requests.cache.enable": true }
		

可以使用 request_cache 查询字符串参数在每个请求的基础上启用或禁用缓存。如果设置了该参数，它将覆盖索引级别的设置

				GET /my-index-000001/_search?request_cache=true
					{
  "size": 0,
  "aggs": {
    "popular_colors": {
      "terms": {
        "field": "colors"
      }
    }
  }
}
		

即使在索引设置中启用了请求缓存，size 大于 0 的请求也不会被缓存。要缓存这些请求，您需要使用此处详细说明的查询字符串参数。

整个 JSON 主体的哈希值被用作缓存键。这意味着如果 JSON 发生变化 —— 例如键以不同的顺序输出 —— 那么缓存键将无法被识别。

可以使用 indices-stats API 按索引查看缓存的大小（以字节为单位）和逐出次数

				GET /_stats/request_cache?human
		

或者使用 nodes-stats API 按节点查看

				GET /_nodes/stats/indices/request_cache?human