solr search过程

原文：http://www.cnblogs.com/mandela/archive/2011/05/10/2041754.html

 

Search步骤
a.SolrParams参数准备
q – 查询语句
sort – 排序字段&排序方式
rows – 返回多少条 start – 起始点
fl – 返回字段，需要返回scorer字段的话这个KEY对应的VALUE里包含”score”就可以了
qt – 查询类型，根据这个字段找Handler
fq – FilterQuery

b.根据coreName到coreContains拿到SolrCore，再到SolrParams里去qt的VALUE到SolrCore找对应的SolrRequestHandler
如果没找到需要调用core.close表示归还，在从coreContains那里拿core时将它的被引用做了++操作了的

c.根据SolrParams&SolrCore构造一个SolrQueryRequest，其包含如下属性SolrCore, SolrParams, Map<obj, obj> context
实例化一个SolrQueryResponse，有了这两个对象后就可以调用solrcore.execute执行查询操作了

d.solrcore.execute – 实际上执行的是handler.handleRequest(request, response)
[1].SolrRequestHandler可以配置三个不同重要性的默认参数，defaults,appends,invariants上面提到过，handler
在处理请求的第一步就是用这三个SolrParams包装用户提交的SolrParams。其包装逻辑是params为用户提交的SolrParams
defaults作为params的默认取值SolrParams -> params
appends作为params里getParams添加参数的SolrParams –> params
params作为invariants的默认取值SolrParams –> params
[2].先前提到对于SearchHandler有SearchComponent，这里只需要注意下QueryComponent就可以了，添加其他的组件
一是可能没有用二是会带来内存开销，比如StatsComponent组件加入的话查询会返回符合结果的DocSet，其本身也没什么用在SearchHandler处理查询请求逻辑里面其会先初始化一个ResponseBuilder，这个对象用来存放各个SearchComponent处理的其他或者结构需要的数据，资源协调者；其再迭代SearchComponent调用prepare函数；其再迭代SearchComponent调用process函数
整个core里SearchComponent只有一个实例，处理查询请求的数据当然不能放在这些SearchComponent里，只能放在资源协调者ResponseBuilder上…
[3].组件QueryComponent的prepare(ResponseBuilder)逻辑
---------
request.params.get[fl]拿到希望返回的域，判断里面是否包含scorer –> 设置到ResponseBuilder上
request.params.get[defType]拿到QueryParserPlugin名字，如果为null则使用LuceneQParserPlugin.NAME
request.params.get[q]拿到查询字符串 –>设置到ResponseBuilder上
QParser.getParser(queryStr, queryParserType, request)解析得到Qparser，其解析过程大致是
---------
a.实例化一个Map<String, String>用来存放从queryStr以正则表达式{!(.*)}抽取的group(1)里符合正则
x|x=’(.*)’|x=”(.*)”|x=/$(.*)/$|x=(.*) |x=(.*)$ - x表示符合JAVA变量命名规则的字符串
对于第一种往MAP里PUT(“type”, x)，对于第四种则PUT(x, request.params.get(group(1)))；其他的put(x, group(1))
queryStr里正则{!(.*)}剩下的PUT(“v”, 剩下的str)，MAP –> MapSolrParams作为localParams
b.从localParams找”typd”.value作为指定QueryParserPlugin的值，如果没有还是使用默认的LuceneQParserPlugin.NAME
如果queryStr里包含正则{!(.*)}则queryStr=localParams.get(“v”)
c.根据指定的QueryParserPlugin的名称到core里获取QueryParserPlugin，调用其createParser函数构造Qparser
其传入的参数有{queryStr, localParams, requst.params, request}
d.以LuceneQParserPlugin为例子查看其构造Qparser - LuceneQParser的过程，Qparser的作用主要是构造一个Query
在实例化时如果localParams.get(“tags”)不为null则会取request.context.get(“tags”)其值是一个
Map<str, collection>，如果取的值是null则new以个PUT到request.context里，再来解析localParams.get(“tags”)
得到的字符串，有”,”切割得到的子字符串PUT到request.context.get(“tags”)得到的Map中，VALUE=
List.add(LuceneQParserPlugin)，以解析{!tag=”wdx,monkey”}为例子，context.get(“tags”)里有两个映射
“wdx” -> List – {LuceneQParserPlugin} //LuceneQParserPlugin持有request, queryStr, params, localParams
“monkey” -> List – {LuceneQParserPlugin}
---------
调用Qparser.parse获取Query的逻辑是
a.到localParam&params里找”df” – 默认字段，找VALUE时localParam优先，找不到再到params里面，如果没找到则
到core.indexSchema那里拿
b.到localParam&params里找”q.op” – BooleanQuery默认关系，拿的逻辑同上
c.实例化一个SolrQueryParser解析queryStr -> Query输出
得到Query –>设置到ResponseBuilder上
---------
抽取localParam&params里的”sort”，”rows”，”start” –> 设置到ResponseBuilder上，其中sort可以指定
schema里指定的域名|score|docid
同时把Qparser设置到ResponseBuilder上
---------
处理”fq” – FilterQuery
request.params.get(“fq”)得到过滤查询String[]，迭代这个数组调用QParser.getParser(str, null, request)
获取Qparser解析str得到过滤查询Query，QParser.getParser的逻辑上面介绍过，这样得到一个过滤查询的链表，将这个
链表设置到ResponseBuilder上

