solr搜索过程解析

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¶ms里找”df” – 默认字段，找VALUE时localParam优先，找不到再到params里面，如果没找到则

到core.indexSchema那里拿

b.到localParam¶ms里找”q.op” – BooleanQuery默认关系，拿的逻辑同上

c.实例化一个SolrQueryParser解析queryStr -> Query输出

得到Query –>设置到ResponseBuilder上

---------

抽取localParam¶ms里的”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返回了...