solr雲的簡單搭建（了解）

 

1、認識系統架構

1.1、集群概述

1.1.1、單點服務器的問題

我們之所以要學習集群，是因為單點服務器，存在一系列的問題。

 

我們以前學習的JavaEE項目，都是部署在一台Tomcat上，所有的請求，都由這一台服務器處理，存在很大風險：

A：並發處理能力有限。因為單服務器的性能有限制。所以單台Tomcat的最大連接數有限制， 

B：容錯率低，一旦服務器故障，整個服務就無法訪問了。

eBay於 1999年6月停機22小時的事故，中斷了約230萬的拍賣，使eBay的股票下降了9.2個百分點。

C：單台服務器計算能力低，無法完成復雜的海量數據計算。

提高CPU主頻和總線帶寬是最初提供計算機性能的主要手段。但是這一手段對系統性能的提供是有限的。接着人們通過增加CPU個數和內存容量來提高性能，於是出現了向量機，對稱多處理機(SMP)等。但是當CPU的個數超過某一閾值，這些多處理機系統的可擴展性就變的極差。主要瓶頸在於CPU訪問內存的帶寬並不能隨着CPU個數的增加而有效增長。與SMP相反，集群系統的性能隨着CPU個數的增加幾乎是線性變化的

 

 

 

1.1.2、集群的特點

集群是是指將多台服務器集中在一起，每台服務器都實現相同的業務，做相同的事情。但是每台服務器並不是缺一不可，存在的作用主要是緩解並發壓力和單點故障轉移問題。可以利用一些廉價的符合工業標准的硬件構造高性能的系統。實現：高擴展、高性能、低成本、高可用！

 

Apache 

注意：該圖中最大的特點就是，每個Tomcat都完成相同的業務，但是分擔着不同用戶的訪問，它們並不是缺一不可，如果一個Tomcat出現故障，網站依舊可以運行。

 

 

 

伸縮性（Scalability）

在一些大的系統中，預測最終用戶的數量和行為是非常困難的，伸縮性是指系統適應不斷增長的用戶數的能力。提高這種並發會話能力的一種最直觀的方式就增加資源（CPU，內存，硬盤等），集群是解決這個問題的另一種方式，它允許一組服務器組在一起，像單個服務器一樣分擔處理一個繁重的任務，我們只需要將新的服務器加入集群中即可，對於客戶來看，服務無論從連續性還是性能上都幾乎沒有變化，好像系統在不知不覺中完成了升級

 

高可用性（High availability）

單一服務器的解決方案並不是一個健壯方式，因為容易出現單點失效。像銀行、賬單處理這樣一些關鍵的應用程序是不能容忍哪怕是幾分鍾的死機。它們需要這樣一些服務在任何時間都可以訪問並在可預期的合理的時間周期內有響應。高可用性集群的出現是為了使集群的整體服務盡可能可用，以便考慮計算硬件和軟件的易錯性。如果高可用性集群中的主節點發生了故障，那么這段時間內將由次節點代替它。次節點通常是主節點的鏡像，所以當它代替主節點時，它可以完全接管其身份，並且因此使系統環境對於用戶是一致的。

 

負載均衡（Load balancing）

負載均衡集群為企業需求提供了更實用的系統。如名稱所暗示的，該系統使負載可以在計算機集群中盡可能平均地分攤處理。該負載可能是需要均衡的應用程序處理負載或網絡流量負載。這樣的系統非常適合於運行同一組應用程序的大量用戶。每個節點都可以處理一部分負載，並且可以在節點之間動態分配負載，以實現平衡。

 

高性能 (High Performance )

通常，第一種涉及為集群開發並行編程應用程序，以解決復雜的科學問題。這是並行計算的基礎，盡管它不使用專門的並行超級計算機，這種超級計算機內部由十至上萬個獨立處理器組成。但它卻使用商業系統，如通過高速連接來鏈接的一組單處理器或雙處理器 PC，並且在公共消息傳遞層上進行通信以運行並行應用程序。因此，您會常常聽說又有一種便宜的 Linux 超級計算機問世了。但它實際是一個計算機集群，其處理能力與真的超級計算機相等

 

