Solr云(SolrCloud)簡介

    SolrCloud只是作為Solr的一個突出特性，這個特殊的特性能夠實現分布式功能。利用這個功能，你能建立高效、容錯的Solr服務器群。這對于訪問量規模巨大的企業級應用來說，使用SolrCloud能實現高有效性、容錯性、分布式索引和搜索功能。

1      了解SolrCloud

    千呼萬喚，始出來。期待已久，Solr4.1的版本終于發布了。Solr4包含的突出特性SolrCloud, 真的讓人眼前一亮。下面，讓就來探究一下SolrCloud。

1.1 了解SolrCores 與集合(Collections)

1.2 準備工作

下載最新的Solr穩定版本包(最新的是Solr 4.1,下載地址http://lucene.apache.org/solr/downloads.html)。為了便于演示，筆者采用實用cygwin (更多的信息，請參考http://cygwin.com/ )工具來執行腳本命令。

2 熟悉Solr Cloud

如果你對Solr還不太熟悉，建議先到Solr官網上查看一下具體的簡單介紹(Simple Tutorial)。在對于Solr有一定了解后，刪除Sample目錄下的你測試產生的相關數據。這樣能避免產生意外的錯誤，保證Demo能順利進行。

對于分布式配置和協調，Solr嵌入和使用了Zookeeper(更詳細的信息，請參考文檔http://zookeeper.apache.org/)作為一個倉庫--考慮到Zookepper能夠包含所有Solr服務器的信息的分布式文件系統。

2.1 簡單兩個片集群(ShardCluster)

                                                                 

   需要兩臺Solr服務器，可以復制一下已有example(下載的Solr4.2包，可以查看到這個目錄)。進入解壓后的目錄后，在cygwin窗口執行命令。

   cp -r example example01

   下面這個命令將會啟動Solr服務器以及啟動一個新的Solr集群。

          java -Djetty.port=8800 -Dbootstrap_confdir=./solr/collection1/conf

                  -Dcollection.configName=myconf-DzkRun -DnumShards=2 -jar start.jar

·        -DzkRun 觸發嵌入在Solr服務器中的Zookeeper運行。

·        -Dbootstrap_confdir=./solr/collection1/conf 既然我們還沒在Zookeeper中進行配置，這個參數引起本地的配置目錄./solr/上傳并且作為“myconfig”配置。這個名字“myconfig”是來自"collection.configName"得參數值。

·        -Dcollection.configName=myconf setsthe config to use for the new collection. Omitting this param will cause theconfig name to default to "configuration1". 設置新的集合(Collection)的配置去使用，忽略這個配置將會引起配置名默認為"configuration1"。

·        -DnumShards=2我們計劃分離索引到幾個邏輯分區，這個指定了對應數量。

·        -Djetty.port=8800設置Jetty服務器運行的端口，默認是8983。

瀏覽http://localhost:8800/solr/#/~cloud?view=rgraph，可以看到集群的狀態。點擊Tree，會發現我們的配置文件目錄已經上傳上去了，對應的config目錄也生產了。

    現在，然我們啟動第二個Solr服務器。它將會自動地賦給shard2，原因是我們沒有具體指定這個shard id值。

    java-Djetty.port=7800 -DzkHost=localhost:9983 -jar start.jar

    當我們指定-DzkHost=localhost:9800,是更具shard的Zookeeper的值來指定的。在沒

有指定Zookeeper端口的情況，嵌入在Solr中的Zookeeper默認為Sorl端口+1000，所以這里的Zookeeper的端口應該是9800。

接下來，建立一些索引文件。為了匆忙地完成，我們才采用 CloudSolrServer實現。

    cd exampledocs

    java-Durl=http://localhost:8800/solr/collection1/update -jar post.jar *.xml

在瀏覽器中輸入：http://localhost:8800/solr/collection1/select?q=*:*&wt=xml，可以得到以下結果。

2.2 簡單帶有片重復(shard replicas)的兩個片集群

    這個例子將會通過復制shard1和shard2來構建先前的例子，額外的備份的shard被用做來實現高有效性和容錯性，或是簡單地提升分布式查詢能力。

首先，保持先前的例子處于運行中。使用命令，復制這兩個實例。

    cp -r example01example01_replica

    cp -r example02example02_replica

    在每個彼此的窗口中開啟這兩個新的不同端口的服務器。

    java -Djetty.port=8801-DzkHost=localhost:9800 -jar start.jar

    java -Djetty.port=7801-DzkHost=localhost:9800 -jar start.jar

     瀏覽Zookeeper窗口http://localhost:8800/solr/#/~cloud，發現有效shard上圖所示。此刻，窗口的查詢日子和有關節點信息如下圖。

    你可以嘗試去關閉一個節點，看看查詢是否失效。一旦一個服務器中斷了，發送請求將會發送到剩余啟動的服務器。這時，你會繼續看到整個一樣的結果。如果我們 停掉某個幾點的所有服務器，這個請求對于這些服務器將會得到503錯誤。在shards中，返回僅僅這些存在于有效剩余有效shards的文檔，添加跟隨 的查詢參數便可以生效。

shards.tolerant=true

    SolrCloud使用的是實施細節的領導(Leader)和監督者。這意味著，一些nodes/replicas能夠扮演特殊的角色。你沒有必要擔心是 否這個失效的服務器是領導者還是分布式的監督者—如果你碰巧是他們中的一個失效，他們自動透明地選擇新的領導者或者新的監督者來回復使用者以及能無縫地負 責他們各自的工作。任何Solr實例都能提升作為他們對于角色之一。