實例展現elasticsearch集羣生態,分片以及水平擴展.

　　elasticsearch用於構建高可用和可擴展的系統。擴展的方式能夠是購買更好的服務器(縱向擴展)或者購買更多的服務器（橫向擴展）,Elasticsearch能從更強大的硬件中得到更好的性能，可是縱向擴展也有必定的侷限性。真正的擴展應該是橫向的，它經過增長節點來傳播負載和增長可靠性。對於大多數數據庫而言，橫向擴展意味着你的程序將作很是大的改動來利用這些新添加的設備。對比來講，Elasticsearch天生是分佈式的：它知道如何管理節點來提供高擴展和高可用。這意味着你的程序不須要關心這些。對於大多數數據庫而言，橫向擴展意味着你的程序將作很是大的改動來利用這些新添加的設備。對比來講，Elasticsearch天生是分佈式的：它知道如何管理節點來提供高擴展和高可用。這意味着你的程序不須要關心這些。

集羣和節點 

節點(node)是你運行的Elasticsearch實例。一個集羣(cluster)是一組具備相同cluster.name的節點集合，他們協同工做，共享數據並提供故障轉移和擴展功能，當有新的節點加入或者刪除節點，集羣就會感知到並平衡數據。集羣中一個節點會被選舉爲主節點(master),它用來管理集羣中的一些變動，例如新建或刪除索引、增長或移除節點等;固然一個節點也能夠組成一個集羣。

節點通訊: 

咱們可以與集羣中的任何節點通訊，包括主節點。任何一個節點互相知道文檔存在於哪一個節點上，它們能夠轉發請求到咱們須要數據所在的節點上。咱們通訊的節點負責收集各節點返回的數據，最後一塊兒返回給客戶端。這一切都由Elasticsearch透明的管理。

 

分片與副本分片
分片用於Elasticsearch在你的集羣中分配數據。想象把分片看成數據的容器。文檔存儲在分片中，而後分片分配給你集羣中的節點上。
當你的集羣擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使集羣保持平衡。

一個分片(shard)是一個最小級別的「工做單元(worker unit)」,它只是保存索引中全部數據的一小片.咱們的文檔存儲和被索引在分片中，可是咱們的程序不知道如何直接與它們通訊。取而代之的是，他們直接與索引通訊.Elasticsearch中的分片分爲主分片和副本分片,複製分片只是主分片的一個副本，它用於提供數據的冗餘副本，在硬件故障以後提供數據保護，同時服務於像搜索和檢索等只讀請求，主分片的數量和複製分片的數量均可以經過配置文件配置。可是主切片的數量只能在建立索引時定義且不能修改.相同的分片不會放在同一個節點上。

1)分片算法:

shard = hash(routing) % number_of_primary_shards

routing值是一個任意字符串，它默認是_id但也能夠自定義，這個routing字符串經過哈希函數生成一個數字，而後除以主切片的數量獲得一個餘數(remainder)，餘數的範圍永遠是0到number_of_primary_shards - 1，這個數字就是特定文檔所在的分片。

這也解釋了爲何主切片的數量只能在建立索引時定義且不能修改：若是主切片的數量在將來改變了，全部先前的路由值就失效了，文檔也就永遠找不到了。

全部的文檔API（get、index、delete、bulk、update、mget）都接收一個routing參數，它用來自定義文檔到分片的映射。自定義路由值能夠確保全部相關文檔.好比用戶的文章,按照用戶帳號路由,就能夠實現屬於同一用戶的文檔被保存在同一分片上。

2)分片和副本交互：

新建、索引和刪除請求都是寫(write)操做，它們必須在主分片上成功完成才能複製到相關的複製分片上,下面咱們羅列在主分片和複製分片上成功新建、索引或刪除一個文檔必要的順序步驟：

1、客戶端給Node 1發送新建、索引或刪除請求。

2、節點使用文檔的_id肯定文檔屬於分片0。它轉發請求到Node 3，分片0位於這個節點上。