Erp hr crm

項目經理

 

互聯網

技術總監 架構師

1.2、分布式架構

1.2.1、傳統架構

 

 

A：系統過於龐大，開發維護困難

B：功能間耦合度太高

C：無法針對單個模塊進行優化

D：無法進行水平擴展

 

 

1.2.2、分布式架構

分布式是指將多台服務器集中在一起，每台服務器都實現總體中的不同業務，做不同的事情。並且每台服務器都缺一不可，如果某台服務器故障，則網站部分功能缺失，或導致整體無法運行。存在的主要作用是大幅度的提高效率，緩解服務器的訪問和存儲壓力。

 

 

 

 

網站首頁

用戶管理

訂單系統

商品系統

 

注意：該圖中最大特點是：每個Web服務器（Tomcat）程序都負責一個網站中不同的功能，缺一不可。如果某台服務器故障，則對應的網站功能缺失，也可以導致其依賴功能甚至全部功能都不能夠使用。

 

 

因此，分布式系統需要運行在集群服務器中，甚至分布式系統的每個不同子任務都可以部署集群 

 

 

1.3、分布式集群綜合架構

一般分布式中的每一個節點，都可以做集群。這樣的系統架構，我們通常稱為分布式集群架構。

 

 

 

 

activeMQ

mycat

 

1.4、代理技術

1.4.1、正向代理（Forward Proxy）

 

 

 

一般情況下，如果沒有特別說明，代理技術默認說的是正向代理技術。關於正向代理的概念如下： 正向代理(forward)是一個位於客戶端【用戶A】和原始服務器(origin server)【服務器B】之間的服務器【代理服務器Z】，為了從原始服務器取得內容，用戶A向代理服務器Z發送一個請求並指定目標(服務器B)，然后代理服務器Z向服務器B轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。

 

簡單來說，正向代理就是代理服務器替代訪問方【用戶A】去訪問目標服務器【服務器B】

 

為什么需要使用正向代理？

 

1、 訪問本無法訪問的服務器B

great firewall

被服務器屏蔽（wow）

2、加速訪問服務器B

 

 

 

3、Cache作用

如果在用戶A訪問服務器B某數據J之前，已經有人通過代理服務器Z訪問過服務器B上得數據J，那么代理服務器Z會把數據J保存一段時間，如果有人正好取該數據J，那么代理服務器Z不再訪問服務器B，而把緩存的數據J直接發給用戶A。

 

4、客戶端訪問授權

 

5、隱藏訪問者的行蹤

服務器B並不知道訪問自己的實際是用戶A，因為代理服務器Z代替用戶A去直接與服務器B進行交互。如果代理服務器Z被用戶A完全控制（或不完全控制），會慣以“肉雞”術語稱呼。 

 

總結一下：正向代理是一個位於客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內容，客戶端向代理發送一個請求並指定目標(原始服務器)，然后代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端必須設置正向代理服務器，當然前提是要知道正向代理服務器的IP地址，還有代理程序的端口。

 

1.4.2、反向代理（reverse proxy）

反向代理正好與正向代理相反，對於客戶端而言代理服務器就像是原始服務器，並且客戶端不需要進行任何特別的設置。客戶端向反向代理的命名空間(name-space)中的內容發送普通請求，接着反向代理將判斷向何處(原始服務器)轉交請求，並將獲得的內容返回給客戶端。 使用反向代理服務器的作用如下：

 

1、保護和隱藏原始資源服務器

 

 

 

用戶A始終認為它訪問的是原始服務器B而不是代理服務器Z，但實用際上反向代理服務器接受用戶A的應答，從原始資源服務器B中取得用戶A的需求資源，然后發送給用戶A。由於防火牆的作用，只允許代理服務器Z訪問原始資源服務器B。在這個虛擬的環境下，防火牆和反向代理的共同作用保護了原始資源服務器B，但用戶A並不知情。

 

2、負載均衡

 

 

192.168.56.101

當反向代理服務器不止一個的時候，我們甚至可以把它們做成集群，當更多的用戶訪問資源服務器B的時候，讓不同的代理服務器Z（x）去應答不同的用戶，然后發送不同用戶需要的資源。

