tlnshuju

LXY3800

2、Query request handling
　　



2.1、Request-handling overview
　　

　　

　　

　　

　　
Solr 查询请求的处理过程:
　　
1、Client（浏览器或者solrjclient）发送查询请求到solrserver
　　
2、Jetty（或者tomcat等其它的webserver）会将/solr的请求路由到solr统一的request dispatcher，dispatcher会依据/collection1找到相应的core，并找到这个core的solrconfig.xml中定义的处理请求的 request handle
　　
3、request handler  使用各个组件串行的处理这个请求
　　
4、处理完毕后，Reponse writer组件会将结果处理成某个格式（xml、json等等）并返回client，默认是返回xml格式。
　　



2.2、search handler
　　
request handler主要有两类search handler和update handler。search handler负责处理查询请求、update handler用来更新索引的请求，这里主要介绍一下search handler，update handler 下一章介绍。下图是solrconfig.xml中/select request handler的定义。
　　

　　

　　
ps:solrconfig.xml文件里定义的solr.开头的class（如这里的solr.SearchHandler）,都会相应于solr core java package：

　　
"analysis.", "schema.", "handler.", "search.", "update.", "core.", "request.", "update.processor.", "util.", "spelling.", "handler.component.", or"handler.dataimport." 。
　　这里的SearchHandler相应于

　　
org.apache.solr.handler.component.SearchHandler 。

　　
一个Search handler能够定义一下几个处理阶段：
　　
1.请求參数处理
　　
加入请求中没有的默认查询參数
　　
覆盖改动请求的參数值
　　
加入额外的參数
　　
2.search first-components（可选）
　　
3.search process components
　　
4.search last-components （可选）
　　

　　



2.3、search components
　　
2.3.1 QUERY COMPONENT
　　
query处理的核心，通过active searcher 解析和运行查询。查询解析是通过參数控制的defType（如edismax，dismax）。query
组件查询初匹配查询參数的doc。这些doc能够被兴许的组件继续处理。query组件是默认开启的，兴许其它的组件须要在查询參数里显示的指定。
　　
2.3.2 FACET COMPONENT
　　
solr将以导航为目的的查询结果称为facet. 它并不会改动查询结果信息, 仅仅是在查询结果上依据分类加入了count信息, 然后用户依据count信息做进一步的查询, 比方淘宝的查询列表中, 上面会表示不同的类目相关查询结果的数量，，兴许会具体介绍
　　
2.3.3 MORE LIKE THIS COMPONENT
　　
假设启用这个组件。会搜索出和查询结果相似的doc，兴许会具体介绍
　　
2.3.4 HIGHLIGHT COMPONENT
　　
假设启用这个组件，会高亮显示匹配的文本，兴许会具体介绍
　　
2.3.5 STATS COMPONENT
　　
统计组件。假设启用，能够统计指定数字field的统计信息。如最小值、最大值、总和、平均值...等等统计信息。详细能够看以下的实例。
　　

　　

　　
2.3.6、DEBUG COMPONENT
　　
开启debug组件。能够看到solr 打分的详情，有助于排查一些诸如排序错误的问题。
　　开启debug组件仅仅用在请求參数添加debugQuery=true就能够了。
　　
2.3.7 ADDING SPELLCHECK AS A LAST-COMPONENT
　　
兴许再介绍





3、Managing searchers
　　
solrconfig.xml中<query>标签包括了一些能够优化查询性能的參数。如缓存、field懒载入、新searcher预热等。


3.1 New searcher overview
　　
       searcher是solr处理query的组件。solr中仅仅有一个active 的searher。
　　这个active searcher 拥有全部lucene索引的仅仅读快照，假设提交一个新的doc到solr，这个doc在当前这个searcher中是不可见的。那么怎样才干使得新提交的doc可见呢？solr的解决方式是关闭当前的searcher，新开一个searcher。新的searcher拥有新提交的doc的索引的仅仅读快照。这就是solr
commit的须要做的一部分工作（每一个commit都要new 一个searcher）。
　　
       当进行一次commit之后，在旧的searcher上还有未运行完的查询，所以旧searcher的销毁是在其上面搜有查询运行完才运行的。销毁旧的searcher的时，其上面全部的缓存也都会被删除（由于原有的缓存都是基于旧的索引快照的，commit之后索引是有更新的。所以旧的缓存也应该是要失效的）。
　　
       而生成新的searcher须要运行一些计算（如又一次计算缓存），所以生成新的searcher是代价比較耗时的操作。
　　为了不正确用户的查询产生影响。solr採用的后台生成新的searcher的方式。当新的searcher就绪之前，旧的searcher一直是提供查询的，直到新的searcher 预热完成。
　　

　　



3.2、Warming a new searcher
　　
预热新的searcher有两种方式：通过旧的cache自己主动预热新的cache、运行cache预热的查询。下一节会具体介绍自己主动预热。
　　
这里先看一下运行cache预热的查询的配置。
　　通过配置一个listener，当newSeacher事件发生时。会运行queries里面的查询用来预热缓存。配置成预热的query一般都是应用最频繁的查询，配置queries不能过多，过多会造成预热的时间太久。耗费太多server的资源。
　　

　　

　　

　　
这样的预热方式方式一个非常实用的场景是solr服务启动first searcher的预热。配置first searcher的预热。仅仅须要将上面的event=&quot;firstSeacher&quot;即可了。
　　solr推断事件是firstSeacher是依据当前Seacher是否是null推断的，假设当前seacher是null则为firstSearcher。
　　
searcher预热还有两个重要的配置标签useColdSearcher和maxWarmingSearchers
　　

<useColdSearcher>false</useColdSearcher>，当配置为true的时候，不等新的searcher预热完成就直接使用，而配置为false的时候，就是等到新的searcher预热完才会使用　　

<maxWarmingSearchers>2</maxWarmingSearchers>， 配置同一时候预热的searcher数量，假设searcher预热的时间过长，commit又比較频繁的话，会导致同一时候有多个searcher在预热。假设同一时候预热的数量超过配置的參数。之后的commit就会报错。假设常常出现报错，就须要考虑是否这个&#20540;设置的不合理或者预热时间过长。solr默认配置的是2。