Solr In Action 笔记(4) 之 SolrCloud分布式索引基础

标签：style   blog   http   io   color   ar   os   使用   sp   

Solr In Action 笔记(4) 之 SolrCloud Index 基础

     SolrCloud Index流程研究了两天，还是没有完全搞懂，先简单记下基础的知识，过几天再写个深入点的。先补充上前文来不及写的内容。

1. Solr.xml的重要配置

     Solr.xml的内容如下：

 1 <solr>
 2   <solrcloud>
 3     <str name="host">${host:}</str>
 4     <int name="hostPort">${jetty.port:8983}</int>
 5     <str name="hostContext">${hostContext:solr}</str>
 6     <int name="zkClientTimeout">${zkClientTimeout:15000}</int>
 7     <bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>
 8   </solrcloud>
 9   <shardHandlerFactory name="shardHandlerFactory"
10     class="HttpShardHandlerFactory">
11     <int name="socketTimeout">${socketTimeout:0}</int>
12     <int name="connTimeout">${connTimeout:0}</int>
13   </shardHandlerFactory>
14 </solr>

• host ， host 指的是Solr节点的IP地址，当Solr节点上线时候，它会向Zookeeper进行注册，注册信息如IP地址就会存储在/clusterstate.json中。这里不但可以直接使用host IP地址如192.168.1.0，也可以使用机器的hostname比如bigdata01。
• port ， port 指的时Solr用来监听的端口，默认是8983，同样它会存储在/clusterstate.json中。
• Solr Host Context， 指的是Solr.war部署的环境路径，多数情况下不用修改。
• zookeeper client timeout，上一节讲到过，zookeeper Znode节点变化最大反应时间。
• core node name, 该节点控制Solr core的命名策略，如果genericCoreNodeNames为true，那么Solr会给core取普通的名字比如，core_node1 ；如果设为true，则会给core取容易辨别的名字，比如带上host信息，比如10.0.1.7:8983_solr_logmill
• Leader Vote Wait Period：

     该参数并未直接在solr.xml中列出来，SolrCloud的leader和其他replica下线只剩最后一个replica的时候，这个Replica并不会立马选举leader，他会等待一段时间，查看leader是否上线，如果上线了，那么leader仍然还是leader，replica仍然还是replica，如果在这个时间段外leader没有上线，那么replica就变为leader了。这个时间就是Leader Vote Wait Period，它的存在防止了当leader和其他replica下线时候，具有旧的数据的node选为leader。

     比如以下一个例子，一个shard有两个node，X为leader，Y为replica，如果X在线，Y下线，那么X仍然可以接受update请求，SolrCloud仍然继续正常运行，只不过leader X不需要再把数据分发给Y了，Y上线后X只需要简单将数据同步给Y就行（Peer sync 策略)。如果X下线，Y在线，那么这个时候因为没有leader接受update请求以及没有leader转发数据，Y是不会接收到update请求的，所以这个时候的SolrCloud的所以建立是无法进行的，所以一旦X挂了SolrCloud就会进行leader选举，但是我们不能立马让Y变为leader，因为Y的数据相比较X来说是旧的数据。如果Y选举为Leader了，那么后续的update他就会接受，过段时间X上线了，由于Y已经是leader了所以X只能是replica，数据的流向变成了Y转发到X，这个时候就发现了奇怪的现象就是X中有部分数据新于Y（Y当选为leader前的数据），Y中有部分数据也新于X（Y当选为leader后的数据），这个时候就需要启动Snapshot replication 策略进行数据复原了，比较麻烦。如果设置了leaderVoteWait 那么X下线后，Y会等待leaderVoteWait时间，这个时间内update操作都是失败的，如果在这时间内X上线了，那么X立马恢复leader状态继续工作，否则就会Y就会变成leader。

     要改善这种情况，可以增加shard和replica的数量，较少leader和replica同时挂掉的可能性。

• zkHost，同样没有出现在上面的solr.xml上，它可以在solr.xml的zkHost配置中设置zookeepr集群信息比如192.168.0.1:2181,192.168.0.2:2181表示两个zookeeper组成一个zookeeper集群。

2. SolrCloud的分布式建索引

2.1 Document的Hash

          建好的SolrCloud集群每一个shard都会有一个Hash区间，当Document进行update的时候，SolrCloud就会计算这个Document的Hash值，然后根据该值和shard的hash区间来判断这个document应该发往哪个shard，所以首先让我们先来学习下SolrCloud的hash算法。

 明天继续，重点介绍下SolrCloud的hash

Solr In Action 笔记(4) 之 SolrCloud分布式索引基础

标签：style   blog   http   io   color   ar   os   使用   sp   

原文地址：http://www.cnblogs.com/rcfeng/p/4082568.html