而且反向代理服務器像正向代理服務器一樣擁有CACHE的作用，它可以緩存原始資源服務器B的資源，而不是每次都要向原始資源服務器B請求數據，特別是一些靜態的數據，比如圖片和文件。

 

簡單來說，反向代理就是反向代理服務器替代原始服務器【服務器B】讓【用戶A】去訪問

 

*****************************************************************************************************

2、Zookeeper分布式協調服務

2.1、什么是Zookeeper

Zookeeper是集群分布式中大管家

 

分布式集群系統比較復雜，子模塊很多，但是子模塊往往不是孤立存在的，它們彼此之間需要協作和交互，各個子系統就好比動物園里的動物，為了使各個子系統能正常為用戶提供統一的服務，必須需要一種機制來進行協調——這就是ZooKeeper

 

Zookeeper 是為分布式應用程序提供高性能協調服務的工具集合，也是Google的Chubby一個開源的實現，是Hadoop 的分布式協調服務。

 

 

2.2、Zookeeper的集群結構

 

 

 

在ZooKeeper集群當中，集群中的服務器角色有兩種：1個Leader和多個Follower，具體功能如下：

1）領導者(leader)，負責進行投票的發起和決議，監控集群中的節點是否存活（心跳機制），進行分配資源

2）follower用於接受客戶端請求並向客戶端返回結果，在選主過程中參與投票

特點：

A：Zookeeper：一個leader，多個follower組成的集群

B：全局數據一致：每個server保存一份相同的數據副本，client無論連接到哪個server，數據都是一致的

C：數據更新原子性，一次數據更新要么成功，要么失敗

D：實時性，在一定時間范圍內，client能讀到最新數據

E：半數機制：整個集群中只要有一半以上存活，就可以提供服務。因此通常Zookeeper由2n+1台servers組成，每個server都知道彼此的存在。每個server都維護的內存狀態鏡像以及持久化存儲的事務日志和快照。為了保證Leader選舉能過得到多數的支持，所以ZooKeeper集群的數量一般為奇數。對於2n+1台server，只要有n+1台（大多數）server可用，整個系統保持可用

 

 

2.3、Zookeeper的leader選主機制

2.3.1、全新集群

以一個簡單的例子來說明整個選舉的過程.
假設有五台服務器組成的zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的.假設這些服務器依序啟動,來看看會發生什么.
1) 服務器1啟動,此時只有它一台服務器啟動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是LOOKING狀態
2) 服務器2啟動,它與最開始啟動的服務器1進行通信,互相交換自己的選舉結果,由於兩者都沒有歷史數據,所以id值較大的服務器2勝出,但是由於沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3),所以服務器1,2還是繼續保持LOOKING狀態.
3) 服務器3啟動,根據前面的理論分析,服務器3成為服務器1,2,3中的老大,而與上面不同的是,此時有三台服務器選舉了它,所以它成為了這次選舉的leader.
4) 服務器4啟動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中最大的,但是由於前面已經有半數以上的服務器選舉了服務器3,所以它只能接收當小弟的命了.
5) 服務器5啟動,同4一樣,當小弟.

 

 

2.3.2、非全新集群

那么，初始化的時候，是按照上述的說明進行選舉的，但是當zookeeper運行了一段時間之后，有機器down掉，重新選舉時，選舉過程就相對復雜了。

需要加入數據id、leader id和邏輯時鍾。

數據id：數據新的id就大，數據每次更新都會更新id。

Leader id：就是我們配置的myid中的值，每個機器一個。

邏輯時鍾：這個值從0開始遞增,每次選舉對應一個值,也就是說:  如果在同一次選舉中,那么這個值應該是一致的 ;  邏輯時鍾值越大,說明這一次選舉leader的進程最新.

選舉的標准就變成：

1、邏輯時鍾小的選舉結果被忽略，重新投票

2、統一邏輯時鍾后，數據id大的勝出

3、數據id相同的情況下，leader id大的勝出

根據這個規則選出leader。

 

 

2.4、Zookeeper的作用

Zookeeper包含一個簡單的原語集，分布式應用程序可以基於它實現命名服務、配置維護、集群選主等：

