NO IMAGE

總結下常用的幾個叢集,大概會涉及SolrCloud、Redis、FastDFS、Dubbo、訊息中介軟體(ActiveMq,RocketMq)。

                                                      ——吹雪

SolrCloud部分


SolrCloud環境:zookeeper-3.4.10,solr-7.0.1-2

SolrCloud架構圖為下圖左側,右側為Solr的Master-Slave。

solr架構

SolrCoud原理:

1、基於zk的分散式叢集協調功能來監視整個叢集中各節點的狀態,當節點出現問題時,通知其他節點,再利用zk的臨時節點特性來註冊watcher選舉出leader節點;基於zk的各節點資料的一致性來保證solr配置檔案在整個叢集中的資料一致性和高可用,註冊對配置檔案節點的watcher,可以感知配置檔案發生變化與否,可以達到啟用最新配置的目的。

2、索引分片,由於索引可能會很大,所以採取分而存之,將索引分成多個shard,每一個shard還可以有自己的備份。(副本:中文對於副本的解釋,一個複製物,我的理解是不包括本體,比如說副本有1個,那共有幾個,就是副本 本體=2個,但是好多從英文翻譯過來的資料,在統計副本個數時,都會包括本體,比如說副本是2,已經包含了本體,所以在語言文化上會導致一些不統一)

搭建SolrCloud需要的機器數:

SolrCloud叢集實際包括zookeeper和solr兩個叢集。

對於zookeeper叢集,根據奇數原則和過半原則,2*n+1,n取最小值:2*1+1=3,所以最少就是3個機子。

對於SolrCloud,由於是分片機制 備份機制,如有1個分片,那至少需要1個備份,就是2臺,這做到了高可用,但對於索引的大小變化,如索引越來越大一臺機子裝不下時,需要水平擴充套件。如有2個分片,每個分片至少一個備份,就是需要4臺機子。所以solr的數目在不分片時,至少是2臺。如果分片,至少是4臺。網上好多搭建環境時用3臺,這如何分片?分2片,那其中1片就沒有備份,分1片,只多出了一個副本,用處不大。到這裡,你可能會不同意,你會想到zookeeper的叢集3臺就可以。這是由於zookeeper的選舉leader演算法是zab協議,過半原則,而solr的leader選擇是利用了zookeeper的臨時節點特性,簡單理解就是:solr主節點掛掉時,剩餘從節點(也就是副本節點)會感知到這個事件,然後去建立zk的臨時節點,誰先建立成功誰就成為主節點。

綜上所述,我的理解,如果不分片,至少需要3臺zk 2臺solr=5臺(做到了高可用)。如果分片,至少需要3臺zk 4臺solr=7臺(做到了分散式和高可用)。

網上有不少文章,比如下圖中的搭建方式,在搭建SolrCloud時,用了3臺機子,分了2個片,3個副本,兩個片都是同一臺機子上,這樣做意義何在?既然都在同一臺機子,那分片幹什麼,分散式集叢集,難道不是分而治之,分而存之?可以為一個分片規劃N(最好大於1)個副本,但不同的分片最好是存不同的機子。這是我的理解。

3臺機子的solr搭建圖



安裝:

非原始碼包,解壓即可。

提示: (如果是原始碼包安裝,即安裝包名稱中有src的,解壓只是第一步,在linux下,安裝之前需要yum instal環境,然後.configure 檢查編譯環境,make對原始碼進行編譯,make insall 將生成的可執行檔案安裝到當前計算機中,最後修改配置檔案。redis、fastDFS、dubbo、nginx、keepalived、activeMq、RocketMq安裝都大同小異,基本上都這幾個步驟。)

我的solr是安裝在windows 7 64位機子上:

本地solr安裝示意

4個內容完全一致的solr,每一個啟動後都是一個solr例項,

埠號規劃:8986,8987,8988,8989

配置略過…

需要注意的是,在liux的.sh指令碼和windows的.cmd指令碼中,設定變數的區別:

.sh是

SOLR_JAVA_HOME=”C:\Java\jdk1.8.0_60″

ZK_HOST=”127.0.0.1:2181/solr”

SOLR_HOST=”127.0.0.1″

SOLR_TIMEZONE=”UTC 8″

而.cmd是

set SOLR_JAVA_HOME=”C:\Java\jdk1.8.0_60″

set ZK_HOST=”127.0.0.1:2181/solr”

set SOLR_HOST=”127.0.0.1″

set SOLR_TIMEZONE=”UTC 8″

啟動zk

……


上傳配置檔案至zk:

以下是常用的4個命令:

solrstart -cloud -p 8989    //啟動

solr stop-cloud -p 8989    //停止

solr zkupconfig -z 127.0.0.1:2181/solr -n store_config -d D:\solrhome\solr1\store_solr_config  //往zk上傳配置檔案

solr zk rm -z 127.0.0.1:2181 -r /solr/configs/store_config      //刪zk上的節點

上傳成功後,如下圖:

solr在zk上的節點

Solr節點對應整個叢集在zk上的根節點(是solrCloud的根,不是zk的根)。

