Elasticsearch用於構建高可用和可擴充套件的系統。擴充套件的方式可以是購買更好的伺服器(縱向擴充套件(vertical scale or scaling up))或者購買更多的伺服器（橫向擴充套件(horizontal scale or scaling out)）。
Elasticsearch雖然能從更強大的硬體中獲得更好的效能，但是縱向擴充套件有它的侷限性。真正的擴充套件應該是橫向的，它通過增加節點來均攤負載和增加可靠性。
對於大多數資料庫而言，橫向擴充套件意味著你的程式將做非常大的改動才能利用這些新新增的裝置。對比來說，Elasticsearch天生就是分散式的：它知道如何管理節點來提供高擴充套件和高可用。這意味著你的程式不需要關心這些。 在這章我們將探索如何建立你的叢集(cluster)、節點(node)和分片(shards)，使其按照你的需求進行擴充套件，並保證在硬體故障時資料依舊安全。
空叢集
如果我們啟動一個單獨的節點，它還沒有資料和索引，這個叢集看起來就像圖1。
圖1：只有一個空節點的叢集
一個節點(node)就是一個Elasticsearch例項，而一個叢集(cluster)由一個或多個節點組成，它們具有相同的cluster.name，它們協同工作，分享資料和負載。當加入新的節點或者刪除一個節點時，叢集就會感知到並平衡資料。
叢集中一個節點會被選舉為主節點(master),它將臨時管理叢集級別的一些變更，例如新建或刪除索引、增加或移除節點等。主節點不參與文件級別的變更或搜尋，這意味著在流量增長的時候，該主節點不會成為叢集的瓶頸。任何節點都可以成為主節點。我們例子中的叢集只有一個節點，所以它會充當主節點的角色。
做為使用者，我們能夠與叢集中的任何節點通訊，包括主節點。每一個節點都知道文件存在於哪個節點上，它們可以轉發請求到相應的節點上。我們訪問的節點負責收集各節點返回的資料，最後一起返回給客戶端。這一切都由Elasticsearch處理。
叢集健康
在Elasticsearch叢集中可以監控統計很多資訊，但是隻有一個是最重要的：叢集健康(cluster health)。叢集健康有三種狀態：green、yellow或red。
GET /_cluster/health
複製程式碼在一個沒有索引的空叢集中執行如上查詢，將返回這些資訊：
{
"cluster_name": "elasticsearch",
"status": "green", <1>
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
複製程式碼status欄位提供一個綜合的指標來表示叢集的的服務狀況。三種顏色各自的含義：
在接下來的章節，我們將說明什麼是主要分片(primary shard)和複製分片(replica shard)，並說明這些顏色（狀態）在實際環境中的意義。
新增索引
為了將資料新增到Elasticsearch，我們需要索引(index)——一個儲存關聯資料的地方。實際上，索引只是一個用來指向一個或多個分片(shards)的“邏輯名稱空間(logical namespace)”.
一個分片(shard)是一個最小級別“工作單元(worker unit)”,它只是儲存了索引中所有資料的一部分。在接下來的《深入分片》一章，我們將詳細說明分片的工作原理，但是現在我們只要知道分片就是一個Lucene例項，並且它本身就是一個完整的搜尋引擎。我們的文件儲存在分片中，並且在分片中被索引，但是我們的應用程式不會直接與它們通訊，取而代之的是，直接與索引通訊。
分片是Elasticsearch在叢集中分發資料的關鍵。把分片想象成資料的容器。文件儲存在分片中，然後分片分配到你叢集中的節點上。當你的叢集擴容或縮小，Elasticsearch將會自動在你的節點間遷移分片，以使叢集保持平衡。
分片可以是主分片(primary shard)或者是複製分片(replica shard)。你索引中的每個文件屬於一個單獨的主分片，所以主分片的數量決定了索引最多能儲存多少資料。
理論上主分片能儲存的資料大小是沒有限制的，限制取決於你實際的使用情況。分片的最大容量完全取決於你的使用狀況：硬體儲存的大小、文件的大小和複雜度、如何索引和查詢你的文件，以及你期望的響應時間。
複製程式碼複製分片只是主分片的一個副本，它可以防止硬體故障導致的資料丟失，同時可以提供讀請求，比如搜尋或者從別的shard取回文件。
當索引建立完成的時候，主分片的數量就固定了，但是複製分片的數量可以隨時調整。
讓我們在叢集中唯一一個空節點上建立一個叫做blogs的索引。預設情況下，一個索引被分配5個主分片，但是為了演示的目的，我們只分配3個主分片和一個複製分片（每個主分片都有一個複製分片）：
PUT /blogs
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
複製程式碼附帶索引的單一節點叢集：
我們的叢集現在看起來就像上圖——三個主分片都被分配到Node 1。如果我們現在檢查叢集健康(cluster-health)，我們將見到以下資訊：
{
"cluster_name": "elasticsearch",
"status": "yellow", <1>
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 3,
"active_shards": 3,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 3 <2>
}
複製程式碼<1> 叢集的狀態現在是 yellow
<2> 我們的三個複製分片還沒有被分配到節點上
叢集的健康狀態yellow表示所有的主分片(primary shards)啟動並且正常執行了——叢集已經可以正常處理任何請求——但是複製分片(replica shards)還沒有全部可用。事實上所有的三個複製分片現在都是unassigned狀態——它們還未被分配給節點。在同一個節點上儲存相同的資料副本是沒有必要的，如果這個節點故障了，那所有的資料副本也會丟失。
現在我們的叢集已經功能完備，但是依舊存在因硬體故障而導致資料丟失的風險。
故障轉移
在單一節點上執行意味著有單點故障的風險——沒有資料備份。幸運的是，要防止單點故障，我們唯一需要做的就是啟動另一個節點。
啟動第二個節點
為了測試在增加第二個節點後發生了什麼，你可以使用與第一個節點相同的方式啟動第二個節點，而且命令列在同一個目錄——一個節點可以啟動多個Elasticsearch例項。
只要第二個節點與第一個節點有相同的cluster.name（請看./config/elasticsearch.yml檔案），它就能自動發現並加入第一個節點所在的叢集。如果沒有，檢查日誌找出哪裡出了問題。這可能是網路廣播被禁用，或者防火牆阻止了節點通訊。
複製程式碼如果我們啟動了第二個節點，這個叢集看起來就像下圖。 雙節點叢集——所有的主分片和複製分片都已分配:
第二個節點已經加入叢集，三個複製分片(replica shards)也已經被分配了——分別對應三個主分片，這意味著在丟失任意一個節點的情況下依舊可以保證資料的完整性。
文件的索引將首先被儲存在主分片中，然後併發複製到對應的複製節點上。這可以確保我們的資料在主節點和複製節點上都可以被檢索。
cluster-health現在的狀態是green，這意味著所有的6個分片（三個主分片和三個複製分片）都已可用：
{
"cluster_name": "elasticsearch",
"status": "green", <1>
"timed_out": false,
"number_of_nodes": 2,
"number_of_data_nodes": 2,
"active_primary_shards": 3,
"active_shards": 6,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0
}
複製程式碼我們的叢集不僅是功能完備的，而且是高可用的。
橫向擴充套件
隨著應用需求的增長，我們該如何擴充套件？如果我們啟動第三個節點，我們的叢集會重新組織自己，就像圖4：
Node3包含了分別來自Node 1和Node 2的一個分片，這樣每個節點就有兩個分片，和之前相比少了一個，這意味著每個節點上的分片將獲得更多的硬體資源（CPU、RAM、I/O）。
分片本身就是一個完整的搜尋引擎，它可以使用單一節點的所有資源。我們擁有6個分片（3個主分片和三個複製分片），最多可以擴充套件到6個節點，每個節點上有一個分片，每個分片可以100%使用這個節點的資源。
繼續擴充套件
如果我們要擴充套件到6個以上的節點，要怎麼做？
主分片的數量在建立索引時已經確定。實際上，這個數量定義了能儲存到索引裡資料的最大數量（實際的數量取決於你的資料、硬體和應用場景）。然而，主分片或者複製分片都可以處理讀請求——搜尋或文件檢索，所以資料的冗餘越多，我們能處理的搜尋吞吐量就越大。
複製分片的數量可以在執行中的叢集中動態地變更，這允許我們可以根據需求擴大或者縮小規模。讓我們把複製分片的數量從原來的1增加到2：
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
複製程式碼圖5：增加number_of_replicas到2：
從圖中可以看出，blogs索引現在有9個分片：3個主分片和6個複製分片。這意味著我們能夠擴充套件到9個節點，再次變成每個節點一個分片。這樣使我們的搜尋效能相比原始的三節點叢集增加三倍。
當然，在同樣數量的節點上增加更多的複製分片並不能提高效能，因為這樣做的話平均每個分片的所佔有的硬體資源就減少了（譯者注：大部分請求都聚集到了分片少的節點，導致一個節點吞吐量太大，反而降低效能），你需要增加硬體來提高吞吐量。
不過這些額外的複製節點使我們有更多的冗餘：通過以上對節點的設定，我們能夠承受兩個節點故障而不丟失資料。
複製程式碼應對故障
我們已經說過Elasticsearch可以應對節點失效，所以讓我們繼續嘗試。如果我們殺掉第一個節點的程式（以下簡稱殺掉節點），我們的叢集看起來就像這樣：
圖5：殺掉第一個節點後的叢集
我們殺掉的節點是一個主節點。一個叢集必須要有一個主節點才能使其功能正常，所以叢集做的第一件事就是各節點選舉了一個新的主節點：Node 2。
主分片1和2在我們殺掉Node 1時已經丟失，我們的索引在丟失主分片時不能正常工作。如果此時我們檢查叢集健康，我們將看到狀態red：不是所有主分片都可用！
幸運的是丟失的兩個主分片的完整拷貝存在於其他節點上，所以新主節點做的第一件事是把這些在Node 2和Node 3上的複製分片升級為主分片，這時叢集健康回到yellow狀態。這個提升是瞬間完成的，就好像按了一下開關。
為什麼叢集健康狀態是yellow而不是green？我們有三個主分片，但是我們指定了每個主分片對應兩個複製分片，當前卻只有一個複製分片被分配，這就是叢集狀態無法達到green的原因，不過不用太擔心這個：當我們殺掉Node 2，我們的程式依然可以在沒有丟失資料的情況下繼續執行，因為Node 3還有每個分片的拷貝。
如果我們重啟Node 1，叢集將能夠重新分配丟失的複製分片，叢集狀況與上一節的 圖5：增加number_of_replicas到2 類似。如果Node 1依舊有舊分片的拷貝，它將會嘗試再利用它們，它只會從主分片上覆制在故障期間有資料變更的那一部分。
現在你應該對分片如何使Elasticsearch可以水平擴充套件並保證資料安全有了一個清晰的認識。接下來我們將會討論分片生命週期的更多細節。
參考：es官方文件