3、Node 3在主分片上執行請求，若是成功，它轉發請求到相應的位於Node 1和Node 2的複製節點上。當全部的複製節點報告成功，Node 3報告成功到請求的節點，請求的節點再報告給客戶端。

客戶端接收到成功響應的時候，文檔的修改已經被應用於主分片和全部的複製分片。你的修改生效了。

3)副本分片複製時的相關的參數說明:

replication:

複製默認的值是sync。這將致使主分片獲得複製分片的成功響應後才返回，若是你設置replication爲async，請求在主分片上被執行後就會返回給客戶端。它依舊會轉發請求給複製節點，但你將不知道複製節點成功與否。

默認的sync複製容許Elasticsearch強制反饋傳輸。async複製可能會由於在不等待其它分片就緒的狀況下發送過多的請求而使Elasticsearch過載。

consistency:

默認主分片在嘗試寫入時須要**規定數量(quorum)**或過半的分片（能夠是主節點或複製節點）可用。這是防止數據被寫入到錯的網絡分區。規定的數量計算公式以下：

int( (primary + number_of_replicas) / 2 ) + 1

consistency容許的值爲one（只有一個主分片），all（全部主分片和複製分片）或者默認的quorum或過半分片。

注意number_of_replicas是在索引中的的設置，用來定義複製分片的數量，而不是如今活動的複製節點的數量。若是你定義了索引有3個複製節點，那規定數量是：int( (primary + 3 replicas) / 2 ) + 1 = 3

但若是你只有2個節點，那你的活動分片不夠規定數量，也就不能索引或刪除任何文檔。

注意: 新索引默認有1個複製分片，這意味着爲了知足quorum的要求**須要**兩個活動的分片。固然，這個默認設置將阻止咱們在單一節點集羣中進行操做。爲了避開這個問題，規定數量只有在number_of_replicas大於一時才生效。

timeout：

當分片副本不足時Elasticsearch會等待更多的分片出現。默認等待一分鐘。若是須要，你能夠設置timeout參數讓它終止的更早：100表示100毫秒，30s表示30秒。

 

集羣生態:

1.同集羣中節點之間能夠擴容縮容,

2.主分片的數量會在其索引建立完成後修正，可是副本分片的數量會隨時變化。

3.相同的分片不會放在同一個節點上.

 

集羣健康:

在Elasticsearch集羣中能夠監控統計不少信息，可是隻有一個是最重要的時集羣健康(cluster health)。Es中用三種顏色狀態表示:green，yellow，red.

Green：全部主分片和副本分片均可用

Yellow：全部主分片可用，但不是全部副本分片均可用

Red：不是全部的主分片均可用；

一、建立單集羣節點

如圖咱們的單點集羣:

實例中咱們建立一個索引dobbyindex.一個索引默認指派5個主分片,實例中咱們設定4個主分片和2個複製分片（每一個主分片有2個複製分片對應）：

PUT /dobbyindex { "settings": { "number_of_shards": 4, "number_of_replicas": 2 } }

建立後索引如圖:

在節點es-node1中片的存放以下:

咱們的主分片都被分配到了es-node1.可是咱們的8個複製分片尚未被分配到節點上, 此時的集羣健康情況以下:

cluster health: yellow (4 of 12)
對應的詳細信息爲:

{ "cluster_name": "elasticsearch-cluster-centos", "status": "yellow", "timed_out": false, "number_of_nodes": 1, "number_of_data_nodes": 1, "active_primary_shards": 4, "active_shards": 4, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 8 }

View Code

意味着全部的主分片(primary shards)啓動而且運行了,集羣已經能夠成功的接受任意請求,可是副本分片(replica shards)尚未所有可用。

事實上全部的8個副本分片如今是unassigned（未分配）狀態,即它們還未被分配給節點,在同一個節點上保存相同的數據副本是沒有必要的，若是這個節點故障了，那全部的數據副本也會丟失。如今咱們的集羣已經功能完備，可是依舊存在因硬件故障而致使的數據丟失的風險。

2.增長故障轉移

