1.简介

Shard Request Cache 简称 Request Cache，他是分片级别的查询缓存，每个分片有自己的缓存。该缓存采用 LRU 机制，缓存的 key 是整个客户端请求，缓存内容为单个分片的查询结果。如果一个客户端请求被数据节点缓存了，下次查询的时候可以直接从缓存获取，无需对分片进行查询。

结构：

final Key key =  new Key(cacheEntity, reader.getReaderCacheHelper().getKey(), cacheKey);

cacheEntity， 主要是 shard信息，代表该缓存是哪个 shard上的查询结果。

readerCacheKey， 主要用于区分不同的 IndexReader。

cacheKey， 主要是整个客户端请求的请求体（source）和请求参数（preference、indexRoutings、requestCache等）。由于客户端请求信息直接序列化为二进制作为缓存 key 的一部分，所以客户端请求的 json 顺序，聚合名称等变化都会导致 cache 无法命中。

缓存的 value比较简单，就是将查询结果序列化之后的二进制数据。

2.用途

Request Cache 的主要作用是对聚合的缓存，聚合过程是实时计算，通常会消耗很多资源，缓存对聚合来说意义重大。

只有客户端查询请求中 size=0的情况下才会被缓存，其他不被缓存的条件还包括 scroll、设置了 profile属性，查询类型不是 QUERY_THEN_FETCH，以及设置了 requestCache=false等。另外一些存在不确定性的查询例如：范围查询带有now，由于它是毫秒级别的，缓存下来没有意义，类似的还有在脚本查询中使用了 Math.random() 等函数的查询也不会进行缓存。

该缓存使用LRU淘汰策略，内存无法被GC。

1）默认被开启，ES6.71版本。

2）RequestCache作用域为Node，在Node中的Shard共享这个Cache空间。。

3）RequestCache 是以查询的DSL整个串为key的，修改一个字符和顺序都需要重新生成Cache。

4）缓存失效是索引的refresh操作，也可以设置失效时间。

5）缓存的默认大小是JVM堆内存的1%，可以通过手动设置。

首先，我们按照 汽车的颜色color来划分桶

size： 查询条数，这里设置为0，因为我们不关心搜索到的数据，只关心聚合结果，提高效率

aggs：声明这是一个聚合查询，是aggregations的缩写

popular_colors：给这次聚合起一个名字，任意。

terms：划分桶的方式，这里是根据词条划分

field：划分桶的字段

3.设置

ES 默认情况下最多使用堆内存的 1% 用作 Request Cache，这是一个节点级别的配置：

indices.requests.cache.size

Request Cache 默认是开启的。你可以为某个索引动态启用或禁用缓存：

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

或者在查询请求级别通过 request_cache 参数来控制本次查询是否使用 cache，他会覆盖索引级别的设置。

GET /my-index/_search?request_cache=true