Elasticsearch为了提升查询效率，提供了多种查询缓存，本文会对这些种类的缓存进行分析，包括缓存的使用场景、监控缓存的使用情况等。
01
Node Query Cache
基于Elasticsearch节点级别的缓存，由节点上所有的分片所共享，主要缓存查询的结果集。节点查询缓存实现了 LRU缓存清除策略，当缓存满了的时候，会清除最近最少使用的数据，为新数据腾出可用空间。
节点查询缓存只缓存使用了Filter过滤器查询到的结果，所以也被称为Filter Cache。
节点查询缓存数量和大小可以通过以下配置进行设置：
另外还可以指定是否缓存某个索引的数据，这通过索引的配置项index.queries.cache.enabled指定，值可以为true和false,默认为true，注意只可以在索引创建或者关闭的时候设置，无法动态设置。
Node Query Cache对于哪些数据哪些场景下会缓存有独立的缓存策略：
- TermQuery、MatchAllDocsQuery、MatchNoDocsQuery、BooleanQuery、DisjunctionMaxQuery都不会被缓存。
- MultiTermQuery、MultiTermQueryConstantScoreWrapper、TermInSetQuery、PointQuery 访问2次就会被缓存，其余的场景访问5次才会被缓存。
02
Shard Rquest Cache
基于索引分片级别的缓存。Elasticsearch的请求发到一个协调节点，协调节点通过转发请求到实际的数据节点获取数据，并且将数据进行组装以后返回响应。每一个节点的分片都会将请求本地结果缓存起来，当访问命中时直接从缓存获取，不需要通过读取磁盘的方式，速度会提升很多。
默认情况下，Shard Rquest Cache只缓存查询请求中size=0的请求结果，主要包括aggregations、hits.total和suggestions等。以下情况不会被缓存：
- 范围查询使用now，由于它是毫秒级别的，缓存下来没有意义
- 脚本查询中使用了 Math.random() 、Date()等函数的查询
- scroll查询
- 设置了 requestCache=false
- 查询类型不是 QUERY_THEN_FETCH
- 设置了profile
由于request cache基于分片，当新的segment写入的时候，原缓存的结果已经不是最新的数据，所以缓存会失效。
03
Fielddata Cache
Fielddata Cache包含了global ordinals和text字段field data的缓存， 主要用于对字段进行排序或聚合 ,它将所有的Field data聚合后的结果加载到内存中，以提供快速的访问。Fielddata Cache十分消耗内存，因为一般用于排序或者聚合的数据较大，需要有足够多的内存。
特别说明，从5.0 版本开始，text 字段默认关闭了 Fielddata 功能，当你对一个text类型的字段进行sort、aggregation时会提示以下异常：
如果要对text类型的字段开启fielddata，可以使用以下API：
Fielddata Cache的大小通过配置文件配置参数indices.fielddata.cache.size进行控制，可以是比例例如 10%,也可以是直接指定具体的值，例如2gb。
04
文件系统缓存
Elasticsearch底层是基于Lucene实现的，Lucene底层涉及大量的文件读写，实际上会使用到文件系统缓存,这点是很容易被忽略的，可以通过free命令查看系统buffer/cache使用情况。
05
indexing buffer
elasticsearch索引的过程不会直接写入磁盘，而是先写入一个缓冲区，定时刷新到磁盘或者等缓冲区满了以后刷新到磁盘，这个缓冲区就是 indexing buffer。索引缓冲区的大小通过配置indices.memory.index_buffer_size指定，默认值为10%.
另外还有两个参数用于直接指定最大和最小缓冲区的大小，分别是
indices.memory.min_index_buffer_size和
indices.memory.max_index_buffer_size,其中最小缓冲区默认为48mb。
06
elasticsearch缓存使用情况查询
Node Query Cache(queryCache)、Shard Rquest Cache(requestCache)、Fielddata Cache(fielddata)的使用情况可以通过Cat API进行查询。