上面實例中的集羣有單點故障的風險,沒有數據冗餘備份。咱們能夠擴展節點來保護數據不被丟失.只要第二個節點與第一個節點有相同的cluster.name(實例中爲elasticsearch-cluster-centos)，它就能自動發現並加入第一個節點的集羣。

若是沒有，檢查日誌找出哪裏出了問題。這多是網絡廣播被禁用，或者防火牆阻止了節點通訊。

當咱們啓動第二個節點以後:集羣中的分片結構圖以下:

雖然,已經有4個副本分片被分陪到es-node2節點上來了，可是按照咱們定義的副本分片的值爲2, 還有4個分片處於未分片狀態,此時對於咱們設定的參數來講,集羣的健康值仍是全部主分片可用，但不是全部複製分片均可用. 對應的集羣健康情況:

cluster health: yellow (8 of 12)

對應的詳細信息爲:

{ "cluster_name": "elasticsearch-cluster-centos", "status": "yellow", "timed_out": false, "number_of_nodes": 2, "number_of_data_nodes": 2, "active_primary_shards": 4, "active_shards": 8, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 4 }

View Code

因此咱們還須要一個節點來分片這些副本分片,使集羣達到高可用,再增長集羣節點:

當咱們啓動第三個節點以後,整個集羣上的分片都進行了有效分配,從圖中能夠看出.es-node1爲這個集羣生態中選舉出來的主(master),es-node2和es-node3爲集羣生態中的slave(從). 這樣,一些新的被索引的文檔將首先被存儲在主分片中，而後平行復制到關聯的複製節點上。這能夠確保咱們的數據在主節點和複製節點上均可以被檢索。

此時集羣的健康狀態以下：

cluster health: green (12 of 12)
對應的詳細信息爲：

{ "cluster_name": "elasticsearch-cluster-centos", "status": "green", "timed_out": false, "number_of_nodes": 3, "number_of_data_nodes": 3, "active_primary_shards": 4, "active_shards": 12, "relocating_shards": 0, "initializing_shards": 0, "unassigned_shards": 0 }

View Code

下圖爲,節點es-node3加入時,分片分配過程當中截取的臨時圖.

3.模擬節點宕機,集羣主從從新選舉
上圖中咱們的主節點爲es-node1,若是主節點宕掉後,會怎樣呢.

如圖:主節點對應的進程號7421,幹掉它，此時es集羣生態發生了以下變化,如圖:

es-node3被選舉爲主節點,es-node2爲從節點,主分片與副本分片也變化了,主分片放置在了es-node2上,副本分片放置到了es-node3上,由於分片沒有徹底被分配,因此集羣的健康狀態變爲yellow(全部主分片可用，但不是全部複製分片均可用),而後咱們重啓es-node1節點.

如圖,重啓後健康狀態恢復到green,可是集羣主從變化了,且主分片的位置也變化了.

 

4.模擬擴展節點

實例2中咱們的集羣已經達到高可用狀態,對應的索引分片如圖.此時咱們想要擴展集羣繼續增長節點時,咱們的分片會怎樣呢,接下來咱們再增長一個擴展節點es-node4.

如圖:擴容後,能夠看到片進行了從新分片,節點es-node1和es-node3上分別持有主分片。es-node2,es-node3,es-node4持有副本分片，因爲筆者模擬過程當中有主節點宕機操做,

因此從圖中能夠看出,新的生態集羣中es-node4爲主節點.對應的各個集羣存儲中包含的片分佈信息以下:

這種狀態下的片也是徹底分配，green(全部主要和複製的分片均可用).

 

5.動態縮小或者擴容副本片數量

副本節點的數量能夠在運行中的集羣中動態的變動，這容許咱們能夠根據需求擴大或者縮小規模。

好比咱們執行一次縮小規模操做:

PUT /dobbyindex/_settings { "number_of_replicas" : 1 } 執行結果返回: { "acknowledged": true }

這時,咱們看到片的信息分又從新作了調整: 主分片分佈在節點es-node1,es-node3,es-node4上.從分片分佈在es-node2,es-node3,es-node4上.



轉載請註明出處:[http://www.cnblogs.com/dennisit/p/4133131.html]