深刻剖析SolrCloud（一）

 做者：洞庭散人

出處：http://phinecos.cnblogs.com/　　　　

本博客聽從Creative Commons Attribution 3.0 License，若用於非商業目的，您能夠自由轉載，但請保留原做者信息和文章連接URL。

 SolrCloud是基於Solr和Zookeeper的分佈式搜索方案，是正在開發中的Solr4.0的核心組件之一，它的主要思想是使用Zookeeper做爲集羣的配置信息中心。它有幾個特點功能：1）集中式的配置信息 2）自動容錯 3）近實時搜索 4）查詢時自動負載均衡 

 

基本能夠用上面這幅圖來概述，這是一個擁有4個Solr節點的集羣，索引分佈在兩個Shard裏面，每一個Shard包含兩個Solr節點，一個是Leader節點，一個是Replica節點，此外集羣中有一個負責維護集羣狀態信息的Overseer節點，它是一個總控制器。集羣的全部狀態信息都放在Zookeeper集羣中統一維護。從圖中還能夠看到，任何一個節點均可以接收索引更新的請求，而後再將這個請求轉發到文檔所應該屬於的那個Shard的Leader節點，Leader節點更新結束完成，最後將版本號和文檔轉發給同屬於一個Shard的replicas節點。

下面咱們來看一個簡單的SolrCloud集羣的配置過程。

首先去https://builds.apache.org/job/Solr-trunk/lastSuccessfulBuild/artifact/artifacts/下載Solr4.0的源碼和二進制包，注意Solr4.0如今還在開發中，所以這裏是Nightly Build版本。

示例1，簡單的包含2個Shard的集羣

這個示例中，咱們把一個collection的索引數據分佈到兩個shard上去，步驟以下：

爲了弄2個solr服務器，咱們拷貝一份example目錄

cp -r example example2

而後啓動第一個solr服務器，並初始化一個新的solr集羣，

cd example
java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar

-DzkRun參數是啓動一個嵌入式的Zookeeper服務器，它會做爲solr服務器的一部分，-Dbootstrap_confdir參數是上傳本地的配置文件上傳到zookeeper中去，做爲整個集羣共用的配置文件，-DnumShards指定了集羣的邏輯分組數目。

而後啓動第二個solr服務器，並將其引向集羣所在位置

cd example2
java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar

-DzkHost=localhost:9983就是指明瞭Zookeeper集羣所在位置

咱們能夠打開http://localhost:8983/solr/collection1/admin/zookeeper.jsp 或者http://localhost:8983/solr/#/cloud看看目前集羣的狀態，

如今，咱們能夠試試索引一些文檔，

cd exampledocs
java -Durl=http://localhost:8983/solr/collection1/update -jar post.jar ipod_video.xml
java -Durl=http://localhost:8983/solr/collection1/update -jar post.jar monitor.xml
java -Durl=http://localhost:8983/solr/collection1/update -jar post.jar mem.xml

最後，來試試分佈式搜索吧:

http://localhost:8983/solr/collection1/select?q

Zookeeper維護的集羣狀態數據是存放在solr/zoo_data目錄下的。

如今咱們來剖析下這樣一個簡單的集羣構建的基本流程：

先從第一臺solr服務器提及：

1)       它首先啓動一個嵌入式的Zookeeper服務器，做爲集羣狀態信息的管理者，

2） 將本身這個節點註冊到/node_states/目錄下

3） 同時將本身註冊到/live_nodes/目錄下

4）建立/overseer_elect/leader，爲後續Overseer節點的選舉作準備，新建一個Overseer，

5) 更新/clusterstate.json目錄下json格式的集羣狀態信息

6) 本機從Zookeeper中更新集羣狀態信息，維持與Zookeeper上的集羣信息一致

7）上傳本地配置文件到Zookeeper中，供集羣中其餘solr節點使用

8) 啓動本地的Solr服務器，

9) Solr啓動完成後，Overseer會得知shard中有第一個節點進來，更新shard狀態信息，並將本機所在節點設置爲shard1的leader節點，並向整個集羣發佈最新的集羣狀態信息。

10）本機從Zookeeper中再次更新集羣狀態信息，第一臺solr服務器啓動完畢。

而後來看第二臺solr服務器的啓動過程：

1） 本機鏈接到集羣所在的Zookeeper，

2） 將本身這個節點註冊到/node_states/目錄下

3）  同時將本身註冊到/live_nodes/目錄下

4） 本機從Zookeeper中更新集羣狀態信息，維持與Zookeeper上的集羣信息一致

5） 從集羣中保存的配置文件加載Solr所須要的配置信息

6） 啓動本地solr服務器，

7） solr啓動完成後，將本節點註冊爲集羣中的shard，並將本機設置爲shard2的Leader節點，

8） 本機從Zookeeper中再次更新集羣狀態信息，第二臺solr服務器啓動完畢。

示例2，包含2個shard的集羣，每一個shard中有replica節點

如圖所示，集羣包含2個shard，每一個shard中有兩個solr節點，一個是leader，一個是replica節點，

cp -r example exampleB
cp -r example2 example2B
cd exampleB
java -Djetty.port=8900 -DzkHost=localhost:9983 -jar start.jar
cd example2B
java -Djetty.port=7500 -DzkHost=localhost:9983 -jar start.jar

咱們能夠打開http://localhost:8983/solr/collection1/admin/zookeeper.jsp  看看包含4個節點的集羣的狀態，

 

 

這個集羣如今就具有容錯性了，你能夠試着幹掉一個Solr服務器，而後再發送查詢請求。背後的實質是集羣的ov erseer會監測各個shard的leader節點，若是leader節點掛了，則會啓動自動的容錯機制，會從同一個shard中的其餘replica節點集中從新選舉出一個leader節點，甚至若是overseer節點本身也掛了，一樣會自動在其餘節點上啓用新的overseer節點，這樣就確保了集羣的高可用性。

示例3 包含2個shard的集羣，帶shard備份和zookeeper集羣機制

 

上一個示例中存在的問題是：儘管solr服務器能夠容忍掛掉，但集羣中只有一個zookeeper服務器來維護集羣的狀態信息，單點的存在便是不穩定的根源。若是這個zookeeper服務器掛了，那麼分佈式查詢仍是能夠工做的，由於每一個solr服務器都會在內存中維護最近一次由zookeeper維護的集羣狀態信息，但新的節點沒法加入集羣，集羣的狀態變化也不可知了。所以，爲了解決這個問題，須要對Zookeeper服務器也設置一個集羣，讓其也具有高可用性和容錯性。

有兩種方式可選，一種是提供一個外部獨立的Zookeeper集羣，另外一種是每一個solr服務器都啓動一個內嵌的Zookeeper服務器，再將這些Zookeeper服務器組成一個集羣。 咱們這裏用後一種作示例：

cd example
java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DnumShards=2 -jar start.jar
cd example2
java -Djetty.port=7574 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -jar start.jar
cd exampleB
java -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -jar start.jar
cd example2B
java -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -jar start.jar

咱們能夠打開http://localhost:8983/solr/collection1/admin/zookeeper.jsp  看看包含4個節點的集羣的狀態，能夠發現其實和上一個沒有任何區別。

後續的文章將從實現層面對SolrCloud這個分佈式搜索解決方案進行進一步的深刻剖析。