一、概念

1、分片Shards

一個 Lucene 索引 我們在 Elasticsearch 稱作 分片 。 一個Elasticsearch 索引 是分片的集合。 當 Elasticsearch 在索引中搜索的時候， 他發(fā)送查詢到每一個屬于索引的分片（Lucene 索引），然后合并每個分片的結果到一個全局的結果集。

分片很重要，主要有兩方面的原因：
1、允許水平分割 / 擴展我們的內(nèi)容容量。
2、允許在分片之上進行分布式的、并行的操作，進而提高性能/吞吐量。

分片的配置必須在創(chuàng)建索引的時候就指定分片數(shù)量，因為這直接決定了數(shù)據(jù)的路由規(guī)則，索引不支持在運行中的索引進行動態(tài)修改，副本則可以。

2、副本Replicas

Elasticsearch 允許你創(chuàng)建分片的一份或多份拷貝，這些拷貝叫做副本分片，目的就是解決在在某個分片或節(jié)點因出現(xiàn)問題時候，能提供故障轉移的機制。

副本分片很重要，有兩個主要原因：
1、在分片/節(jié)點失敗的情況下，提供了高可用性。因為這個原因，注意到副本分片從不與主分片置于同一節(jié)點上是非常重要的。
2、擴展你的搜索量/吞吐量，因為搜索可以在所有的副本上并行運行。

在運行中的集群上是可以動態(tài)調整副本分片數(shù)目的，我們可以按需伸縮集群。讓我們把
副本數(shù)從默認的 1 增加到 2。

PUT your_index/_settings
{
	"number_of_replicas" : 2
}

二、分片副本設置

1、分配 3個主分片和一份副本分配

PUT your_index
{
    "mappings" : {
      "properties" : {
      #索引字段（略）
      }
    }
    "settings" : {
        "number_of_shards" : 3,
        "number_of_replicas" : 1
    }
}

配置之后總共有3個主分片f1,f2,f3,并且每個分片有自己的一個副本分片，f1-back,f2-back,f3-back，總共6個分片。

2、集群部署

1、分片肯定以為著es的集群部署，那么怎樣設置分配和副本才能使得集群部署合理呢？
如果我們按照1那樣配置，并且只有一臺機器
集群健康值:yellow( 3 of 6 )：表示當前集群的全部主分片都正常運行，但是副本分片沒有全部處在正常狀態(tài)。
在同一個節(jié)點上既保存原始數(shù)據(jù)又保存副本是沒有意義的，因為一旦失去了那個節(jié)點，我們也將丟失該節(jié)點 上的所有副本數(shù)據(jù)。
雖然當前集群是正常運行的，但存在丟失數(shù)據(jù)的風險。
2、當我們有3臺服務器，并且在每個啟動的es都配置文件中都完成了集群監(jiān)聽配置

#在節(jié)點1配置節(jié)點2和3的地址
discovery.seed_hosts: ["localhost:9302", "localhost:9303"]

集群健康值:green( 3 of 6 )：表示所有 6 個分片（包括 3 個主分片和 3 個副本分片）都在正常運行。

邊框加粗的是主分片，沒加粗的是副本分片，從中我們也可以看出es自動分片并沒有強迫癥，但是卻嚴格遵守水平擴容，以及故障轉移的配置規(guī)格，但節(jié)點一掛了（服務器node-1）,此時，副本0（node-2）副本1（node-3）會通過選舉成為主分片，保證了索引的正常運行。

三、路由計算

當索引一個文檔的時候，文檔會被存儲到一個主分片中。 Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？當我們創(chuàng)建文檔時，它如何決定這個文檔應當被存儲在分片 1 還是分片 2 中呢？首先這肯定不會是隨機的，否則將來要獲取文檔的時候我們就不知道從何處尋找了。實際上，這個過程是根據(jù)下面這個公式?jīng)Q定的：

shard = hash(routing) % number_of_primary_shards

