Elasticsearch之叢集。

          Elasticsearch用於構建高可用和可擴充套件的系統。擴充套件的方式可以是購買更好的伺服器（縱向擴充套件（vertical scale or scaling up））或者購買更多的伺服器（橫向擴充套件（horizontal scale or scaling out））。

          Elasticsearch雖然能從更強大的硬體中獲得更好的效能，但是縱向擴充套件有它的侷限性。真正的擴充套件應該是橫向的，它通過增加節點來均攤負載和增加可靠性。

             

• 空叢集

          如果我們啟動一個單獨的節點，他還沒有資料和索引，這個叢集看起來就像圖1.

                

                    圖1：只有一個空節點的叢集

        一個節點（node）就是一個Elasticsearch例項，而一個叢集（cluster）由一個或多個節點組成，他們具有相同的 cluster.name，他們協同工作，分享資料和負載。當加入新的節點或者刪除一個節點時，叢集就會感知到並平衡資料。

        叢集中一個節點會被選舉為主節點（master），它將臨時管理叢集級別的一些變更，例如新建或刪除索引、增加或移除節點等。主節點不參與文件級別的變更或搜尋，這意味著在流量增長的時候，該主節點不會成為叢集的瓶頸。任何節點都可以成為主節點。我們例子中的叢集只有一個節點，所以他會充當主節點的角色。

         作為使用者，我們能夠與叢集中的任何節點通訊，包括主節點。每一個節點都知道文件存在於哪個節點上，他們可以轉發請求到相應的節點上。我們訪問的節點負責收集各節點返回的資料，最後一起返回給客戶端。這一切都由Elasticsearch處理。

• 叢集健康

        在Elasticsearch叢集中可以監控很多資訊，但是隻有一個是最重要的：叢集健康（cluster health）。叢集健康有三種狀態：green、yellow或 red。

        GET /_cluster/health

       返回資訊中，status 欄位提供一個綜合的指標來表示叢集的服務狀況。三種顏色各自的含義：

• green

          所有主要分片和複製分片都可用。

• yellow

          所有主要分片可用，但不是所有複製分片都可用

• red

          不是所有的主要分片都可用

• 新增索引

        為了將資料新增到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 狀態——他們還未被分配給節點。在同一個節點上儲存相同的資料副本是沒有必要的，如果這個節點故障了，那所有的資料副本也會丟失。

        現在我們的叢集已經功能完備，但是依舊存在因硬體故障而導致資料丟失的風險。

 

• 增加故障轉移

        在單一節點上執行意味著單點故障的風險——沒有資料備份。幸運的是，要防止單點故障，我們唯一需要做的就是啟動另一個節點。

        啟動第二個節點，只要第二個節點與第一個節點有相同的 cluster.name (請看 ./config/elasticsearch.yml檔案)，它就能自動發現並加入第一個節點所在的叢集。如果沒有，檢查日誌找出哪裡出了問題。這可能是網路廣播被禁用，或者防火牆阻止了節點通訊。

        如果我們啟動了第二個節點，這個叢集看起來就像下圖。

        雙節點叢集——所有的主分片和複製分片都已分配：

      

         第二個節點已經加入叢集，三個複製分片（replica shards）也已經被分配了——分別對應三個主分片，這意味著在丟失任意一個節點的情況下依舊可以保證資料的完整性。

         文件的索引將首先被儲存在主分片中，然後併發複製到對應的複製節點上。這可以確保我們的資料在主節點和複製節點上都可以被檢索。

         cluster-health現在的狀態是green，這意味著所有的6個分片（三個主分片和三個複製分片）都已可用：

         我們的叢集不僅是功能完備的，而且是高可用的。

• 橫向擴充套件

          隨著應用需求的增長，我們該如何擴充套件？如果我們啟動第三個節點，我們的叢集會自我感知，這時便成為了三節點叢集（cluster-tree-nodes）。

          分片已經被重新分配以平衡負載：

         

        從 Node1 和 Node2 來的分片已經被移動到新的 Node3上，這樣每個節點就有兩個分片，以代替之前的三個。這意味著每個節點的硬體資源（CPU、RAM、I/O）被較少的分片共享，這樣每個分片就會有更好的表現。

        分片本身就是一個完整成熟的搜尋引擎，它可以使用單一節點的所有資源。使用這6個分片（3個主分片和3個複製分片） 我們可以擴充套件最多到6個節點，每個節點上有一個分片，這樣就可以100%使用這個節點的資源了。

• 更多擴充套件

        但是要怎麼做菜可以擴充套件我們的搜尋使之大於6個節點？

        主分片的數量在建立索引時已經給定。實際上，這個數字定義了能儲存到索引裡資料的最大數量（實際的數量取決於你的資料、硬體和使用情況）。當然，讀請求——搜尋和文件檢索——能夠通過主分片或者複製分片處理，所以資料的冗餘越多，我們能處理的搜尋吞吐量就越大。

        複製分片的數量可以在執行中的叢集中動態地變更，這允許我們可以根據需求擴大或者縮小規模。讓我們增加複製分片的數量，從原來的1變成2：

        PUT /blogs/_settings

        {

             "number_of_replicas" : 2

        }

        增加numer_of_replicas到2：

       

        從圖中可以看出， blogs 索引現在有9個分片：3個主分片和6個複製分片。這意味著我們能夠擴充套件到9個節點，再次的變成每個節點一個分片。這樣使我們的搜尋效能想必標準的三節點叢集擴充套件三倍。

        注意：當然，只是有更多的複製分片在同樣數量的節點上並不能提高我們的效能，因為每個分片都要訪問更小比重的節點資源（注：大部分請求都聚集到了分片少的節點，導致一個節點吞吐量太大，反而降低效能）。你需要增加硬體來提高吞吐量。

        不過這些額外的複製節點意味著我們有更多的冗餘：通過以上對接點的設定，我們更夠承受兩個節點故障而不丟失資料。

• 應對故障

         我們已經說過Elasticsearch可以應對節點失效，所以讓我們繼續嘗試。如果我們殺掉第一個節點的程式（以下簡稱殺掉節點），看起來像如此：

        

        我們殺掉的節點時一個主節點。必須有一個主節點。必須有一個主節點來讓叢集的功能可用，所以發生的第一件事就是各節點選舉了一個新的主節點： Node 2。

        主分片 1 和 2在我們殺掉 Node 1時已經丟失，我們的索引在丟失主節點時不能正常工作。如果此時我們檢查叢集健康，我們將看到狀態red：不是所有主節點都可用！

        幸運的是丟失的兩個主分片的完整拷貝在其他節點上還存在，所以新主節點的第一件事是提升這些在 Node 2 和 Node3 上的分片的副本為主分片，叢集健康回到yellow狀態。這個提升是瞬間完成的，就好像按了一下開關。

        為什麼叢集健康狀態是yellow 而不是 green ？ 我們有三個主分片，但是我們指定了每個主分片對應兩個複製分片，當前卻只有一個被定義。這阻止我們達到 green狀態，不過不用太擔心這個：當我們殺掉 Node 2，我們的程式依舊可以在沒有丟失資料的情況下執行，因為 Node3 還有每個分片的拷貝。

        如果我們重啟 Node 1，叢集將能夠分批額丟失的複製分片，結果狀態與三主節點雙複製一致。如果 Node 1 依舊有舊節點的拷貝，它將會嘗試再利用他們，它只會複製在故期間資料變更的部分。