命名服務：注冊節點信息，形成有層次的目錄結構（類似Java的包名）。

配置維護：配置信息的統一管理和動態切換

集群選主：確保整個集群中只有一個主，其它為從。並且當主掛了后，可以自動選主

 

 

3、SolrCloud概述

3.1、什么是SolrCloud

單點的Solr服務：

A：能存儲的數據量有限，如果是海量數據，無法存儲

B：容易出現單點故障

C：對高並發的處理能力差

 

如果我們的需要處理海量數據、應對高並發請求，並且讓我們的服務實現高可用。那么就必須要搭建SolrCloud了。反之，如果數據量很少，請求並發低的情況下，是不需要SolrCloud的，單點Solr就夠了

 

SolrCloud(solr 雲)是Solr提供的分布式搜索方案，可以解決海量數據的 分布式全文檢索，因為搭建了集群，因此具備高可用的特性，同時對數據進行主從備份，避免了單點故障問題。可以做到數據的快速恢復。並且可以動態的添加新的節點，再對數據進行平衡

 

 

3.2、SolrCloud結構簡介

 

為了實現海量數據的存儲，我們會把索引進行分片（Shard），把分片后的數據存儲到不同Solr節點。

 

為了保證節點數據的高可用，避免單點故障，我們又會對每一個Shard進行復制，產生很多副本（Replicas），每一個副本對於一個Solr節點中的一個core

 

用戶訪問的時候，可以訪問任何一個會被自動分配到任何一個可用副本進行查詢，這樣就實現了負載均衡。

 

邏輯結構：

 

 

 

 

Collection：在SolrCloud集群中邏輯意義上的完整的索引。一般會包含多個Shard（分片），如果大於1個分片，那么就是分布式存儲。

 

Shard: Collection的邏輯分片。每個Shard被化成一個或者多個replicas（副本），通過選舉確定哪個是Leader（主），其它為從

 

Replica: Shard的一個副本，存儲在Solr集群的某一台機器中（就是一個節點），對應這台Solr的一個Core。

 

Leader: 贏得選舉的Shard replicas。每個Shard有多個Replicas，這幾個Replicas需要選舉來確定一個Leader。選舉可以發生在任何時間，但是通常他們僅在某個Solr實例發生故障時才會觸發。當索引documents時，SolrCloud會傳遞它們到此Shard對應的leader，leader再分發它們到全部Shard的replicas

 

 

 

 

 

 

 

 

分片數量越多，每一片的數據就越少，每一個副本的數據就越少。但是一般不要多於機器數量

分片數量越少，每一片的數據就越多，每一個副本的數據就越多。

 

副本數量越少，總數據量越少， 這樣可以減少每一台機器上的數據量，會降低高可用性，提高數據存儲上限。

副本數量越多，總數據量越多，會增加每一台機器上的數據量，但是會提高整個集群的高可用性。

 

 

 

4、SolrCloud的搭建

 

4.1、基本環境

我們需要三台服務器，也就是三台虛擬機。分別是：

192.168.56.101

192.168.56.102

192.168.56.103

每台機器上都需要部署以下環境：

JDK：基本Java運行環境

Tomcat：裝載Solr服務

Solr-4.10.2：Solr服務

Zookeeper：對Solr雲進行管理

 

理論上應該給每台機器分別安裝，但是我們是虛擬機，我們可以先安裝一台，然后把虛擬機進行復制！

 

 

4.2、單機部署

4.2.1、Centos6.5安裝

參見昨天筆記

4.2.2、JDK安裝

參見昨天筆記

4.2.3、Tomcat安裝

參見昨天筆記

 

4.2.4、Solr安裝

1）上傳Solr的安裝包到 /usr/local/myapp目錄

 

 

 

2）解壓

tar –zxvf solr-4.10.2.tgz

 

 

 

3）將solr-4.10.2/example/solr/webapps/solr.war復制到tomcat的webapps目錄下

 

cp /usr/local/myapp/solr-4.10.2/example/webapps/solr.war /usr/local/myapp/apache-tomcat-7.0.57/webapps/

 

4）進入tomcat的webapps目錄解壓縮solr.war

