标签：垃圾 频繁 调整 查询 影响 频率 lru 变化 注意
sor缓存
虽然solr的检索速度很快，但是当搜索服务的请求变得非常复杂的时候，我们还是会发现搜索会出现一些性能上的问题。其实很多用户的请求很有很多相似的地方，
比如（一）：它们可能是不同用户的同一个请求,或者这个用户仅仅是进行了翻页的操作;（二）：用户的过滤条件会有重合的地方，比如它们在同一个类目下进行了不同的查询；
针对这两个问题，其实我们可以通过设置solr的缓存来使查询速度变快从而提高性能。
搜索器：
在这里就不对搜索器进行很细致的介绍了，因为本文档不是主要介绍搜索器的，而搜索器的一些操作可能会用到缓存且对缓存造成影响，在这提一下。
1.当你在对solr进行一次硬提交（普通提交）的时候，你可以选择打开搜索器或者不打开，如果不打开可能会导致搜索不可见，因为搜索器存的只是索引的只读视图，当你对索引改变时，需要重新启动一个搜索器来重新加载只读视图。而一个新的搜索器的加载，会导致缓存的失效，导致那段时间用户的体验很差。
2.当你进行软提交的时候cache（filterCache、queryResultCache、fieldvaluecache ）都会失效，如果进行一个很频繁的软提交，那么缓存几乎是不可用的
3.如果你打开了opensearch为true那么你可以选择对搜索器进行预热。
这里有一个链接很好地讲了软提交和硬提交https://hacpai.com/article/1489704451481?m=0。
缓存大小：
从缓存大小来说，我们不能把缓存设置的太大，否则它会消耗jvm的大部分内存。solr能够将所有的缓存都保存在内存中，不会溢出到硬盘上，solr为了控制缓存的大小要求每个缓存都要配置它们的上限。当数量达到上限时，solr将采用LRU最久未使用置换法或LFU最近最少使用置换法回收一部分空间。
LRU：当缓存达到上限且需要添加新对象时，solr将会置换缓存中最久未被请求过的对象。
LFU：该方法根据缓存对象被请求频率的高低决定缓存对象被回收的次序。（过滤器缓存是使用这个的好地方）
注意：一般我们会有一个误区，就是如果我们内存足够，缓存应该设置得越大越好。其实不然，因为一旦缓存失效，那么JVM需要进行大量的垃圾回收工作，如果不对缓存做合适的调整那么可能会导致JVM长时间在做垃圾回收工作，而暂停服务。
solr的cache类型：
（1）filterCache过滤器缓存：这个缓存主要是针对fq进行的。通常用户会在一个固定的业务场景下进行不同的查询，而启用这个缓存会大大地提高搜索性能。
（2）queryResultCache查询结果缓存：需要满足query、filterquery sortFiled一致才行。如果多次执行一个查询，其实看到的是缓存取出的结果，并不是去索引的结果。对要耗费大量计算资源的查询来说，这是一种比较高效的解决方式。
这里提到一点，我们可以去设置查询结果窗口大小，比如我们每页展示20个商品，如果用户大多数情况下去浏览第一页第二页那么我们可以把queryResultWindowSize设置为40，这样就可以避免用户查看第二页时再次执行查询请求。（这个可以通过跑数据来决定我们要设置的值）
（3）documentCache文档缓存：里面存储了文档的内容，如果索引更新的比较快，结果文档也常在变化，那么文档缓存可能会把资源耗费在对应用程序性能无益的地方。但是如果索引更新频率很低，那么文档缓存可能有助于提高应用程序的性能。
（4）filedValueCache字段值缓存：
标签：垃圾 频繁 调整 查询 影响 频率 lru 变化 注意
原文地址：http://www.cnblogs.com/cch-java/p/7296437.html