[4].组件QueryComponent的process(ResponseBuilder)逻辑
a.每个request都只持有一个IndexSearcher的引用，通过调用core.getSearcher获取，QueryComponent
需要先获取IndexSearcher，core.getSearcher里的逻辑是
----getSearcher的逻辑
getSearcher – (forceNew, returnSearcher, waitSearcher-Futures)
关注solr全局三个点调用getSearcher函数 : solrCore初始化时(false, false, null)，QueryComponent处理查询
请求时(false, true, null)，UpdateHandler在处理commit请求时(true, false, new Future[1])
---------
1.solrCore初始化时
根据solrconfig配置的IndexReaderFactory&DirectoryFactory获取索引的IndexReader，再使用这个reader
封装一个SolrIndexReader，再使用这个SolrIndexReader封装一个RefCounted(searcher的引用计数器，当搜索
组件获取一个组件后引用++，用完后调用close引用--，当引用数为0时将这个引用从core管理的一个当前被使用的
searcher的链表移除，同时调用searcher.close回收资源)，将这个引用添加到core管理的一个当前被使用的searcher
的链表里如果firstSearcherListeners不为空则回调这些监听器，这个回调是交给core的一个newSingleThreadExecutor去
做的，再往这个线程池里添加一个任务:将这个RefCounted设置为core当前最新的searcher的引用计数器
最后返回null，因为returnSearcher=false
在solrCore初始化时这样做的主要目的是在初始化时就加载好IndexSearcher，搜索请求来了之后能立即返回，而不必等待加载IndexSearcher
---------
2.QueryComponent处理查询请求时
由于core当前最新的searcher的引用计数器不为null且这个获取IndexSearcher的请求不是强制要求获取最新的，且
returnSearcher=true故直接返回core当前最新的searcher的引用计数器，且这个引用计数器做++
这里面还有段当前searcher的引用计数器为null的逻辑，但是没有发现有什么情况会导致这种情况发生故不累述了
---------
3.UpdateHandler在处理commit请求时
首先到core管理的一个当前被使用的searcher的链表里获取目前最新的searcher；同时会加载索引目录下的
index.properties文件(如果存在的话)，拿到KEY=’index’的值，其指明目前索引的存放地方；如果获取的目录和当前
最新的searcher使用的目录一致且solrConfig.reopenReaders为true则获取通过searher.reader.reopen获取
最新的reader -> 封装成searcher，否则直接IndexReader.open获取reader。
获取到searcher后的一段逻辑[RefCount封装，添加到searchers链表]和core初始化时是一样的，接下来的逻辑是
如果solrConfig.useColdSearcher为TRUE其当前searcher的引用为null-导致来自QueryComponent的请求阻塞
[现在还没发现什么情况会导致searcher的引用为null]
立即将这个新的searcher的引用设置为core当前最新的searcher的引用计数器，这样来自QueryComponent的请求
拿到这个引用后返回，当时这时这个新建的searcher是没有经过其前一个searcher的cache热身的，同时这样会导致这个
新建的searcher不会进行热身活动
如果solrConfig.useColdSearcher为FALSE则会往线程池里添加一个热身的任务
如果newSearcherListeners不为空则回调这些监听器，也是给线程池的任务
最后如果先前没有做将新的searcher的引用设置为core当前最新的searcher的引用计数器的行为的话，则往线程池添加
一个任务 – 将新的searcher的引用设置为core当前最新的searcher的引用计数器
最后返回null，因为returnSearcher=false
---------
----solr的索引视图
用IndexReader构建SolrIndexSearcher时会先用solr的视图包装这个IndexReader –> SolrIndexReader
solr的索引视图在lucene上添加了一层快速处理多个索引目录的视图，在用IndexReader构建SolrIndexReader时会获取这个reader下的所有叶子Reader-SegmentReader，并建立索引，基于这样索引传入一个DOCID后能快速的定位SegementReader，即其会持有其下的所有SegementReader&其start-offset，同时search时如果是TermQuery则直接用叶子reader来做
----SolrIndexSearcher.cache
a.SolrIndexSearcher有四个缓存 – 对于cache来说有三个角色CacheConfig，SolrCache，CacheRegenerator
其分工是CacheConfig来自于solrconfig文件配置，在一个searcher初始化时会迭代fieldValueCache，filterCache，
queryResultCache，documentCache的配置，如果有配置则通过CacheConfig @class创建SolrCache实例
CacheRegenerator是负责新searcher创建后用老的searcher热身行为的，会遍历老的searcher的各个cache的key-value
具体做什么由各个CacheRegenerator说了算，因为这时候由于update的commit操作会有新的doc进入索引，所有老的value都不能用了，唯一能做的就是知道哪些key比较热门
对于filterCache来说其会使用新的searcher去加载这些热门的key的值放到cache里
对于queryResultCache来说其会使用新的searcher去加载这些热门query的值放到cache里，当时查询参数flag会加上
NO_CHECK_QCACHE
-------
SolrCache : filterCache queryResultCache documentCache
queryResultCache – key=QueryResultKey value=DocList，主要是存放一个查询请求返回的DocList数据，QueryResultKey计算hash的影响因素有 : query filters sort
documentCache – key=int value=Document，主要是存放docid->document的映射，在加载document时都会走这个缓存，如果不存在则用reader去加载，然后PUT到cache里
filterCache ：key=Query value=DocSet，主要存放query->docSet的映射，满足这个query的所有docid的映射，其作用和
queryResultCache比区别在于其存放的可能只是中间结果，queryResultCache存放的是最终结果
值得注意的是使用这些cache是很耗内存空间的，为了限制内存空间的使用，cache的实现也是使用LRU机制，通过实现LinkedHashMap的removeEldestEntry函数里判断目前的大小是否大于了限制来实现的
-------
b.对于纯粹的来自QueryComponent组件的查询请求是只需要返回DocList就可以了，可能还需要分数，这里分析为了简便只考虑需要DocList和分数的情况
根据offset+len计算当期期望的最大的docId，再和maxDoc比较，不能比maxDoc大
如果queryResultCache存在且这个查询没有过滤查询则到用这个查询封装一个QueryResultKey到queryResultCache取值
如果存在且[查询不需要分数或者cache里有分数]这样就立即拿到了docList返回，查询结束
如果cache里没有找到或者需要分数而cache里没分数则需要走查询了，对于查询的结果如果可以cache则put到queryResultCache
---------------
拿到DocList了后就可以给SolrQueryResponse返回了...