"brown fox", "fox jumped", "jumped over", "over the", "the
lazy", "lazy dog".粗糙的测试表明，这样至少可以提高2-3倍的性能。
使用多Solr服务器(Scale wide)
当你对单台Solr服务器的调优仍然无法满足性能需求的时候，接下来你应该考虑拆分查询请求到不同的机器上，具备横向扩展(Scale
wide)是可扩展系统的最基本的特点，因此，solr也具备了该特点。
Script VS Java replication
在Solr1.4之前，replication是通过使用Unix脚本进行的。一般来说，这种方案还算不错，但是可能有一些复杂了，需要编写shell脚本，cron
jobs和resync daemon。
从1.4开始，Solr实现了基于Java的复制策略，不用再编写复杂的shell脚本，并且运行得更快。
Replication的配置在solrconfig.xml之中，并且配置文件本身可以在master和slave服务器之间被复制。Replication目前已经支持Unix和Windows系统并且已经集成到了Admin
interface之中。Admin
interface目前可以控制复制---例如，强制开始replication或者终止失效（stalled）的复制。复制是通过ReplicationHandler提供的REST
API进行的。
开始体验多Solr服务器
如果你在多个Solr服务器之间使用了同一个solrconfig.xml文件，那么你需要在启动的时候指定以下几个参数：
l -Dslave=disabled：指定当前solr服务器是Master。Master将负责推送索引文件到所有slave服务器。你将会存储document到master上，而在slave服务器上进行查询。
l -Dmaster=disabled：指定当前solr服务器是Slave。Slave要么定期轮询Master服务器来更新索引，要么手动的通过Admin
interface触发更新操作。一组slave将会被负载均衡（可能是HAProxy之类）器管理着来对外提供搜索。
如果你想在同一机器上运行多个Solr服务器，那么你需要通过-Djetty.port=8984指定不同的端口，并且通过-Dsolr.data.dir=./solr/data8984指定不同的data目录。
配置Replication
配置replication很简单，在./examples/cores/mbreleases/solrconfig.xml中就有示例配置:
startup
commit
stopwords.txt
http://localhost:8983/solr/replication
00:00:60
注意${}将能够运行期进行配置，它将通过-Dmaster=disabled 或-Dslave=disabled决定这里的参数是master还是slave。Master机器已经配置了在每次commit之后进行replication。并且可通过confFiles属性以指定复制配置文件。复制配置文件非常有用，因为你可以在运行期修改配置而无需重新部署。在master上修改配置文件，replication到slave后，Slave将会知道配置文件被修改了，并reload
core。
可以参考http://wiki.apache.org/solr/SolrReplication
Replication的实现
Master是感知不到Slave的存在的，Slave会周期性的轮询Master来查看当前的索引版本。如果Slave发现有新的版本，那么Slave启动复制进程。步骤如下：
1. Slave发出一个filelist命令来收集文件列表。这个命令将返回一系列元数据（size，lastmodified，alias等等）
2. Slave查看它本地是否有这些文件，然后它会开始下载缺失的文件(使用命令filecontent)。如果连接失败，则下载终止。它将重试5次，如果仍然失败则放弃。
3. 文件被下载到了一个临时目录。因此，下载中途出错不会影响到slave。
4. 一个commit命令被ReplicationHandler执行，然后新的索引被加载进来
跨多个Slave的分布式搜索 索引一些文件到Master上
你可以用SSH运行两个session，一个开启Solr服务，另一个索引一些文件：
>> curl http://localhost:8983/solr/mbreleases/update/csv
-F f.r_
attributes.split=true -F f.r_event_country.split=true -F
f.r_event_
date.split=true -F f.r_attributes.separator=' ' -F
f.r_event_country.
separator=' ' -F f.r_event_date.separator=' ' -F commit=true -F
stream.
file=/root/examples/9/mb_releases.csv
上面的命令索引了一个csv文件。你可以通过Admin interface监控这个操作。
配置Slave
之前已经索引了文件，并且通过复制已经到了slave上，接下来，需要使用SSH到slave机器上，配置masterUrl如下：
http://ec2-67-202-19-216.compute-1.amazonaws.com:8983/solr/mbreleases/replication
00:00:60
你可以到Admin interface上查看当前的replication状况。
分发搜索请求到不同的Slave上
由于使用了多个Slave，所以我们没有一个固定的请求URl给客户的，因此，我们需要使用负载均衡，这里使用了HAProxy。
在master机器上，配置/etc/haproxy/haproxy.cfg，将你的salve机器的url放入：
listen solr-balancer 0.0.0.0:80
balance roundrobin
option forwardfor
server slave1
ec2-174-129-87-5.compute-1.amazonaws.com:8983
weight 1 maxconn 512 check
server slave2
ec2-67-202-15-128.compute-1.amazonaws.com:8983
weight 1 maxconn 512 check
solr-balancer处理器将会监听80端口，并将根据权重将请求重定向到每个Slave机器，运行
>> service haproxy start
来启动HAProxy。
当然，SolrJ也提供了API来进行负载均衡，LBHttpSolrServer需要客户端知道所有slave机器的地址，并且它没有HAProxy这样的强健，因为它在架构上实现得很简略。可以参考：
http://wiki.apache.org/solr/LBHttpSolrServer
索引分片(Sharding indexes)
Sharding是一种当你的数据太多时很普遍的对单台数据库进行扩展的策略。在Solr中，sharding有两种策略，一是将一个单一的Solr
core分成多个Solr服务器，二是将单核的Solr变成多核的。Solr具备将单一的查询请求分发到多个Solr
shards上，并聚集结果到一个单一的result里返回调用者。
当你的查询在单台服务器上执行太慢时你就需要组合多台solr服务器的能力来共同完成一个查询。如果你的查询已经足够快了，而你只是想扩展以为更多用户服务，那么建议你使用全索引而使采用replication的方法。
使用Sharding并不是一个完全透明的操作。关键的约束就是当索引一个document，你需要决定它应当在哪个Shards上。Solr对于分布式索引并没有相关的逻辑支持。那么当你搜索的时候你需要加上shards参数到url，以确定需要到哪些shards上收集结果。这意味着客户端需要知道Solr的架构。另外，每个document需要一个唯一的id，因为你是基于行将其拆分的，需要一个id来区分彼此。
分发documents到shards
一种比较好的办法是对id进行hash，在模分片的大小来决定应当分发到哪个shards上：
SHARDS = ['http://ec2-174-129-178-110
.compute-1.amazonaws.com:8983/solr/mbreleases',
'http://ec2-75-101-213-59
.compute-1.amazonaws.com:8983/solr/mbreleases']
unique_id = document[:id]
if unique_id.hash % SHARDS.size == local_thread_id
# index to shard
end
这样，在你的shards不变化的情况下，你的document将会很好的找到它的shards。
跨多个shards搜索(Searching across shards)
这个功能是已经配置在query request
handler里面的。因此你无需做额外的配置，如果你想在两个shards上面进行查询，那么你只需要在url跟相关的参数即可：
>>
http://[SHARD_1]:8983/solr/select?shards=ec2-174-129-178-110.
compute-1.amazonaws.com:8983/solr/mbreleases,ec2-75-101-213-59.compute-
1.amazonaws.com:8983/solr/mbreleases&indent=true&q=r_a_name:Joplin
注意shards后的参数不能跟http这样的传输协议，并且你可以跟尽量多的shards，只要你不超过GET
URL的最大字符数4000.
在使用Shards的时候，请务必注意以下内容：
l Shards仅仅支持以下组件(Component):Query,faceting,Hignlighting,Stats和Debug
l 每个document必须有一个唯一的id。Solr是根据这个来合并搜索结果document的。
l 如果多个shards返回了相同id的document，那么第一个会被选中，而余下的被忽略。
联合使用Replication和Shards(Scale Deep)
如果你使用了前面的方法，仍然发现性能无法满足要求，那么是到了将两个联合起来组成更高层次的架构来达到你的需要的时候了。
你需要使用同样的方法配置一组Master，这样最终你将有一棵树一样的Masters和Slaves。你甚至可以有一个专用的Solr服务器，它没有索引，只负责将查询分发的shards上，并在最后合并结果返回用户。
数据的更新将通过在Master机器上更新并replication到slave机器上实现。前端需要相关的负载均衡支持，但是这样一来，Solr将能够处理极大的数据。
关于Solr的下一步scaling，在Solr的邮件列表里面已经讨论了很多次，一些调查研究显示，Hadoop能够提供强健可靠的文件系统。另一个有趣的项目是ZooKeeper，它将能对分布式系统进行集中式的管理，对于将ZooKeeper集成进来已经有不少努力。
京公网安备 11010802041100号