unzip -oq solr.war -d solr

 

5）上傳依賴包到solr/WEB-INF/下

 

 

 

 

6）修改tomcat的bin目錄下的catalina.sh文件，添加啟動的參數，指向solr的索引文件夾

export JAVA_OPTS=-Dsolr.solr.home=/usr/local/myapp/solr-4.10.2/example/solr

 

7）啟動tomcat，訪問：http://192.168.56.101:8080/solr 查看單點Solr部署情況

 

4.2.5、zookeeper安裝

1）上傳zookeeper的安裝包

 

 

2）解壓縮安裝包

tar -zxvf zookeeper-3.4.5.tar.gz

 

3）重命名目錄（可選）

某些機器無法識別標點，因此我們可以把目錄的名稱做修改：

mv zookeeper-3.4.5 zookeeper

 

 

4）修改配置文件

A：進入zookeeper/conf目錄

B：復制模板文件

cp zoo_sample.cfg  zoo.cfg

C：修改配置文件信息，添加以下內容

vi zoo.cfg

要添加的內容：

dataDir=/usr/local/myapp/zookeeper/data

dataLogDir=/usr/local/myapp/zookeeper/log

server.1=192.168.56.101:2888:3888

server.2=192.168.56.102:2888:3888

server.3=192.168.56.103:2888:3888

 

 

注意：模板文件中已經有一個dataDir參數，我們一定要把這個刪除，或者在這個基礎上修改

 

 

 

dataDir：數據目錄

dataLogDir：日志目錄

server.1=x.x.x.x:port1:port2 指定所有zookeeper的節點信息

server后的數字是節點ID，port1是心跳端口，port2是數據端口

 

 

5）創建數據目錄和日志目錄

我們在配置文件里指定了數據和日志目錄。所以我們需要創建這些目錄

A：先進入zookeeper目錄

B：創建目錄

mkdir -m 755 data

mkdir -m 755 log

這樣兩個命令可以在創建目錄的同時指定文件夾的權限

6）添加節點ID信息

進入data目錄，創建文件myid，並且寫上ID信息：1

vi myid

插入id：1

 

 

 

注意，其它節點的ID必須與配置文件中的ID一直，分別是2和3

7）配置zookeeper的環境變量，可以在任何位置使用zookeeper命令

A：vi /etc/profile(修改文件)

B：添加內容：

export ZOOKEEPER_HOME=/usr/local/myapp/zookeeper

export PATH=$PATH:$ZOOKEEPER_HOME/bin

C：重新編譯文件：

source /etc/profile

 

8）zookeeper命令：

啟動zookeeper：  zkServer.sh start

停止zookeeper：  zkServer.sh stop

查看狀態： zkServer.sh status

9）如果出現錯誤：

先stop 掉原zk

zkServer.sh stop

然后以./zkServer.sh start-foreground方式啟動，會看到啟動日志

zkServer.sh start-foreground

 

1. 上傳解壓
2. 重命名
3. 修改配置文件/conf/zoo.cfg 
4. 創建數據目錄，log日志目錄
5. 在數據目錄下創建myid文件，內容：1
6. 啟動

4.3、集群部署

4.3.1、修改tomcat啟動文件，添加zookeeper的地址信息

 

修改：tomcat文件夾下的bin目錄中的catalina.sh文件，添加以下信息：

 

export JAVA_OPTS="-Dsolr.solr.home=/usr/local/myapp/solr-4.10.2/example/solr -DzkHost=192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181"

 

-Dsolr.solr.solr.home指定的是Solr索引庫位置

-DzkHost指定的是三個zookeeper的ip和客戶端端口信息

 

這樣tomcat啟動后，solr服務就可以到zookeeper中注冊自己的信息，或者獲取其它節點信息。

 

 

4.3.2、復制虛擬機（也可以重新安裝）

 

1）復制虛擬機，這里我們復制2台即可。復制前請先關閉itcast虛擬機

 

 

 

2）修改其它2台虛擬機的IP，設為靜態IP

分別為192.168.56.102和192.168.56.103

步驟參見昨天Linux筆記

 

 

