大數據實戰之環境搭建(九)

好消息,好消息,江南最大皮革廠倒閉,老闆黃鶴吃喝嫖賭欠下3.5個億,攜帶小姨子跑了,我們沒有辦法,只能撬開倉庫拿皮包頂工資。原價100元的,200元的,500元的,現價只賣50元。黃鶴,你不是人,你還我血汗錢,還我血汗錢。現在賣皮包的人真是不容易啊,天天罵人家姓黃的不是人。


上節我們講述了Cassandra集羣的搭建,這節我們當然要講Solr 雲的搭建,實現分佈式搜索。Cassnadra集羣有什麼好處呢?動態擴展,集羣可以最大限度的實現數據容錯,試想,如果只有一臺機器來存儲數據,假如這臺機器所在的機房停電了或者着火了,那麼意味着應用程序將訪問不到這些數據源或者辛辛苦苦經營的數據化爲烏有,那麼Cassandra的集羣的工作原理是什麼呢?


在上一節我們在配置集羣的時候,配置了一個seeds節點在cassandra.yaml文件中。而且集羣中的所有節點的seeds配置都是一樣的,在Cassandra集羣之間有一個協議叫Gossip協議,這是一個稱之爲端到端的八卦協議。每個Cassandra集羣節點都靠這個協議互通信息,Gossip每秒都會向其他節點發送心跳探測,進行信息交換,確定彼此的狀態。seeds節點是cassandra中一個比較重要的節點,他負責和集羣中的其他節點通訊並獲取信息。對於cassandra的寫入和讀取操作,都是通過seeds節點均衡的請求其它的節點。那麼當集羣中一個節點Down了,Gossip會探測到,就不會將數據寫到這個down的節點上,但是還會繼續向這個節點發送心跳探測,只要這個節點恢復正常,會立即加入集羣進行工作,分擔負載。


那麼今天Solr雲怎麼搭建呢?其實也是很簡單的,首先給大家介紹一個網站

http://wiki.apache.org/solr/SolrCloud#schema.xml

專門講述Solr Cloud的,看懂了,搭建Solr雲是比較輕鬆的。


進入正題,我們看一下CentOS中的Solr Cloud如何搭建

首先我們將example複製一份叫example2,如果你是用puty等linux客戶端連接工具的話,進入solr目錄使用cp -r example example2命令拷貝。

我們看一下example下的東東

有一個solr文件夾,內容如下

包含MyTest的一個實例,多個SolrCore可以組成Solr的一個collection。那麼我們在此再創建一個實例,實現多實例,我們修改後的solr文件夾如下

增加了一個MyTest1的實例,並且將solr.xml的文件內容修改如下

<cores adminPath="/admin/cores" defaultCoreName="Bruce" host="${host:}" hostPort="${jetty.port:8983}" hostContext="${hostContext:solr}" zkClientTimeout="${zkClientTimeout:15000}">
  <core name="MyTest.UserInfo" instanceDir="MyTest" />
   <core name="MyTest.BonusInfo" instanceDir="MyTest1" />
</cores>

OK,那麼我們就實現了多實例的一個SolrCollection。OK,我們瀏覽一下

看到了吧,這就是在一個IP地址一個端口下多實例的實現,那麼在這裏我模擬一個簡單的業務,一個是用戶信息,一個是資金信息,這兩個共同組成一個用戶的一個資金管理業務。但是這種部署方式是省事了,也很簡單,佔用的機器也少,但是如果說這個192.168.192.128的機器因自然災害被毀,那麼辛苦經營的數據豈不是付之東流。所以目前大多數的用戶在使用Solr的時候,都是採用雲部署,從而實現分佈式搜索,通過簡單的拓撲結構,就可以避免部分機器over,導致整個數據的不完整或者無法使用。那麼下來我們就看一下傳說中的Solr Cloud。


首先,我們在上面提到的Solr-4.3.0目錄下有example和example2,兩個是完全一樣的複製品,首先我們要確保example/solr/MyTest/data下面是空的,沒有數據和索引文件。我麼要實現的是下面的集羣


接着進入到example命令,執行如下的命令

java -Djetty.port=8983 -Dbootstrap_confdir=./solr/MyTest/conf -Dcollection.configName=myconf-DzkRun -DnumShards=2 -jar

到這一步沒有錯誤算是啓動成功

在這裏我們可以看到集羣的一些信息。

那麼上面的這個命令是什麼意思呢?在此解釋一下

-Djetty.port=8983是設置jetty的啓動端口,jetty和Tomcat以及Jboss號稱三大web主流容器。

-DzkRun是觸發嵌入在SolrServer中的zookeeper運行

-Dbootstrap_confdir=./solr/MyTest/conf是將Solr的config上傳至zookeeper下,並且文件夾名稱爲

myconf。我們看一下上傳到zookeeper的myconf文件夾及內容


看到了吧,在這裏已經有了myconf文件夾,內容就是從solr/conf下面上傳過來的。-DnumShareds=2意思是我們要將索引劃分爲幾個邏輯分區。在這裏設置爲2,那麼我們的shareds就有兩個

因爲目前我只是啓動了一個機器,所以shared2還沒有映射的機器,等我再啓動一臺後,他會映射到shard2。好了我們再啓動一臺,看是否能映射到shared2。首先我們進入到example2目錄下,執行

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

解釋一下這段命令

-Djetty的意思是告訴jetty servlet容器使用另外的端口,-DzHost是指出剛纔我們運行的一個Solr Server中嵌入的zookeeper的地址,官網解釋是zookeeper的端口爲solr的端口加上1000,所以在這裏是9983。OK我們再看一下Solr雲

看到了吧,出現了兩個分片,那麼寫數據的時候可能有些數據寫在shared1上,有些寫在shared2上,但是我們在檢索數據的時候,會返回一個完整的結果,這就是一個簡單的雲部署。

那麼當我們再啓動幾臺機器會怎麼樣呢?因爲我們指定了只能有兩個邏輯分區,那麼當我們啓動第三臺機器的時候,他就作爲shard1的複製品,如果再啓動一個機器,他就作爲shard2的複製品。ok,我們現在來試一下,由於我只有一個虛擬機和一臺windows7機器,所以我打算在windows上啓動2個solr,那麼他們會自動加入shard1和shard2。那到底是不是這樣呢?我用同樣的命令啓動了一個windows上的solr,報錯,錯誤原因至今沒找到,或者說壓根就是個錯誤的嘗試。那我們再複製兩個example,如下

OK,我們用如下的命令在啓動一個機器

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

我們再看一下solr cloud有沒有變化,輸入http://192.168.192.128:8983/solr/#/~cloud,我們發現shard1多了一個複製品

其拓撲圖如下

這個實驗驗證了我們所說的,第三臺機器會作爲第一臺機器的一個複製品。

我們在啓動一臺機器,這個節點將作爲第二臺機器的複製品

其拓撲結構如下

上面的拓撲結構就是我們實現的分區爲2,複製品爲1的solr 集羣

OK,如果我們有機器資源的話,只需要在不同的機器上像這樣啓動,就可以搭建出一個solr cloud。由於本人機器有限,只能用同一個IP給大家做演示。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章