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分布式索引基礎