VMware同學參見筆記：《VMvare克隆虛擬機.docx》

 

 

4.3.3、啟動zookeeper集群

1）修改102和103機器中的zookeeper的節點ID

修改zookeeper目錄中 data/myid的內容，分別為2和3

 

2）分別啟動三台虛擬機中的zookeeper

zkServer.sh start

查看狀態:

zkServer.sh status

停止：

zkServer.sh stop

 

3）使用zookeeper的客戶端控制台，查看zookeeper信息

 

Zookeeper提供了自己的客戶端命令行工具，與Linux的命令非常相似。

A：啟動客戶端工具：

zkCli.sh –server { ip }:port

這里的參數可以省略，如果省略，默認訪問的是本機的zookeeper節點即：localhost:2181

B：顯示根目錄下、文件： ls / 使用 ls 命令來查看當前 ZooKeeper 中所包含的內容

C：顯示根目錄下、文件： ls2 / 查看當前節點數據並能看到更新次數等數據

D：創建文件，並設置初始內容： create /zk "test" 創建一個新的 znode節點“ zk ”以及與它關聯的字符串

E：獲取文件內容： get /zk 確認 znode 是否包含我們所創建的字符串

F：修改文件內容： set /zk "zkbak" 對 zk 所關聯的字符串進行設置

G：刪除文件： delete /zk 將剛才創建的 znode 刪除

H：退出客戶端： quit

I：幫助命令： help

 

 

4.3.4、修改Solr配置文件，配置集群的中每台Solr服務的IP和端口

1）進入/usr/local/myapp/solr-4.10.2/example/solr目錄

 

2）修改solr.xml文件

<solrcloud>

    <str name="host">192.168.56.101</str>

    <int name="hostPort">8080</int>

    <str name="hostContext">${hostContext:solr}</str>

    <int name="zkClientTimeout">${zkClientTimeout:30000}</int>

    <bool name="genericCoreNodeNames">${genericCoreNodeNames:true}</bool>

  </solrcloud>

 

我們訪問一台Solr服務的地址，一般是這樣的：http://192.168.56.101:8080/solr

而在這里的幾個參數，分別對應這個地址的一些信息：

host：就是Solr服務的IP地址，每台機器配置為自己的IP

hostPort：就是監聽端口，我們是Tomcat服務，因此是8080

hostContext：就是訪問的路徑，這里缺省值是solr，我們不用改

 

 

4.3.5、將Solr配置文件上傳到Zookeeper中，有Zookeeper統一管理

 

由於zookeeper統一管理solr的配置文件（主要是schema.xml、solrconfig.xml）， solrCloud各各節點使用zookeeper管理的配置文件。以后無論創建任何的core，本地的配置文件都沒用了，使用的都是zookeeper的配置文件

 

執行下邊的命令將/usr/local/myapp/solr-4.10.2/example/solr/collection1/conf/下的配置文件上傳到zookeeper：

 

 

sh /usr/local/myapp/solr-4.10.2/example/scripts/cloud-scripts/zkcli.sh -zkhost 192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181 -cmd upconfig -confdir /usr/local/myapp/solr-4.10.2/example/solr/collection1/conf/ -confname solrconf

 

解釋：

/usr/local/myapp/solr-4.10.2/example/scripts/cloud-scripts/zkcli.sh ： Solr提供的訪問Zookeeper的腳本文件

-zkhost 192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181： 指定Zookeeper的地址信息

-cmd upconfig： 指定操作的命令。這里是上傳配置

-confdir /usr/local/myapp/solr-4.10.2/example/solr/collection1/conf/ ：指定要上傳的配置文件目錄，我們上傳Solr的樣例中的配置

-confname solrconf ：指定注冊到Zookeeper中后配置文件目錄名稱

 

4.3.6、啟動SolrCloud

1、啟動每一台服務器中的Solr服務（其實就是啟動Tomcat）

 

2、訪問SolrCloud，查看雲的狀態

 

 

 

4.4、通過管理界面查看和操作SolrCloud

4.4.1、SolrCloud的操作命令：

Solr采用的是類似WebService的API接口，采用Http方式進行訪問，因此，其操作命令都是一些URL聯接及對應參數

 

