Solr配置文件及SolrCloud

一、Solr配置文件

solr的配置重要的有三个：solr.xml、solrConfig.xml、schema.xml。Solr中最主要的配置文件是：solrconfig.xml和schema.xml。

solr Manager -> solr core -> handler -> component

solr.xml 是整个Solr节点的配置，是定义关于core的管理、collection分片、solrcloud和http请求处理
solrconfig.xml从整体上对core进行了配置，例如索引的存放路径、字段的最大长度（maxFiedlLength）、写锁的超时时间（writeLockTimeout）、锁类型（lockType）、是否压缩索引（useCompoundFile）、内存索引缓冲区大小（ramBufferSizeMB）、合并因子（mergeFactor）、删除策略、自动提交策略、缓存设置等。里面详细描述了各个部件（handler）的参数。
schema.xml主要是对索引的配置，例如分词器、字段名称+索引方法+存储方式+分词方式、唯一标识字段等。

链接：
http://www.aboutyun.com/thread-7018-1-1.html
http://www.cnblogs.com/seaspring/p/5381715.html

二、SolrCloud之分布式索引及与Zookeeper的集成

1、概述

SolrCloud是Solr4.0版本开发出的具有开创意义的基于Solr和Zookeeper的分布式搜索方案，主要思想是使用Zookeeper作为集群的配置信息中心。也可以说，SolrCloud是Solr的一种部署方式，除SolrCloud之外，Solr还可以以单机方和多机Master-Slaver方式进行部署。分布式索引是指当索引越来越大，一个单一的系统无法满足磁盘需求的时候，或者一次简单的查询实在要耗费很多时间的时候，我们就可以使用solr的分布式索引了。在分布式索引中，原来的大索引，将会分成多个小索引，solr可以将这些小索引返回的结果合并，然后返回给客户端。

2、Solr Cloud的基本概念

SolrCloud模式下有Cluster，Node，Collection，Shard，LeaderCore，ReplicationCore等重要概念。
（1）Cluster集群：Cluster是一组Solr节点，逻辑上作为一个单元进行管理，整个集群必须使用同一套schema和SolrConfig。
（2）Node节点：一个运行Solr的JVM实例。
（3）Collection：在SolrCloud集群中逻辑意义上的完整的索引,常常被划分为一个或多个Shard，这些Shard使用相同的Config Set，如果Shard数超过一个，那么索引方案就是分布式索引。SolrCloud允许客户端用户通过Collection名称引用它，这样用户不需要关心分布式检索时需要使用的和Shard相关参数。
（4）Core: 也就是Solr Core，一个Solr中包含一个或者多个Solr Core，每个Solr Core可以独立提供索引和查询功能，Solr Core的提出是为了增加管理灵活性和共用资源。SolrCloud中使用的配置是在Zookeeper中的，而传统的Solr Core的配置文件是在磁盘上的配置目录中。
（5）Config Set: Solr Core提供服务必须的一组配置文件,每个Config Set有一个名字。最小需要包括solrconfig.xml和schema.xml，除此之外，依据这两个文件的配置内容，可能还需要包含其它文件,如中文索引需要的词库文件。Config Set存储在Zookeeper中，可以重新上传或者使用upconfig命令进行更新，可使用Solr的启动参数bootstrap_confdir进行初始化或更新。
（6）Shard分片: Collection的逻辑分片。每个Shard被分成一个或者多个replicas，通过选举确定哪个是Leader。
（7）Replica: Shard的一个拷贝。每个Replica存在于Solr的一个Core中。换句话说一个Solr Core对应着一个Replica，如一个命名为“test”的collection以numShards=1创建，并且指定replicationFactor为2，这会产生2个replicas，也就是对应会有2个Core，分别存储在不同的机器或者Solr实例上，其中一个会被命名为test_shard1_replica1，另一个命名为test_shard1_replica2，它们中的一个会被选举为Leader。
（8）Leader: 赢得选举的Shard replicas，每个Shard有多个Replicas，这几个Replicas需要选举来确定一个Leader。选举可以发生在任何时间，但是通常他们仅在某个Solr实例发生故障时才会触发。当进行索引操作时，SolrCloud会将索引操作请求传到此Shard对应的leader，leader再分发它们到全部Shard的replicas。

3、SolrCloud选举leader

首先调用setup方法保证选举初始化，主要是保证写在zookeeper上的信息节点存在。

加入选举队列实现

每个shard进入集群后，会在zookeeper上注册一个序列号类似，n_0000000001 or n_0000000003
应该是以active的状态记录,每次进入选举的队列里，都会先取得新的序列号，先进序列号越小，这个序列号对于选举leader很重要，每次选举leader会从最小的序列号做为leader，初次创建的时候，就会作为首选的leader。
至于每次有leader发生故障的时候，看检查自己是不是最小的那个序列号，如果是，则可以做一下leader的初始化工作，如果不是，至以当前第二小的做为新的leader看齐。
挂掉的leader的shard再成功起来的时候，照道理应该是改为最大的序列号，变为followe者。