solr缓存学习

birk

　　sor缓存
　　虽然solr的检索速度很快，但是当搜索服务的请求变得非常复杂的时候，我们还是会发现搜索会出现一些性能上的问题。其实很多用户的请求很有很多相似的地方，
　　比如（一）：它们可能是不同用户的同一个请求,或者这个用户仅仅是进行了翻页的操作;（二）：用户的过滤条件会有重合的地方，比如它们在同一个类目下进行了不同的查询；
　　针对这两个问题，其实我们可以通过设置solr的缓存来使查询速度变快从而提高性能。
　　solr的cache类型：
　　（1）filterCache过滤器缓存：这个缓存主要是针对fq进行的。通常用户会在一个固定的业务场景下进行不同的查询，而启用这个缓存会大大地提高搜索性能。
　　（2）queryResultCache查询结果缓存：需要满足query、filterquery sortFiled一致才行。如果多次执行一个查询，其实看到的是缓存取出的结果，并不是去索引的结果。对要耗费大量计算资源的查询来说，这是一种比较高效的解决方式。
　　queryResultWindowSize：我们可以去设置查询结果窗口大小，比如我们每页展示20个商品，如果用户大多数情况下去浏览第一页第二页那么我们可以把queryResultWindowSize设置为40，这样就可以避免用户查看第二页时再次执行查询请求。（这个可以通过跑数据来决定我们要设置的值）
　　enableLazyFieldLoading：一般我们置为true，避免拉到不必要的字段
　　（3）documentCache文档缓存：里面存储了文档的内容，如果索引更新的比较快，结果文档也常在变化，那么文档缓存可能会把资源耗费在对应用程序性能无益的地方。但是如果索引更新频率很低，那么文档缓存可能有助于提高应用程序的性能。
　　（4）filedCache字段值缓存：这个缓存主要是lucene来管理，而不是solr来管理。它提供了可以快速访问字段值的途径，主要是用在sort和facet是使用。
　　（4）filedValueCache多值字段缓存：主要用于存储multivalued Field，同上面的filedCache，它是solr特有的缓存，如果你不配置在solrconfig.xml那么它会自动初始化为(初始大小10，最大10000），这样可能会有内存溢出的风险。
　　搜索器：
　　在这里就不对搜索器进行很细致的介绍了，因为本文档不是主要介绍搜索器的，而搜索器的一些操作可能会用到缓存且对缓存造成影响，在这提一下。
　　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长时间在做垃圾回收工作，而暂停服务。