SolrCloud(solr 雲)是Solr提供的分佈式搜索方案,當你須要大規模,容錯,分佈式索引和檢索能力時使用SolrCloud。當一個系統的索引數據量少的時候是不須要使用SolrCloud的,當索引量很大,搜索請求併發很高,這時須要使用SolrCloud來知足這些需求。SolrCloud是基於Solr和Zookeeper的分佈式搜索方案,它的主要是使用Zookeeper做爲集羣的配置信息中心。node
1)集中式的配置信息web
2)自動容錯數據庫
3)近實時搜索編程
4)查詢時自動負載均衡segmentfault
顧名思義zookeeper就是動物園管理員,他是用來管hadoop(大象)、Hive(蜜蜂)、pig(小豬)的管理員,Apache Hbase和Apache Solr 的分佈式集羣都用到了zookeeper;Zookeeper:是一個分佈式的、開源的程序協調服務,是hadoop項目下的一個子項目。瀏覽器
1、配置管理服務器
在咱們的應用中除了代碼外,還有一些就是各類配置。好比數據庫鏈接等。通常咱們都是使用配置文件的方式,在代碼中引入這些配置文件。可是當咱們只有一種配置,只有一臺服務器,而且不常常修改的時候,使用配置文件是一個很好的作法,可是若是咱們配置很是多,有不少服務器都須要這個配置,並且還多是動態的話使用配置文件就不是個好主意了。這個時候每每須要尋找一種集中管理配置的方法,咱們在這個集中的地方修改了配置,全部對這個配置感興趣的均可以得到變動。好比咱們能夠把配置放在數據庫裏,而後全部須要配置的服務都去這個數據庫讀取配置。可是,由於不少服務的正常運行都很是依賴這個配置,因此須要這個集中提供配置服務的服務具有很高的可靠性。通常咱們能夠用一個集羣來提供這個配置服務,可是用集羣提高可靠性,那如何保證配置在集羣中的一致性呢?這個時候就須要使用一種實現了一致性協議的服務了。Zookeeper就是這種服務,它使用Zab這種一致性協議來提供一致性。如今有不少開源項目使用Zookeeper來維護配置,好比在HBase中,客戶端就是鏈接一個Zookeeper,得到必要的HBase集羣的配置信息,而後才能夠進一步操做。還有在開源的消息隊列Kafka中,也使用Zookeeper來維護broker的信息。在Alibaba開源的SOA框架Dubbo中也普遍的使用Zookeeper管理一些配置來實現服務治理。網絡
2、名字服務架構
名字服務這個就很好理解了。好比爲了經過網絡訪問一個系統,咱們得知道對方的IP地址,可是IP地址對人很是不友好,這個時候咱們就須要使用域名來訪問。可是計算機是不能是別域名的。怎麼辦呢?若是咱們每臺機器裏都備有一份域名到IP地址的映射,這個卻是能解決一部分問題,可是若是域名對應的IP發生變化了又該怎麼辦呢?因而咱們有了DNS這個東西。咱們只須要訪問一個你們熟知的(known)的點,它就會告訴你這個域名對應的IP是什麼。在咱們的應用中也會存在不少這類問題,特別是在咱們的服務特別多的時候,若是咱們在本地保存服務的地址的時候將很是不方便,可是若是咱們只須要訪問一個你們都熟知的訪問點,這裏提供統一的入口,那麼維護起來將方便得多了。併發
3、分佈式鎖
其實在第一篇文章中已經介紹了Zookeeper是一個分佈式協調服務。這樣咱們就能夠利用Zookeeper來協調多個分佈式進程之間的活動。好比在一個分佈式環境中,爲了提升可靠性,咱們的集羣的每臺服務器上都部署着一樣的服務。可是,一件事情若是集羣中的每一個服務器都進行的話,那相互之間就要協調,編程起來將很是複雜。而若是咱們只讓一個服務進行操做,那又存在單點。一般還有一種作法就是使用分佈式鎖,在某個時刻只讓一個服務去幹活,當這臺服務出問題的時候鎖釋放,當即fail over到另外的服務。這在不少分佈式系統中都是這麼作,這種設計有一個更好聽的名字叫Leader Election(leader選舉)。好比HBase的Master就是採用這種機制。但要注意的是分佈式鎖跟同一個進程的鎖仍是有區別的,因此使用的時候要比同一個進程裏的鎖更謹慎的使用。
4、集羣管理
在分佈式的集羣中,常常會因爲各類緣由,好比硬件故障,軟件故障,網絡問題,有些節點會進進出出。有新的節點加入進來,也有老的節點退出集羣。這個時候,集羣中其餘機器須要感知到這種變化,而後根據這種變化作出對應的決策。好比咱們是一個分佈式存儲系統,有一箇中央控制節點負責存儲的分配,當有新的存儲進來的時候咱們要根據如今集羣目前的狀態來分配存儲節點。這個時候咱們就須要動態感知到集羣目前的狀態。還有,好比一個分佈式的SOA架構中,服務是一個集羣提供的,當消費者訪問某個服務時,就須要採用某種機制發現如今有哪些節點能夠提供該服務(這也稱之爲服務發現,好比Alibaba開源的SOA框架Dubbo就採用了Zookeeper做爲服務發現的底層機制)。還有開源的Kafka隊列就採用了Zookeeper做爲Cosnumer的上下線管理。
集羣的結構大體以下,一個zookeeper集羣負責管理配置文件和投票選舉,solr集羣共倆分片,每一個分片一主一僕。
1 # cd zookeeper1 2 # mkdir data 3 # echo 1 >> data/myid
1 cd conf # 進入zookeeper config目錄 2 cp zoo_sample.cfg zoo.cfg # 複製一份配置文件,並修改內
修改配置信息以下:
重點關注最後四行
dataDir:就是剛剛建立的目錄,有個myid文件表示當前節點id(咱們填的1)
clientPort:外部訪問solrcloud時鏈接的端口,由於solr交給zookeeper管理了
server.zookeeper_nodeId=zookeeper_ip:選舉端口:投票端口,選舉和投票在不一樣端口進行
# bin/zkServer.sh start # 啓動zookeeper
# bin/zkServer.sh stop # 關閉節點
節點所有啓動後,能夠查看節點狀態
# bin/zkServer.sh status
本次實驗目錄設置
solr7_conf是配置文件,要把該配置文件上傳到zookeeper管理,後面會說
三個zookeeper集羣,四個solr集羣,solr中的docs和example文件夾能夠刪除,以下圖
#修改 bin/solr.in.sh SOLR_HOST="本機ip" SOLR_PORT="程序運行端口" #分佈式時ip不同,端口同樣,僞分佈式時,ip同樣,端口不同 #可選操做 SOLR_PORT=8981 ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183" #若是不指定這兩個,能夠在solr啓動時指定
solr_home, 配置指定你建立的索引庫位置所在,默認就在安裝目錄的server/solr中
本人配置:
#solr1
SOLR_HOST="192.168.1.105" SOLR_PORT="8981"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#solr2
SOLR_HOST="192.168.1.105" SOLR_PORT="8982"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#solr3
SOLR_HOST="192.168.1.105" SOLR_PORT="8983"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#solr4
SOLR_HOST="192.168.1.105" SOLR_PORT="8984"
ZK_HOST="192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183"
#沒有在配置文件中指定ZK_HOST 和 SOLR_PORT的在啓動要指定
solr1/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8981 -force"
solr2/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8982 -force"
solr3/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8983 -force"
solr4/bin/solr start -cloud -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -p 8984 -force"
本次測試啓動:
solr1/bin/solr start -cloud -force"
solr2/bin/solr start -cloud -force"
solr3/bin/solr start -cloud -force"
solr4/bin/solr start -cloud -force"
參數解釋:
-c / -cloud 以solrcloud方式啓動
-z 指定zookeeper集羣的地址和客戶端鏈接端口,以逗號隔開
-p 指定端口
後兩個在有配置的狀況下能夠省
在任意一臺機器
$ /opt/solr-6.6.0/bin/solr create_collection -c collection1 -shards 2 -replicationFactor 2 -force
create_collection 建立集合,只有在cloud模式下有效
-c
指定庫(collection)名稱 -shards
指定分片數量,可簡寫爲 -s ,索引數據會分佈在這些分片上 -replicationFactor
每一個分片的副本數量,每一個碎片由至少1個物理副本組成
或者瀏覽器輸入:
http://192.168.1.105:8982/solr/admin/collections?action=CREATE&name=collection2&numShards=2&replicationFactor=2
配置文件上傳到ZooKeeper 集羣
可用參數(全部參數都是必需的)
-n <name>
在ZooKeeper中設置的配置名稱,能夠經過管理界面,點擊菜單,Cloud 選中 Tree / configs 下查看,配置列表 -d <configset dir>
配置設置爲上傳的路徑。路徑須要有一個「conf」目錄,依次包含solrconfig.xml等。最好能夠提供絕對路徑 -z <zkHost>
Zookeeper IP 端口,多個zk用"," 分隔
SolrCloud是經過Zookeeper集羣來保證配置文件的變動及時同步到各個節點上,因此,能夠將配置文件上傳到Zookeeper集羣。
$ solr1/bin/solr zk upconfig -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183 -n myconfig -d ../solr7_conf/conf
刪除上傳到ZooKeeper 集羣的solr 配置
rm
刪除-r
遞歸刪除
$ solr1/bin/solr zk rm -r /configs/myconfig -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183
響應
Connecting to ZooKeeper at node1:2181,node2:2181,node3:2181 ... Removing Zookeeper node /configs/mynewconfig from ZooKeeper at node1:2181,node2:2181,node3:2181 recurse: true
solr1/bin/solr status
配置目錄是否被其餘集合使用。若是沒有,那麼該目錄將從SolrCloud 集羣 中刪除
solr1/bin/solr delete -c collection1
有時候上面方法刪不掉,用下面這個
刪除collection1.
瀏覽器輸入:
http://192.168.1.105:8983/solr/admin/collections?action=DELETE&name=collection1
四個節點分別調用
bin/solr stop
$ bin/solr healthcheck -c test_collection -z 192.168.1.105:2181,192.168.1.105:2182,192.168.1.105:2183
# 若是指定了 ZK_HOST和端口,隨便找個節點目錄輸入輸入: bin/solr healthcheck -c collection
雖然solr如今支持頁面直接添加field域,可是fieldType仍是須要本身預先指定,因此要把配置文件從zookeeper中down下來,修改後再up上去(同名會自動覆蓋)
# down下來配置 solr1/bin/solr zk downconfig -n myconfig -d /home/conf 修改managed-schema,添加中文分詞器 以下: <fieldType name="text_ik" class="solr.TextField"> <analyzer class="org.wltea.analyzer.lucene.IKAnalyzer"/> </fieldType> 這樣就加入了中文分詞器IK 而後須要把相關jar包和IK的配置文件分別放在server/solr-webapps/webapp/WEB-INF下的lib和classes中 最後上傳配置文件便可 solr1/bin/solr zk upconfig -n myconfig -d /home/conf
效果圖:
最後用solrj測試下:
導入maven依賴
寫個測試程序:
單點測試:
集羣測試:待了解