建设高性能solr-分发与拷贝

分发和拷贝
对于接收大量查询的应用来说，单个solr server可能满足不了性能要求。因此，Solr提供基于负载均衡的多查询server间拷贝Lucene index的机制。复制过程通过处理一组事件监听器（这些监听器在solrconfig.xml配置）来和一些shell脚本来完成。

在复制架构中，一个Solr server扮演master server角色，为一个或多个（用于查询服务的）slave server提供index的拷贝（也叫snapshots）。建Index的指令被发到主server，查询指令被发到从server。主server 能手动创建快照，也能通过配置solrconfig.xml中的<updateHandler>段以触发snapshot的创建（当收到 commit或/与optimize时间时）。不管是手动的拷贝还是自动的事件触发的方式，snapshooter脚本在主server中被调用，以创建一个名为snapshot.yyyymmddHHMMSS的目录。从server然后使用rsync拷贝那些lucene index中已改过的文件。
Listing 1. Update handler listeners

<listener event="postCommit" class="solr.RunExecutableListener">
<str name="exe">snapshooter</str>
<str name="dir">solr/bin</str>
<bool name="wait">true</bool>
<arr name="args"> <str>arg1</str> <str>arg2</str> </arr>
<arr name="env"> <str>MYVAR=val1</str> </arr>
</listener>

在从server那边，通过snappuller脚本从主server收到snapshot。snappuller从主server收到必要的文件然后snapinstaller shell脚本能用来安装snapshot并通告solr新的snapshots已创建好了。最好安排好你的系统按照多久你会创建snapshots的基准来执行这些步骤。主server这边，rsync后台进程必须在从server能获取snapshots前启动。从server这边 snappuller-enable脚本必须在snappuller调用前执行。

分发时常用问题解决：
当尝试optimize 更新的index时，会有以下问题：
1.优化大index会非常耗时，建议在index 更新操作不是那么多的时候做。Optimization 导致很多lucene的索引文件合并成一个文件。这意味着“从server”不得不拷贝整个文件。但这种方式比在每个 从server 上自己optimize index要好很多。因为这些server可能没有从主server同步到数据。
2.如果新的snapshots被频繁的从master server拷贝出来，slave server可能会隐过度使用snappuller的copy操作和因为新的index需要预热而经受性能下降。
【译者注】
截止到目前为止，官方只发布了solr 1.3 此版本还未提供solr的java版的replication。但从solr的官方wiki中讲到了java版的ReplicationHandler。see http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/handler/ReplicationHandler.java?revision=823711&view=markup 想在solr中直接使用还是要稍微DIY一下了。