ES集群核心概念
1）Cluster：集群
ES可以作為一個獨立的單個搜索服務器。不過，為了處理大型數據集，實現容錯和高可用性，ES可以運行在許多互相合作的服務器上。這些服務器的集合稱為集群，集群內的節點的cluster.name相同。
2）Node：節點
形成集群的每個服務器稱為節點。
ES 為分配不同的任務，定義了以下幾個節點角色：Master,Data Node,Coordinating Node,Ingest Node
Master 節點：每個 ES 節點啟動之前都會有個默認配置 node.master:true ,也就是說每個節點都有可能成為 Master 節點，這些節點被稱作 Master-eligible nodes ，就是合格的有資格成為 Master 節點的節點。
當然 Master 只能有一個，所以會通過選舉的方法對這啟動的節點選舉，被選中的節點才會成為 Master 節點。
Master 節點主要是負責維護集群的狀態，像所有節點的信息，所有的索引和它相關的 Mapping 關系，配置信息，分片的路由等。
既然 Master 節點維護了這么重要的信息，玩意它掛了怎么辦？
掛了的話，將會對其他的有資格成為 Master 節點的節點重新選舉出另一個 Master 節點，因此這就說明了其他 Master-eligible nodes 也會保存集群信息，但是只有 Master 節點有權限能夠修改，試想如果其他節點也能修改的話，這將會導致數據不一致的問題。
Data Node 節點：數據節點，這個節點主要負責數據的存儲，在數據擴展上起到了至關重要的作用。也就是說讀寫數據都會找到相應的 Data Node 節點。
Coordinating Node 節點：協調節點主要負責協調客戶端的請求，將接收到的請求分發給合適的節點，並把結果匯集到一起。比如客戶端請求查詢某個索引的數據，協調節點將會把請求分發給保存相關的數據的 DataNode 節點，找到相應的分片，並把查詢到的結果都匯集返回。並且每個節點都默認起到了 Coordinating Node 的職責。
Ingest Node節點: Ingest node 專門對索引的文檔做預處理,發生在對真實文檔建立索引之前。在建立索引對文檔預處理之前，先定義一個管道（pipeline），管道里指定了一系列的處理器。每個處理器能夠把文檔按照某種特定的方式轉換。比如在管道里定義一個從某個文檔中移除字段的處理器，緊接着一個重命名字段的處理器。集群的狀態也會被存儲到配置的管道內。定義一個管道，簡單的在索引或者bulk request(一種批量請求方法)操作上定義 pipeline 參數,這樣 ingest node 就會知道哪個管道在使用。這個節點在使用過程中用的也不多，所以大概了解一下就行。
說明：
- 一個節點可以充當一個或多個角色，默認三個角色都有。
- 協調節點：一個節點只作為接收請求、轉發請求到其他節點、匯總各個節點返回數據等功能的節點。就叫協調節點。
3）Index：索引
在 ES 中, 索引是一組文檔的集合。索引的作用相當於圖書的目錄，可以根據目錄中的頁碼快速找到所需的內容。當表中有大量記錄時，若要對表進行查詢，第一種搜索信息方式是全表搜索，是將所有記錄一一取出，和查詢條件進行一一對比，然后返回滿足條件的記錄，這樣做會消耗大量數據庫系統時間，並造成大量磁盤I/O操作；第二種就是在表中建立索引，然后在索引中找到符合查詢條件的索引值，最后通過保存在索引中的ROWID（相當於頁碼）快速找到表中對應的記錄。
4）Shard：分片
當有大量的文檔時，由於內存的限制、磁盤處理能力不足、無法足夠快的響應客戶端的請求等，一個節點可能不夠。
這種情況下，數據可以分為較小的分片。每個分片放到不同的服務器上。
當你查詢的索引分布在多個分片上時，ES會把查詢發送給每個相關的分片，並將結果組合在一起，而應用程序並不知道分片的存在。即：這個過程對用戶來說是透明的。
說明：
- 創建索引的時候就確定好主分片的數量，除非重索引。
- 分片對應的存儲實體是索引。
- 一個分片就是一個 Lucene 實例
5）路由
Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？當我們創建文檔時，它如何決定這個文檔應當被存儲在分片 1 還是分片 2 中呢？
首先這肯定不會是隨機的，否則將來要獲取文檔的時候我們就不知道從何處尋找了。實際上，這個過程是根據下面這個公式決定的：
shard = hash(routing) % number_of_primary_shards
routing 是一個可變值，唯一不可重復，默認是文檔的 _id ，也可以設置成一個自定義的值。 routing 通過 hash 函數生成一個數字，然后這個數字再除以 number_of_primary_shards （主分片的數量）后得到余數 。這個分布在 0 到 number_of_primary_shards-1 之間的余數，就是我們所尋求的文檔所在分片的位置。
這就解釋了為什么我們要在創建索引的時候就確定好主分片的數量 並且永遠不會改變這個數量：因為如果數量變化了，那么所有之前路由的值都會無效，文檔也再也找不到了。
所有的文檔 API( get 、 index 、 delete 、 bulk 、 update 以及 mget )都接受一個叫做 routing 的路由參數 ，通過這個參數我們可以自定義文檔到分片的映射。一個自定義的路由參數可以用來確保所有相關的文檔——例如所有屬於同一個用戶的文檔——都被存儲到同一個分片中。
6）Replia：副本
在創建某個索引之前，需要指定分配這個索引多少個分片？多少個副本？副本就這這個分片的備胎，當分片掛掉了，它的副本就會隨時准備上位，因此副本也是個分片只不過不負責主要功能。
不僅僅如此，ES 如何能夠提高數據吞吐量呢？增加副本個數就是個不錯的選擇，比如說讀寫分離，讀數據的時候從副本上讀，寫數據的時候只用主分片去寫。需要注意的是，主分片的個數實在建立索引之前要確定，建立完索引之后，是不能夠進行修改的，除非重新建索引。因此在建索引之前，一定要合理的配置分片個數，副本個數的話后期是可以改動的。
為提高查詢吞吐量或實現高可用性，可以使用分片副本。
副本是一個分片的精確復制，每個分片可以有零個或多個副本。ES中可以有許多相同的分片，其中之一被選擇更改索引操作，這種特殊的分片稱為主分片。
當主分片丟失時，如：該分片所在的數據不可用時，集群將副本提升為新的主分片。
Elasticsearch 禁止同一個分片的主分片和副本分片在同一個節點上，所以如果是一個節點的集群是不能有副本的。
如何設置副本
啟動 2 個 ES 節點，配置分片個數為 3，副本個數為 1（每個分片有一個副本）。如下圖，藍色的代表主分片，綠色的是副本，仔細一點不難發現，分片與其副本不在同一個節點內。這是非常合理的，因為副本本來就是主分片的備胎，當主分片節點掛了，另外一個節點的副本將會充當主分片，如果它們在同一個節點內，副本將發揮不到作用。
水平擴展原理
單個節點的容量是有限的，如果后期兩個節點的容量不能夠支持三個分片，那么另外啟動一個節點就可以了，ES 會自動的重新規划分片，如下圖：可以看到 A3 節點已經被自動的分配到 Node3 節點里面了，另外副本 B1 從 Node2 移動到 Node3 節點，B3 分片從 Node1 節點被分配到 Node2 節點。這里想一下，如果再啟動一個節點呢？是的，再啟動一個節點將不會對主分片起到任何作用，因為主分片不可以修改，只有三個，但是副本可以修改，能夠起到擴容的作用。
