Elasticsearch由淺入深（二）ES基礎分佈式架構、橫向擴容、容錯機制

Elasticsearch的基礎分佈式架構

Elasticsearch對複雜分佈式機制的透明隱藏特性

Elasticsearch是一套分佈式系統，分佈式是爲了應對大數據量。

Elasticsearch隱藏了複雜的分佈式機制：

• 分片：咱們以前隨隨便便就將一些document插入到es集羣中去了，咱們沒有關心過數據是如何進行分配的、數據到哪一個shard中去了。
• 集羣發現機制(cluster discovery):若是啓動一個新的es進程，那麼這個es進程會做爲一個node而且發現es集羣，而後自動加入進去。
• shard負載均衡：舉例，假設如今有3個節點，總共有25個shard要分配到3個節點上去，es會自動進行均分分配，以保證每一個節點的均衡的讀寫負載請求
• shard副本
• 請求路由
• 集羣擴容
• shard重分配

Elasticsearch的垂直擴容與水平擴容

擴容方案：

　　6臺服務器，每臺容納1T的數據，立刻數據量要增加到8T，這個時候有兩個方案。

（1）垂直擴容：從新購置兩臺服務器，每臺服務器的容量就是2T，替換掉老的兩臺服務器，那麼如今6臺服務器的總容量就是 4 * 1T + 2 * 2T = 8T。

（2）水平擴容：新購置兩臺服務器，每臺服務器的容量就是1T，直接加入到集羣中去，那麼如今服務器的總容量就是8 * 1T = 8T

垂直擴容：採購更強大的服務器 ，成本很是高昂，並且會有瓶頸，假設世界上最強大的服務器容量就是10T，可是當你的總數量達到5000T的時候，你要採購多少臺最強大的服務器啊。

水平擴容：業界常常採用的方案，採購愈來愈多的普通服務器，性能比較通常，可是不少普通服務器組織在一塊兒，就能構成強大的計算和存儲能力。

增減或減小節點時的數據rebalance

好比如今有4個node,其中3個node中有一個shard,1個node中有2個shard,可是這個時候若是有一個新的node加入進來，則es會自動把其中一個shard分配到剛加入的node上去。

master節點

一個es集羣中總會有一個node是master節點：

• 管理es集羣的元數據：好比說索引的建立和刪除、維護索引元數據；節點的增長和移除、維護集羣的數據
• 默認狀況下，會自動選擇出一臺節點做爲master節點
• master節點不承載全部的請求，因此不會是單點瓶頸

節點平等的分佈式架構

1. 節點對等，每一個節點都能接收全部的請求
2. 自動請求路由：任何一個節點接收到請求後，均可以把這個請求自動路由到相關節點上去處理該請求。
3. 響應收集：最原始節點會從其餘節點接收響應數據，而後把這些數據返回給客戶端。

primary shard 和 replica shard機制再次梳理

1. 一個索引(index)包含多個shard
   

    

2. 每一個shard都是一個最小工做單元，承載部分數據，lucene實例，完整的創建索引和處理請求的能力。
   

    

3. 增減節點時，shard會自動在nodes中負載均衡。

    

4. primary shard和replica shard,每一個document確定只存在於某一個primary shard以及其對應的replica shrad中，不可能存在於多個primary shard。
5. replica shard是primary shard的副本，負責容錯，以及承擔讀請求負載。
6. primary shard的數量在建立索引的時候就固定了，replica shard的數量能夠隨時修改。
7. primary shard的默認數量是5，replica shrad默認數量是1。
8. primary shard不能和本身的replica shard放在同一個節點上（不然節點宕機時，primary shard和replica shard都丟失了，起不到容錯的做用。），可是能夠和其它primary shard的replica shard放在同一個節點上。

單node環境下建立index是什麼樣子的？

1. 單node環境下，建立一個index: 有3個primary shard、3個replica shard
   

   PUT /test_index
   {
      "settings" : {
         "number_of_shards" : 3,
         "number_of_replicas" : 1
      }
   }

2. 集羣狀態是yellow
3. 這個時候，只會將3個primary shard分配到僅有的一個node上去，另外3個replica shard是沒法分配的
4. 集羣能夠正常工做，可是一旦出現節點宕機，數據所有丟失，並且集羣不可用，沒法承擔任何請求
   

兩個node環境下replica shard是如何分配的？ 

 此時的狀況，1個node、3個primary shard、3個replica shard

若是此時新增一個node進來，構成了一個由2個node組成的es集羣，以下:

而且：

1. primary shard會自動把數據同步到對應的replica shard上去
2. 客戶端的讀請求能夠發送到primary shard上去，也能夠發送到replica shard上去

Elasticsearch橫向擴容

1. primary shard 和 replica shard自動負載均衡
   目前狀況：2個node， 3個primary shard，3個replica shard
   
   
   若是此時給es集羣增長一個節點(node),es會自動對primary shard和replica shard進行負載均衡
   
2. 每一個Node有更少的shard, IO/CPU/Memory資源給每一個shard分配更多，每一個shard性能更好
3. 擴容的極限，6個shard(3個primary shard,3個replica shard),最多擴容到6臺機器，每一個shard能夠佔用單臺服務器的全部資源，性能最好
   
4. 超出擴容極限，動態修改replica數量，9個shard（3primary，6 replica），擴容到9臺機器，比3臺機器時，擁有3倍的讀吞吐量
5. 3臺機器下，9個shard（3 primary，6 replica），資源更少，可是容錯性更好，最多容納2臺機器宕機，6個shard只能容納0臺機器宕機
6. 這裏的這些知識點，你綜合起來看，就是說，一方面告訴你擴容的原理，怎麼擴容，怎麼提高系統總體吞吐量；另外一方面要考慮到系統的容錯性，怎麼保證提升容錯性，讓儘量多的服務器宕機，保證數據不丟失

Elasticsearch容錯機制

1. master選舉、replica容錯、數據恢復 
   目前es集羣狀況：3個node，9個shard(3個primary shard,6個replica shard)
   

   若是此時master node宕機：
   

   由於Node1節點宕機了，因此primary shard0、replica shard一、replica shard2三個3shard就丟失了。master node宕機的一瞬間，primary shard0這個shard就沒有了，此時就不是active status,因此集羣的狀態爲red.

2. 容錯第一步：master選舉，自動選舉另一個node成爲新的master，承擔起master的責任來：
   

3. 容錯第二步：新master將丟失的primary shard的某個replica shard提高爲primary shard，此時cluster status會變爲Yellow，由於全部的primary shard都變成了active status，可是，少了一個replica shard，因此不是全部的replica shard都是active。
   

4. 容錯第三步：重啓故障的node, new master節點將會把缺失的副本都copy一份到該node上去，並且該node會使用以前已有的shard數據，只是同步一下宕機以後發生的改變。
   

   此時es cluster的狀態爲green，由於全部的primary shard和replica shard都是active狀態。