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 shard1、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狀態。