双十一来临，大家应该要对所有索引都做做健康检查了，由于最近压力上不去，所以盯上了Query Cache，由于之前Query Cache没有怎么注意，一直用的是默认配置，所以导致我发现cache的效率一直没上去。如下图，初步一看命中率50%+， Memory size 也没伤到预订大小，这里先不逐个字段解释，下面就以问答的形式来介绍一下这个query cache。
什么是Query Cache
简单来看可以这样理解，一个ES的查询会先被parse 成一系列的Lucene 的phrase，这些phrases 中的filter语句，如果对于查询条件是一样的时候，其实结果集是已定的，那么这些phrase 其实就是可以存放在一个地方当做cache用，这个就是 query cache。在ES里，这个是Node级别的配置，必须通过 yml配置里面去配置。
Query Cache 如何配置size 大小
如上图所示，如果默认的话，ES将会用10%的HEAP大小来存所有的Query Cache，这个配置必须通过yml文件来调整，但是从文章开头的截图可以出，我30G的HEAP最后只是使用了800MB的cache，为什么并不是配置的10%也就是3G呢？那就要看另外一个限制的配置
Query Cache配置最大个数
从截图中可以发现一个非常醒目的整数，这个就是另外一个限制条件，最大个数，这个同样是Node级别的，Query level，默认就是10000，就是说，不管size 有没有达到，数据到了10000，query cache也不会再增加了。
可以通过
indices.queries.cache.count=10000
的方式在yml配置
但是又有人会问，为什么我配置了10000，但是我还是会发现有超过10000的情况？比如：10123这样；
那就要看看下一个问题
Query Cache 的数据结构是怎么存的
简单来说ES的内部数据结构就是一个MAP，key就是一个具体的query，而value就是一个segment的 K/V, 而上面的10000的配置，只是Query 这个level，就是说真正的cache_size 是 Query size * segment nums， 如果你有2个segment，那么你看到的state数据很可能是cache_size:20000
为什么在文档没看到有这个cache.count的说明和配置？
看下图就明白了，其实如果看源代码的话你就知道怎么配了。。。
怎么判断哪些Query 会被cache
这个问题可以拆分成2个子问题：
- 这个Query 会还是不会被cache
- 这个Query请求多少次后会被cache
可以从UsageTrackingQueryCachingPolicy.java 这个类里面找答案；
其中第一个问题是
关于上面这几个Query 都不会被cache，对于第一个，TermQuery，官方的说法是从ES5开始，他们觉得从Term 的链表中去找数据已经足够快了，所以是不需要再去缓存了；其他的则是一些联合查询，或者嵌套查询，不应该把外层cache
对于第二个问题则可以看代码：
分两种，如果是Costly的query，则只需要访问2次就会被cache了。
为什么明明限制了cache.size,但是为什么dump出来发现cache的占用还是大于阈值
要回答这个问题就比较复杂了，简单一句话就是：要估算一个Query最终占用多少空间，其实是非常复杂的，如果对这个问题感兴趣，我建议必须真的一定务必要认真阅读一下下面这两个issue，你会受益匪浅的
query cache used memory calculating is not correct, which cause non-stopping old gc
那有办法避免cache过大OOM么？
目前来看如果你的查询真的非常复杂，真的很容易有cache 泄漏的话，那么最简单暴力的办法就是去减少cache.count,比如设置到1000（默认10000）
官方已经很贴心的帮你这么做了,如果你用的是下面以后的版本，那么你的默认cache.count是被设置成1000了
结尾
好了，如果你完成了这一系列的配置之后，剩下就是去观察你的GC频率，HEAP使用，还有query_cache的states了。
下面放出我的调优结果：
- Memory size已经可以接近配置的3G
- cache size 调成了30000
- 命中率提升到75% 以上
希望大家双十一性能爆表！还有cache 的问题欢迎来聊。
