1. 程式人生 > >solrcloud叢集部署 二

solrcloud叢集部署 二

四、SolrCloud概述

1、單點問題總結

單點的Solr服務缺點:

A:能儲存的資料量有限,如果是海量資料,無法儲存,

B:容易出現單點故障

C:對高併發的處理能力差

2、單點Solr問題解決

1.	把原始的Solr的一個邏輯核心(collection),拆分成多個Shard(分片),每個分片儲存原始總資料的部分資料

2.	拆分後新的問題:
原始資料切分為多個分片之後,當SolrJ(客戶端)來訪問時,具體訪問哪臺機器上的資料分片呢?
如果當SolrJ來訪問時,填寫具體的IP,那麼當分片足夠多的時候顯然是不可能的,
所以我們引入一個管家,zookeeper,我們通過它來提供資訊,以便於我們訪問這些分散式分片

3、分散式方案問題

多個數據分片組成了一個邏輯的collection,但由於多個分片儲存在多個機器上,如果某臺機器宕機,
那麼勢必會造成資料的不完整,從整體邏輯來說這是不允許的,所以我們對每個分片進行叢集,
在不新增機器的前提下,資料儲存選擇交叉儲存,每臺機器儲存資料分片的一個或者多個副本(replica)。
這樣就形成了SolrCloud的雛形:

說明:

1,	資料量太大,一臺機器放不下,一臺機器的效能不行 
2,	如何分?分原始的collection(核心),分成一個個shard,只要shard>1就是分散式
3,	由於存在單點故障,所以要對分片shard做叢集操作。只要副本數量>1就是 叢集(多個副本不在同一臺機器)
4,	Collection是邏輯的,由多個shard組成,
5,	Replica副本,可以有多個,只要副本>1並且沒有儲存在同一臺機器就是叢集

4、SolrCloud邏輯結構詳解

說明:

為了實現海量資料的儲存,我們會把索引進行分片(Shard),把分片後的資料儲存到不同Solr節點。

為了保證節點資料的高可用,避免單點故障,我們又會對每一個Shard進行復制,
產生很多副本(Replicas),每一個副本對於一個Solr節點中的一個core

使用者訪問的時候,可以訪問任何一個會被自動分配到任何一個可用副本進行查詢。
Collection:在SolrCloud叢集中邏輯意義上的完整的索引。一般會包含多個Shard(分片),如果大於1個分片,那麼就是分散式儲存。

Shard: Collection的邏輯分片。每個Shard被化成一個或者多個replicas(副本)

Replica: Shard的一個副本,儲存在Solr叢集的某一臺機器中(就是一個節點),
對應這臺Solr的一個Core,如果機器上存放了多個副本,那本機器的solr將有多個core。

Collection和Shard只是邏輯存在的 ,真實存在的只有replica,replica其實就是shard。

分片的數量不要多於機器的數量,3,分片最好不要超過三個

五、Zookeeper分散式協調服務

1、Zookeeper概述

Zookeeper是叢集分散式系統中大管家

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

Zookeeper 是為分散式應用程式提供高效能協調服務的工具集合,
也是Google的Chubby一個開源的實現,是Hadoop 的分散式協調服務

2、Zookeeper叢集結構

在ZooKeeper叢集當中,叢集中的伺服器角色有兩種:1個Leader和多個Follower,具體功能如下:

1)領導者(leader),負責進行投票的發起和決議,監控叢集中的節點是否存活(心跳機制),進行分配資源
2)follower用於接受客戶端請求並向客戶端返回結果,在選主過程中參與投票

特點:

A:Zookeeper:一個leader,多個follower組成的叢集

B:全域性資料一致(leader主持):每個server儲存一份相同的資料副本,client無論連線到哪個server,資料都是一致的

C:資料更新原子性,一次資料更新要麼成功。

D:實時性,在一定時間範圍內,client能讀到最新資料, 

E:半數機制:整個叢集中只要有一半以上存活,就可以提供服務。因此通常Zookeeper由2n+1(n>=0)臺servers組成,
每個server都知道彼此的存在。每個server都維護的記憶體狀態映象以及持久化儲存的事務日誌和快照。
為了保證Leader選舉能獲得到多數的支援,所以ZooKeeper叢集的數量一般為奇數。對於2n+1臺server,
只要有n+1臺(大多數)server可用,整個系統保持可用

3、Zookeeeper的leader選主機制

假設有五臺伺服器組成的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一樣,當小弟.

注意: 但當叢集節點伺服器裡有資料時、就按資料最新的節點伺服器做為leader

4、Zookeeper的作用

Zookeeper包含一個簡單的 原語集 ,分散式應用程式可以基於它實現:命名服務、配置維護、叢集選主等

命名服務:註冊節點資訊,形成有層次的目錄結構(類似Java的包名)。
配置維護:配置資訊的統一管理和動態切換(solrconfig.xml,schame.xml) 

 

叢集選主:確保整個叢集中只有一個主,其它為從。並且當主掛了後,可以自動選主(同一shard的多個副本之間選主)
不可逆:所有操作都是不可逆的