基本可以用上面這幅圖來概述，這是一個擁有4個Solr節(jié)點的集群，索引分布在兩個Shard里面，每個Shard包含兩個Solr節(jié)點，一個是Leader節(jié)點，一個是Replica節(jié)點，此外集群中有一個負(fù)責(zé)維護(hù)集群狀態(tài)信息的Overseer節(jié)點，它是一個總控制器。集群的所有狀態(tài)信息都放在Zookeeper集群中統(tǒng)一維護(hù)。從圖中還可以看到，任何一個節(jié)點都可以接收索引更新的請求，然后再將這個請求轉(zhuǎn)發(fā)到文檔所應(yīng)該屬于的那個Shard的Leader節(jié)點，Leader節(jié)點更新結(jié)束完成，最后將版本號和文檔轉(zhuǎn)發(fā)給同屬于一個Shard的replicas節(jié)點。
下面我們來看一個簡單的SolrCloud集群的配置過程。
首先去https://builds.apache.org/job/Solr-trunk/lastSuccessfulBuild/artifact/artifacts/下載Solr4.0的源碼和二進(jìn)制包，注意Solr4.0現(xiàn)在還在開發(fā)中，因此這里是Nightly Build版本。
示例1，簡單的包含2個Shard的集群
這個示例中，我們把一個collection的索引數(shù)據(jù)分布到兩個shard上去，步驟如下：
為了弄2個solr服務(wù)器，我們拷貝一份example目錄
然后啟動第一個solr服務(wù)器，并初始化一個新的solr集群，
-DzkRun參數(shù)是啟動一個嵌入式的Zookeeper服務(wù)器，它會作為solr服務(wù)器的一部分，-Dbootstrap_confdir參數(shù)是上傳本地的配置文件上傳到zookeeper中去，作為整個集群共用的配置文件，-DnumShards指定了集群的邏輯分組數(shù)目。
然后啟動第二個solr服務(wù)器，并將其引向集群所在位置
-DzkHost=localhost:9983就是指明了Zookeeper集群所在位置
我們可以打開http://localhost:8983/solr/collection1/admin/zookeeper.jsp 或者http://localhost:8983/solr/#/cloud看看目前集群的狀態(tài)，
現(xiàn)在，我們可以試試索引一些文檔，
最后，來試試分布式搜索吧:
http://localhost:8983/solr/collection1/select?q
Zookeeper維護(hù)的集群狀態(tài)數(shù)據(jù)是存放在solr/zoo_data目錄下的。
現(xiàn)在我們來剖析下這樣一個簡單的集群構(gòu)建的基本流程：
先從第一臺solr服務(wù)器說起：
1) 它首先啟動一個嵌入式的Zookeeper服務(wù)器，作為集群狀態(tài)信息的管理者，
2） 將自己這個節(jié)點注冊到/node_states/目錄下
3） 同時將自己注冊到/live_nodes/目錄下
4）創(chuàng)建/overseer_elect/leader，為后續(xù)Overseer節(jié)點的選舉做準(zhǔn)備，新建一個Overseer，
5) 更新/clusterstate.json目錄下json格式的集群狀態(tài)信息
6) 本機從Zookeeper中更新集群狀態(tài)信息，維持與Zookeeper上的集群信息一致
7）上傳本地配置文件到Zookeeper中，供集群中其他solr節(jié)點使用
8) 啟動本地的Solr服務(wù)器，
9) Solr啟動完成后，Overseer會得知shard中有第一個節(jié)點進(jìn)來，更新shard狀態(tài)信息，并將本機所在節(jié)點設(shè)置為shard1的leader節(jié)點，并向整個集群發(fā)布最新的集群狀態(tài)信息。
10）本機從Zookeeper中再次更新集群狀態(tài)信息，第一臺solr服務(wù)器啟動完畢。
然后來看第二臺solr服務(wù)器的啟動過程：
1） 本機連接到集群所在的Zookeeper，
2） 將自己這個節(jié)點注冊到/node_states/目錄下
3） 同時將自己注冊到/live_nodes/目錄下
4） 本機從Zookeeper中更新集群狀態(tài)信息，維持與Zookeeper上的集群信息一致
5） 從集群中保存的配置文件加載Solr所需要的配置信息
6） 啟動本地solr服務(wù)器，
7） solr啟動完成后，將本節(jié)點注冊為集群中的shard，并將本機設(shè)置為shard2的Leader節(jié)點，
8） 本機從Zookeeper中再次更新集群狀態(tài)信息，第二臺solr服務(wù)器啟動完畢。
示例2，包含2個shard的集群，每個shard中有replica節(jié)點
如圖所示，集群包含2個shard，每個shard中有兩個solr節(jié)點，一個是leader，一個是replica節(jié)點，
我們可以打開http://localhost:8983/solr/collection1/admin/zookeeper.jsp 看看包含4個節(jié)點的集群的狀態(tài)，
這個集群現(xiàn)在就具備容錯性了，你可以試著干掉一個Solr服務(wù)器，然后再發(fā)送查詢請求。背后的實質(zhì)是集群的ov erseer會監(jiān)測各個shard的leader節(jié)點，如果leader節(jié)點掛了，則會啟動自動的容錯機制，會從同一個shard中的其他replica節(jié)點集中重新選舉出一個leader節(jié)點，甚至如果overseer節(jié)點自己也掛了，同樣會自動在其他節(jié)點上啟用新的overseer節(jié)點，這樣就確保了集群的高可用性。
示例3 包含2個shard的集群，帶shard備份和zookeeper集群機制
上一個示例中存在的問題是：盡管solr服務(wù)器可以容忍掛掉，但集群中只有一個zookeeper服務(wù)器來維護(hù)集群的狀態(tài)信息，單點的存在即是不穩(wěn)定的根源。如果這個zookeeper服務(wù)器掛了，那么分布式查詢還是可以工作的，因為每個solr服務(wù)器都會在內(nèi)存中維護(hù)最近一次由zookeeper維護(hù)的集群狀態(tài)信息，但新的節(jié)點無法加入集群，集群的狀態(tài)變化也不可知了。因此，為了解決這個問題，需要對Zookeeper服務(wù)器也設(shè)置一個集群，讓其也具備高可用性和容錯性。
有兩種方式可選，一種是提供一個外部獨立的Zookeeper集群，另一種是每個solr服務(wù)器都啟動一個內(nèi)嵌的Zookeeper服務(wù)器，再將這些Zookeeper服務(wù)器組成一個集群。 我們這里用后一種做示例：
我們可以打開http://localhost:8983/solr/collection1/admin/zookeeper.jsp 看看包含4個節(jié)點的集群的狀態(tài)，可以發(fā)現(xiàn)其實和上一個沒有任何區(qū)別。
后續(xù)的文章將從實現(xiàn)層面對SolrCloud這個分布式搜索解決方案進(jìn)行進(jìn)一步的深入剖析。
