原文出处：http://www.cnblogs.com/gpcuster/archive/2012/10/10/2718341.html

概述

Solr单机支持的搜索数据量是有一定上限的，这个取决于搜索的复杂程度，服务器的硬件配置与业务的要求等等，所以将搜索功能分布化将是对于大数据搜索的一个必然趋势。

Solr从1.3版本开始，自带了分布式搜索（Distributed Search）。这个功能使得Solr能够通过多服务器进行横行扩展，对数据进行水平拆分，从而支持海量数据的搜索功能。

Solr-3.6.1版本对分布式搜索的支持功能如下：

由于业务功能和时间的缘故，本文将只讨论Query component的技术实现逻辑。

注意事项

在使用Solr进行分布式搜索的时候，需要注意以下细节：

• schema.xml中定义的unique key必须保存在索引中。因为Solr在进行2nd phrase搜索时需要使用这个unique key进行数据一致性的二次确认与获取搜索要求查询的字段数据。
• 分布在不同服务器中的索引文件中包含的unique key不要有重复。因为Solr在进行1st phrase搜索时需要根据这些unique key进行排序与去重，如果unique key有重复，包含相同unique key的doc结果将随机返回。
• 搜索结果不要有过多的翻页。因为Solr的分布式搜索中，会将需要翻页排序后的总结果全部返回给proxy solr server进行汇总排序，如果翻页过多，那么对网络带宽将会照成一定的压力。（英文原文：Makes it more inefficient to use a high "start" parameter. For example, if you request start=500000&rows=25 on an index with 500,000+ docs per shard, this will currently result in 500,000 records getting sent over the network from the shard to the coordinating Solr instance. If you had a single-shard index, in contrast, only 25 records would ever get sent over the network. (Granted, setting start this high is not something many people need to do.)，解释：start值过大就意味着翻页很多次，为什么第一个shard会传500000个docs到第二个shard？因为要对分值进行排序，返回分值最高的25条，所以要将shard1和shard2的结果集合并，在合并后的结果集里返回分值最高的25条。
• 注意HTTP连接数。因为Solr的分布式搜索中，服务器可能既是search server又是proxy server，一遍等待http请求应答有一遍处理http请求，多台服务器之间就可能会出现死锁。

分布式搜索逻辑实现

Query component的实现原则为：Multi-phased approach, allowing for inconsistency，具体的实现细节如下：

1. 客户端发送搜索请求给Solr集群中的任意一台服务器SP。
2. SP服务器处理分布式查询请求
   1. Phase One
      1. 构建查询请求，只获取查询Doc的unique key与sort field字段。
      2. 将构建好的请求通过HTTP发送给每一个Solr Shard节点。
      3. 等待Solr Shard节点返回查询结果。
      4. 根据排序规则，逐个合并Solr Shard节点返回的查询结果。
   2. Phase Two
      1. 构建查询请求，根据unique key查询客户端查询的相关字段数据。
      2. 将构建好的请求通过HTTP发送给每一个需要请求的Solr Shard节点。
      3. 等待Solr Shard节点返回查询结果。
      4. 逐个合并Solr Shard节点返回的查询结果，构建本次查询的最终结果。
      5. SP服务器将分布式查询结果返回给客户端

注意：当前的版本中，分布式查询中如果有某一个Shard异常，整体的查询将失败。

参考文档

• http://wiki.apache.org/solr/DistributedSearch
• http://wiki.apache.org/solr/WritingDistributedSearchComponents
• http://wiki.apache.org/solr/DistributedSearchDesign
• Solr-3.6.1源码

看完这篇分析总体来说觉得分布式搜索还存在许多弊端，但是是4.0版本以前唯一的处理大数据搜索的方式了，将索引库分片单独存储，比如按省分片存储商家数据等等，有效的降低索引库的大小。对于其中某一个SHARD异常导致查询失败的情况，可以用TOMCAT集群来处理，通过索引的replication在多个TOMCAT之间同步索引，当一个群组瘫痪时，将请求发送到另外一个群组，不过分片过多的话，用到的TOMCAT服务器也越多，架构太复杂不便于维护了。

所以感觉实在是逼不得已才去使用分布式搜索。

去研究一下4.X版本的solrCloud看看对这些问题能不能解决。