<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          elasticsearch集群擴(kuò)容和容災(zāi)

          共 5688字,需瀏覽 12分鐘

           ·

          2021-04-12 23:09



          點擊上方藍(lán)色“邁莫coding”,選擇“設(shè)為星標(biāo)”



          一、集群健康

           

          Elasticsearch 的集群監(jiān)控信息中包含了許多的統(tǒng)計數(shù)據(jù),其中最為重要的一項就是集群健康,它在 status 字段中展示為 green 、 yellow 或者 red。

           

          在kibana中執(zhí)行:GET /_cat/health?v

          1 epoch      timestamp cluster        status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent2 1568794410 08:13:30  my-application yellow          1         1     47  47    0    0       40             0                  -                 54.0%
           

          其中我們可以看到當(dāng)前我本地的集群健康狀態(tài)是yellow ,但這里問題來了,集群的健康狀況是如何進(jìn)行判斷的呢?

          green(很健康)    所有的主分片和副本分片都正常運行。yellow(亞健康)    所有的主分片都正常運行,但不是所有的副本分片都正常運行。red(不健康)    有主分片沒能正常運行。

           

           注意:

           

          我本地只配置了一個單節(jié)點的elasticsearch,因為primary shard和replica shard是不能分配到一個節(jié)點上的所以,在我本地的elasticsearch中是不存在replica shard的,所以健康狀況為yellow。

           

          二、shard和replica

           


          為了將數(shù)據(jù)添加到Elasticsearch,我們需要索引(index)——一個存儲關(guān)聯(lián)數(shù)據(jù)的地方。實際 上,索引只是一個用來指向一個或多個分片(shards)的“邏輯命名空間(logical namespace)”. 一個分片(shard)是一個最小級別“工作單元(worker unit)”,它只是保存了索引中所有數(shù)據(jù)的一 部分。

           

          道分片就是一個Lucene實例,并且它本身就是一個完整的搜索引擎。我們的文檔存儲在分片中,并且在分片中被索引,但是我們的應(yīng)用程序不會直接與它們通信,取而代之的是,直接與索引通信。分片是Elasticsearch在集群中分發(fā)數(shù)據(jù)的關(guān)鍵。把分片想象成數(shù)據(jù)的容器。文檔存儲在分片中,然后分片分配到你集群中的節(jié)點上。當(dāng)你的集群擴(kuò)容或縮小,Elasticsearch將會自動在你的節(jié)點間遷移分片,以使集群保持平衡。分片可以是主分片(primary shard)或者是復(fù)制分片(replica shard)。

           

          你索引中的每個文檔屬于一個單獨的主分片,所以主分片的數(shù)量決定了索引最多能存儲多少數(shù)據(jù)。理論上主分片能存儲的數(shù)據(jù)大小是沒有限制的,限制取決于你實際的使用情況。分片的最大容量完全取決于你的使用狀況:硬件存儲的大小、文檔的大小和復(fù)雜度、如何索引 和查詢你的文檔,以及你期望的響應(yīng)時間。

           

          復(fù)制分片只是主分片的一個副本,它可以防止硬件故障導(dǎo)致的數(shù)據(jù)丟失,同時可以提供讀請 求,比如搜索或者從別的shard取回文檔。當(dāng)索引創(chuàng)建完成的時候,主分片的數(shù)量就固定了,但是復(fù)制分片的數(shù)量可以隨時調(diào)整。讓我們在集群中唯一一個空節(jié)點上創(chuàng)建一個叫做 blogs 的索引。默認(rèn)情況下,一個索引被分配5個主分片,一個主分片默認(rèn)只有一個復(fù)制分片。

           

          重點:
          shard分為兩種:    1,primary shard --- 主分片    2,replica shard --- 復(fù)制分片(或者稱為備份分片或者副本分片)

           

          需要注意的是,在業(yè)界有一個約定俗稱的東西,單說一個單詞shard一般指的是primary shard,而單說一個單詞replica就是指的replica shard。

           

          另外一個需要注意的是replica shard是相對于索引而言的,如果說當(dāng)前index有一個復(fù)制分片,那么相對于主分片來說就是每一個主分片都有一個復(fù)制分片,即如果有5個主分片就有5個復(fù)制分片,并且主分片和復(fù)制分片之間是一一對應(yīng)的關(guān)系。

           

          很重要的一點:primary shard不能和replica shard在同一個節(jié)點上。重要的事情說三遍:

           

          primary shard不能和replica shard在同一個節(jié)點上

          primary shard不能和replica shard在同一個節(jié)點上

          primary shard不能和replica shard在同一個節(jié)點上

           

          所以es最小的高可用配置為兩臺服務(wù)器。 

           

          三、master節(jié)點、協(xié)調(diào)節(jié)點和節(jié)點對等特性

           

          elasticsearch同大多數(shù)的分布式架構(gòu),也會進(jìn)行主節(jié)點的選舉,elasticsearch選舉出來的主節(jié)點主要承擔(dān)一下工作:

           

          1 集群層面的設(shè)置2 集群內(nèi)的節(jié)點維護(hù)3 集群內(nèi)的索引、映射(mapping)、分詞器的維護(hù)4 集群內(nèi)的分片維護(hù)

           

          不同于hadoop、mysql等的主節(jié)點,elasticsearch的master將不會成為整個集群環(huán)境的流量入口,即其并不獨自承擔(dān)文檔級別的變更和搜索(curd),也就意味著當(dāng)流量暴增,主節(jié)點的性能將不會成為整個集群環(huán)境的性能瓶頸。這就是elasticsearch的節(jié)點對等特性。

           

          • 節(jié)點對等:

           

          所謂的節(jié)點對等就是在集群中每個節(jié)點扮演的角色都是平等的,也就意味著每個節(jié)點都能成為集群的流量入口,當(dāng)請求進(jìn)入到某個節(jié)點,該節(jié)點就會暫時充當(dāng)協(xié)調(diào)節(jié)點的角色,對請求進(jìn)行路由和處理。這是一個區(qū)別于其他分布式中間件的很重要的特性。節(jié)點對等的特性讓elasticsearch具備了負(fù)載均衡的特性。在后面對document的寫入和搜索會詳細(xì)介紹該牛叉的特性。

           

          • 協(xié)調(diào)節(jié)點:

           

          通過上面的分析,我們可以得出一個結(jié)論,協(xié)調(diào)節(jié)點其實就是請求命中的那個節(jié)點。該節(jié)點將承擔(dān)當(dāng)前請求的路由工作。

           

          四、擴(kuò)容

           

          一般的擴(kuò)容模式分為兩種,一種是水平擴(kuò)容,一種是垂直擴(kuò)容。

           


          1
          4.1、垂直擴(kuò)容:


          所謂的垂直擴(kuò)容就是升級服務(wù)器,買性能更好的,更貴的然后替換原來的服務(wù)器,這種擴(kuò)容方式不推薦使用。因為單臺服務(wù)器的性能總是有瓶頸的。

           


          1
          4.2、水平擴(kuò)容:

           

          水平擴(kuò)容也稱為橫向擴(kuò)展,很簡單就是增加服務(wù)器的數(shù)量,這種擴(kuò)容方式可持續(xù)性強(qiáng),將眾多普通服務(wù)器組織到一起就能形成強(qiáng)大的計算能力。水平擴(kuò)容 VS 垂直擴(kuò)容用一句俗語來說再合適不過了:三個臭皮匠賽過諸葛亮。

           


          1
          4.3、垂直擴(kuò)容的過程分析

           

          上面我們詳細(xì)介紹了分片,master和協(xié)調(diào)節(jié)點,接下來我們通過畫圖的方式一步步帶大家看看橫向擴(kuò)容的過程。

           

          首先呢需要鋪墊一點關(guān)于自定義索引shard數(shù)量的操作

           

           PUT /student {    "settings" : {       "number_of_shards" : 3,       "number_of_replicas" : 1    } }

           

           

          以上代碼意味著我們創(chuàng)建的索引student將會分配三個primary shard和三個replica shard(至于上面為什么是1,那是相對于索引來說的,前面解釋過)。

           

          4.3.1、一臺服務(wù)器

           

          當(dāng)我們只有一臺服務(wù)器的時候,shard是怎么分布的呢?

           

           

           注:P代表primary shard, R代表replica shard。明確一點在后面的描述中默認(rèn)一個es節(jié)點在一臺服務(wù)器上。

           

          分析一下上面的過程,首先需要明確的兩點:

           

          1. primary shard和replica shard不能再同一臺機(jī)器上,因為replica和shard在同一個節(jié)點上就起不到副本的作用了。

          2. 當(dāng)集群中只有一個節(jié)點的時候,node1節(jié)點將成為主節(jié)點。它將臨時管理集群級別的一些變更,例如新建或 刪除索引、增加或移除節(jié)點等。

           

          明確了上面兩點也就很簡單了,因為集群中只有一個節(jié)點,該節(jié)點將直接被選舉為master節(jié)點。其次我們?yōu)閟tudent索引分配了三個shard,由于只有一個節(jié)點,所以三個primary shard都被分配到該節(jié)點,replica shard將不會被分配。此時集群的健康狀況為yellow。

           

          4.3.2、增加一臺服務(wù)器

           

          接著上面繼續(xù),我們增加一臺服務(wù)器,此時shard是如何分配的呢?

           

           

          Rebalance(再平衡),當(dāng)集群中節(jié)點數(shù)量發(fā)生變化時,將會觸發(fā)es集群的rebalance,即重新分配shard。Rebalance的原則就是盡量使shard在節(jié)點中分布均勻,達(dá)到負(fù)載均衡的目的。

           

          原先node1節(jié)點上有p0、p1、p2三個primary shard,另外三個replica shard還未分配,當(dāng)集群新增節(jié)點node2,觸發(fā)集群的Rebalance,另外三個replica shard將被分配到node2上,即如上圖所示。

           

          此時集群中所有的primary shard和replica shard都是active(可用)狀態(tài)的所以此時集群的健康狀況為yellow。可見es集群的最小高可用配置就是兩太服務(wù)器。

          4.3.3、繼續(xù)新增服務(wù)器

           

           

           

           繼續(xù)新增服務(wù)器,集群將再次進(jìn)行Rebalance,在primary shard和replica shard不能分配到一個節(jié)點上的原則,這次rebalance同樣本著使shard均勻分布的原則,將會從node1上將P1,P2兩個primary shard分配到node1,node2上面,然后將node2在primary shard和replica shard不能分配到一臺機(jī)器上的原則上將另外兩個replica shard分配到node1和node2上面。

           

          注意:具體的分配方式上,可能是P0在node2上面也有可能在node3上面,但是只要本著Rebalance的原則將shard均勻分布達(dá)到負(fù)載均衡即可。

           


          五、集群容災(zāi)


          分布式的集群是一定要具備容災(zāi)能力的,對于es集群同樣如此,那es集群是如何進(jìn)行容災(zāi)的呢?接下來聽我娓娓道來。

           

          在前文我們詳細(xì)講解了primary shard和replica shard。replica shard作為primary shard的副本當(dāng)集群中的節(jié)點發(fā)生故障,replica shard將被提升為primary shard。具體的演示如下

           

           

           集群中有三臺服務(wù)器,其中node1節(jié)點為master節(jié)點,primary shard 和 replica shard的分布如上圖所示。此時假設(shè)node1發(fā)生宕機(jī),也就是master節(jié)點發(fā)生宕機(jī)。此時集群的健康狀態(tài)為red,為什么呢?因為不是所有的primary shard都是active的。

           

          具體的容災(zāi)過程如下:


          1. 重新選舉master節(jié)點,當(dāng)es集群中的master節(jié)點發(fā)生故障,此時es集群將再次進(jìn)行master的選舉,選舉出一個新的master節(jié)點。假設(shè)此時新的主節(jié)點為node2。

           

          1. node2被選舉為新的master節(jié)點,node2將作為master行駛其分片分配的任務(wù)。

           

          1. replica shard升級,此時master節(jié)點會尋找node1節(jié)點上的P0分片的replica shard,發(fā)現(xiàn)其副本在node2節(jié)點上,然后將R0提升為primary shard。這個升級過程是瞬間完成的,就像按下一個開關(guān)一樣。因為每一個shard其實都是lucene的實例。此時集群如下所示,集群的健康狀態(tài)為yellow,因為不是每一個replica shard都是active的。

           

           

          容災(zāi)的過程如上所示,其實這也是一般分布式中間件容災(zāi)備份的一般手段。如果你很了解kafka的話,這個就很容易理解了。



          分割線



          原文地址:https://www.cnblogs.com/hello-shf/p/11543468.html


          往期推薦


          實習(xí)四個多月,聊一聊自己的感受

          elasticsearch入門篇

          go語言十分鐘入門教程

          你真的知道怎么實現(xiàn)一個延遲隊列嗎?

          深度解析go context實現(xiàn)原理及其源碼

          mysql那些事兒|深入淺出mysql索引(上)

          【7天從零實現(xiàn)TORM框架】Day04:條件組件庫


          文章也會持續(xù)更新,可以微信搜索「 邁莫coding 」第一時間閱讀。每天分享優(yōu)質(zhì)文章、大廠經(jīng)驗、大廠面經(jīng),助力面試,是每個程序員值得關(guān)注的平臺。




          1. 你點的每個贊,我都認(rèn)真當(dāng)成了喜歡
          瀏覽 75
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  中文字幕无码人妻在线二区 | 亚洲操逼操| 国产精品91AV | 久草手机在线视频 | 亚洲日本无 |