從zk的zNode可以看出,solrCloud的大致設計思路,比如clusterstat.json存叢集的狀態資訊,collections目前是個葉子節點,其下什麼都沒有,configs存放配置檔案,live_nodes節點下是叢集中活動的機子,由於我們還沒啟動solr,所以目前該節點還是個葉子節點,啟動solr後,每一個solr例項都會在該節點下建立一個子節點。除此之外叢集中還有一個重要的角色——監控者,在叢集中任何機子都有資格精選監控者,監控者資訊在overseer_elect,監控者用來監控整個叢集的狀態,overseer下是監控者用來工作時的一些資源,比如佇列。

而SolrCloud正是利用了zk的特性從而做到了分散式協調:叢集有多少機子,每個機子的狀況,機子之間的互相通訊,主從節點的切換。

啟動SolrCloud

啟動示意

啟動成功後,solr告訴我們,Happysearching!開始快樂的搜尋旅程吧!

啟動失敗後,在solr的日誌檔案中可以找到詳細出錯資訊,進行除錯。

再檢視zk節點的變化:

啟動後solr節點在zk上的變化

在live_nodes下有4個節點。在electon節點下也有4個節點,還有一個leader節點,leader節點的內容:

/solr/overseer_celct/leader節點內容

這說明,監控者是8986埠的節點。在啟動solrCloud時,我就是最先啟動的8986節點,啟動後,8986埠的solr例項會先在/solr/overseer_celc/election節點下建立一個臨時節點順序節點,然後向/solr/overseer_celct/leader節點寫入內容,其他的節點啟動後,也同樣會在/solr/overseer_celc/election節點下建立一個臨時節點順序節點,然後會發現/solr/overseer_celct/leader節點已經有了資訊,而且檢視資訊內容,8986已經註冊成為監控者。

(這裡值的思考的是,對於監控者節點的選擇,為什麼不是在/solr/overseer_celct/leader下建立一個子節點,而是採用了在leader節點中寫入內容?根據zk的特性,多個客戶端向zk請求建立節點時,只會有一個建立成功,誰建立成功,誰就會有特殊的地位(在solrClound中便是監控者),但solr為什麼不這樣做?根據上圖中/solr/overseer_celct/leader節點的內容{“id”:”99492852084441148-127.0.0.1:8986_solr-n_0000000015″},注意最後的數字0000000015,再檢視election節點的子節點,發現0000000015是最小的編號,而擁有這個編號的8986節點在election節點下是存在的,所以承認8986的地位,這是利用了zk的順序節點的特性。對於solrCloud而言,誰編號最小誰就是監控者,而8986最先到達,建立順序節點時的編號最小,因此成為了監控者。由此也可見,solr的監控者選舉是通過election節點和leader兩個節點共同控制來完成的。這也給我們提供了一種選舉的思路,加上之前的提到過的臨時節點建立方式,以後有業務需要時也可以借鑑這兩種選舉做法。)

建立collection

我們有四個solr服務,訪問任意一個都可以,這正是叢集的好處,負載均衡 高可用,效能也很好。

建立collection

建立一個collection,shard分片我2,就是我們把這個索引分成兩份,放到兩臺機子上,進行分散式儲存,然後再為每一個shard加一個備份,加上本體,副本數一共是2。

匯入索引

在solr監控臺,匯入即可

檢視cloud圖

cloud圖

8987和8988為shard1下的主從,8987為leader節點。

8986和8989位shard2下的主從,8986位leader節點。

根據上邊啟動solr時的順序,8986-8987-8988-8989,可見8986和8987先啟動的兩臺率先分別註冊成為了兩個主節點。即使8988和8988都down掉,這個叢集還是可以工作的,只是沒有了備份。為了驗證,我們先關掉

8989節點。

此時cloud圖如下:

關掉8989節點後cloud圖

可以看到shard2只剩下了8986主節點。

查詢一下資料:

查詢資料

叢集可以工作。

再關掉8989後,cloud圖如下:

關掉8988後cloud圖

觀察zk

把關掉的8989和8988節點啟動,檢視zk節點狀態

4個solr都啟動後在zk上的節點示意

可以看出,shard下主節點也是利用zk的臨時順序節點特性來選舉出來的。

做個搜尋的小測試

兩條資料,第一條資料的店鋪名稱storeName為權重,第二條資料的擅長領域goodArea為權重,在搜尋時,我們輸入關鍵詞是權重,q為[storeName:權重OR goodArea:權重]返回的欄位中加入score(相關度得分)。可以發現是storeName為權重的資料排在了第一行,這條資料的相關度得分為2.25大於第二條資料的1.89。

現在,如何做才能讓第二條資料,就是goodAre為權重的資料排在前邊?

根據solr語法的,“^”可以用來提升相關度得分。將q改為[storeName:權重OR goodArea:權重^2],查詢結果如下:

可以看到goodArea為權重的資料排在了前邊,它的相關度得分變為了3.78,是之前得分1.89的2倍。

SolrCloud部分完。