solr分布式搜索源码分析

基于solr4.4   

   分布式搜索的主控逻辑是在SearchHandler.handleRequestBody方法中实现的，参见distributed request分支
分布式搜索过程是分阶段stage的，stage的控制在每个componnet的distributedProcess方法中，每个stage的请求输出都会封装在outgoing.add(sreq)中。
component针对每个stage做相应的参数的设置和处理，并输出到outgoing中，在while循环中检测到outgoing有值，则代表需要对该请求，进行分布式的调用；
分布式调用会针对当前的stage提交每个shard的查询，并异步收集所有shard的返回结果。
 每个stage计算完成后，对结果进行处理
 for(SearchComponent c : components) {
              c.handleResponses(rb, srsp.getShardRequest());
            }

所有的stage都完成后，调用component.finishStage进行后续的处理
   for(SearchComponent c : components) {
          c.finishStage(rb);
        }

stage主要分两个stage，为makeQuery和getFileds
      makeQuery,给url带上查询参数fl=id，score根据情况是否会带，我们知道fl是代表只返回那些field，Solr会取schema配置文件的uniquerField，所以这次请求就只返回id的值。得到id值后，QueryComponent会合并id，如果不同的shard有相同的id，则会只取一个
      getFileds,通过QueryComponent来封装请求参数，其中最关键的是封装ids参数，即根据上面请求得到的ids参数把他作为值放到url里，再一次发请求根据id来取对应的field
其实在这两个阶段之前，还有一个阶段是STAGE_PARSE_QUERY，在这个阶段可以计算分布式的idf，不过目前solr没有实现，而是默认每个shard只计算自己的idf,并不会计算全局的idf,在数据量较大的情况下，基于Shard层次的TF-IDF不会有太大的偏差，但是如果分布式索引非常不均衡，可能就要重视相关度的计算问题.

      makeQuery stage完成后，对所有shards返回的docs进行mergeIds操作，mergeIds实现中会根据分页把doc放到优先级队列中，根据sort和score进行比较排序,获取当前页面的doc list，这里存在一个问题，优先级队列的size是start+rows，只返回rows大小的给客户端，不过需要对top的start+rows数量的doc进行排序，的对于翻页比较多的情况，代理节点内存的开销和排序计算的CPU开销都会比较大

比如
QueryComponent,
  private void handleRegularResponses(ResponseBuilder rb, ShardRequest sreq) {
    if ((sreq.purpose & ShardRequest.PURPOSE_GET_TOP_IDS) != 0) {
      mergeIds(rb, sreq);
    }

    if ((sreq.purpose & ShardRequest.PURPOSE_GET_FIELDS) != 0) {
      returnFields(rb, sreq);
    }
  }