四、集群中es的數(shù)據(jù)增刪改查操作流程

1、數(shù)據(jù)寫流程（增、刪）

新建、刪除請求都是寫操作， 必須在主分片上面完成之后才能被復制到相關的副本分片。
當刪除某個數(shù)據(jù)時，es并不會直接物理刪除，而是將原文檔的數(shù)據(jù)標記為刪除，然后重新寫入新的文檔數(shù)據(jù)，被標記刪除的文檔數(shù)據(jù)，會有一定的策略進行統(tǒng)一收集再真正進行物理刪除操作

2、更新流程 & 批量操作（改）

更新一個文檔的部分數(shù)據(jù)

1. 客戶端向Node 1發(fā)送更新請求。
2. 它將請求轉發(fā)到主分片所在的Node 3 。
3. Node3從主分片檢索文檔，修改_source字段中的JSON，并且嘗試重新索引主分片的文檔。如果文檔已經(jīng)被另一個進程修改,它會重試步驟3,超過retry_on_conflict次后放棄。
4. 如果 Node 3成功地更新文檔，它將新版本的文檔并行轉發(fā)到Node 1和 Node2上的副本分片，重新建立索引。一旦所有副本分片都返回成功，Node 3向協(xié)調節(jié)點也返回成功，協(xié)調節(jié)點向客戶端返回成功。

當主分片把更改轉發(fā)到副本分片時， 它不會轉發(fā)更新請求。 相反，它轉發(fā)完整文檔的新版本。請記住，這些更改將會異步轉發(fā)到副本分片，并且不能保證它們以發(fā)送它們相同的順序到達。 如果 Elasticsearch 僅轉發(fā)更改請求，則可能以錯誤的順序應用更改，導致得到損壞的文檔。

3、數(shù)據(jù)讀流程（查）

五、優(yōu)化

1、減少 Refresh 的次數(shù)

Lucene 在新增數(shù)據(jù)時，采用了延遲寫入的策略，默認情況下索引的refresh_interval 為1 秒。

Lucene 將待寫入的數(shù)據(jù)先寫到內(nèi)存中，超過 1 秒（默認）時就會觸發(fā)一次 Refresh，然后 Refresh 會把內(nèi)存中的的數(shù)據(jù)刷新到操作系統(tǒng)的文件緩存系統(tǒng)中。

如果我們對搜索的實效性要求不高，可以將 Refresh 周期延長，例如 30 秒。

這樣還可以有效地減少段刷新次數(shù)，但這同時意味著需要消耗更多的 Heap 內(nèi)存。

2、加大 Flush 設置

Flush 的主要目的是把文件緩存系統(tǒng)中的段持久化到硬盤，當 Translog 的數(shù)據(jù)量達到 512MB 或者 30 分鐘時，會觸發(fā)一次 Flush。

index.translog.flush_threshold_size 參數(shù)的默認值是 512MB，我們進行修改。

增加參數(shù)值意味著文件緩存系統(tǒng)中可能需要存儲更多的數(shù)據(jù)，所以我們需要為操作系統(tǒng)的文件緩存系統(tǒng)留下足夠的空間。

3、減少副本的數(shù)量

ES 為了保證集群的可用性，提供了 Replicas（副本）支持，然而每個副本也會執(zhí)行分析、索引及可能的合并過程，所以 Replicas 的數(shù)量會嚴重影響寫索引的效率。

當寫索引時，需要把寫入的數(shù)據(jù)都同步到副本節(jié)點，副本節(jié)點越多，寫索引的效率就越慢。

如果我們需要大批量進行寫入操作，可以先禁止Replica復制，設置
index.number_of_replicas: 0 關閉副本。在寫入完成后， Replica 修改回正常的狀態(tài)。文章來源地址http://www.zghlxwxcb.cn/news/detail-402491.html

到了這里，關于ES分片副本設置及集群部署的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！