1、創建core命令：

http://192.168.56.101:8080/solr/admin/collections?action=CREATE&name=myCore1&numShards=3&replicationFactor=2&maxShardsPerNode=8&property.schema=schema.xml&property.config=solrconfig.xml

 

參數說明：

name：指明collection名稱

numShards：指明分片數

replicationFactor：指明副本數

maxShardsPerNode： 每個節點最大分片數（默認為1）

property.schema：指定使用的schema.xml，這個文件必須在zookeeper上。

property.config：指定使用的solrconfig.xml，這個文件必須在zookeeper上。

 

2、刪除Collection命令；

http://192.168.56.101:8080/solr/admin/collections?action=DELETE&name=collection1

 

3、查詢所有的Collection

http://192.168.56.101:8080/solr/admin/collections?action=LIST

 

4、顯示集群的狀態

http://192.168.56.101:8080/solr/admin/collections?action=CLUSTERSTATUS

 

5、分裂shard

http://192.168.56.101:8080/solr/admin/collections?action=SPLITSHARD&collection=myCore2&shard=shard2

 

6、刪除shard

http://192.168.56.101:8080/solr/admin/collections?action=DELETESHARD&collection=myCore2&shard=shard2

 

更多的命令請參數官方文檔：

apache-solr-ref-guide-4.10.pdf

 

 

注意：

啟動solrCloud需要先啟動solrCloud依賴的所有zookeeper服務器，再啟動每台solr服務器。

如果服務器跟服務器之間無法通訊，查看每台服務器的/etc/hosts 里面是否配置了其他服務器的IP地址和hostname

 

 

4.4.2、SolrCloud測試

1、創建索引

測試：在一台Solr上創建的索引，從其它solr服務上可以查詢到

 

 

2、查詢索引：

從任意一台Solr上查詢索引，選擇任意的一個分片，都會返回一個完整的結果 

 

 

3、測試高可用

三台服務器，任意掛掉一台，依然不會影響使用，事實上，只要剩余的機器上，有完整的shard分片信息，都不影響使用。不管剩余幾台服務器

 

4、測試數據自動同步

當一個節點掛掉時，如果有索引的更新，那么這個節點啟動后，會自動同步新的數據

 

5、測試系統的伸縮性

如果我們啟動新的Solr服務，那么這個服務也可以融入集群中。

 

5、使用SolrJ訪問SolrCloud

與單機Solr相比，API僅僅是在創建SolrServer時發生了改變，其它沒有變化。

單機采用的是：HttpSolrServer

SolrCloud采用的是：CloudSolrServer

 

5.1、添加或修改數據

@Test

public void testWrite() throws Exception{

// 創建SolrServer

CloudSolrServer server = new CloudSolrServer("192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181");

// 指定要訪問的Collection名稱

server.setDefaultCollection("collection1");

 

// 創建Document對象

SolrInputDocument document = new SolrInputDocument();

// 添加字段

document.addField("id", "20");

document.addField("title", "duang手機，自帶特效的手機，值得擁有");

 

// 添加Document到Server

server.add(document);

// 提交

server.commit();

}

 

 

5.2、刪除數據

 

@Test

public void testDelete() throws Exception{

// 創建SolrServer

CloudSolrServer server = new CloudSolrServer("192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181");

// 指定要訪問的Collection名稱

server.setDefaultCollection("collection1");

// 根據ID刪除

server.deleteById("20");

// 提交

server.commit();

}

 

 

5.3、查詢數據

 

@Test

public void testSearch() throws Exception {

// 創建SolrServer

CloudSolrServer server = new CloudSolrServer("192.168.56.101:2181,192.168.56.102:2181,192.168.56.103:2181");

// 指定要訪問的Collection名稱

server.setDefaultCollection("collection1");

 

// 查找數據

QueryResponse response = server.query(new SolrQuery("title:手機"));

 

// 以document形式解析數據

SolrDocumentList documentList = response.getResults();

// 遍歷

for (SolrDocument solrDocument : documentList) {

System.out.println(solrDocument.getFieldValue("id"));

System.out.println(solrDocument.getFieldValue("title"));

}

}