四、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的多個副本之間選主)

不可逆：所有操作都是不可逆的