本地英文版地址: ../en/shard-request-cache.html
当对一个或多个索引执行搜索请求时，每个相关的分片在本地执行搜索，并将其本地结果返回给协调节点(coordinating node)，协调节点再将这些分片级的结果组合成一个“全局的(global)”结果集。
分片级请求缓存模块在每个分片上缓存本地结果。 这使得经常使用的(也可能是大量的)搜索请求几乎可以立即返回结果。 请求缓存非常适合日志记录场景，在这种情况下，只有最新的索引会被主动更新 —— 旧索引的结果将直接从缓存中提供。
默认情况下，请求缓存将只缓存 size=0 的搜索请求的结果，因此它不会缓存hits，但会缓存 hits.total、aggregations 及 suggestions。
大多数使用 now 的查询(请参考日期计算(Date Math))都不能被缓存。
不缓存使用不确定的API调用的脚本查询，如 Math.random() 或 new Date() 。
缓存失效 (Cache invalidation)
缓存是智能的 - 它保持与 非缓存的搜索 相同的近实时承诺。
只要分片 刷新(refresh)，缓存的结果就会自动失效，但前提是分片中的数据确实发生了更改。 换句话说，你将总会从缓存中获得与未缓存的搜索请求相同的结果。
刷新(refresh)间隔越长，缓存的记录保持有效的时间就越长。 如果缓存满了，最近最少使用的缓存将被清除。
可以使用clear-cache API手动使缓存过期：
POST /kimchy,elasticsearch/_cache/clear?request=true
启用和禁用缓存
默认情况下，缓存是启用的，但在创建新索引时可以禁用，比如：
PUT /my_index
{
"settings": {
"index.requests.cache.enable": false
}
}
也可以使用 update-settings API 动态的对一个已有的索引启用或禁用缓存：
PUT /my_index/_settings
{ "index.requests.cache.enable": true }
为每一个请求启用和禁用缓存
请求参数 request_cache 可以为 每一个请求 启用会禁用缓存。
如果设置了这个请求参数，则会覆盖索引级别的设置：
GET /my_index/_search?request_cache=true
{
"size": 0,
"aggs": {
"popular_colors": {
"terms": {
"field": "colors"
}
}
}
}
即使在索引设置中开启了缓存，参数 size 大于0的请求也不会被缓存。
要对这种查询使用缓存，你需要使用这里提供的请求参数。
缓存的键 (cache key)
整个JSON主体都会被用来作为缓存的键。 这意味着如果JSON改变了——例如，如果键以不同的顺序输出——那么缓存键将不会被识别（即: 会被认为是一个新的键）。
大多数 JSON 库支持规范(canonical)模式，该模式确保 JSON 的键总是以相同的顺序书输出。这种规范模式可以在应用程序中使用，以确保请求总是以相同的方式序列化。
缓存设置
缓存在节点级别进行管理，默认内存占用最大值为堆的1%。这可以在 config/elasticsearch.yml 文件中使用以下命令进行更改：
indices.requests.cache.size: 2%
此外，您可以使用 indices.requests.cache.expire 设置为缓存的结果指定 TTL(Time to Live)，但没有理由这样做。
请记住，刷新(refresh) 索引时，过时的结果的缓存数据会自动失效。
提供此设置只是为了完整性考虑。
监控缓存使用情况
可以使用 indices-stats API 按索引查看缓存的大小(以字节为单位)和淘汰的数量：
GET /_stats/request_cache?human
或者使用 nodes-stats API 按节点查看：
GET /_nodes/stats/indices/request_cache?human