ElasticStack系列之二十 & 數據均衡、遷移、冷熱分離以及節點自動發現原理與機制

1. 數據均衡

　　某個shard分配到哪一個節點上，通常來講，是由 ELasticSearch 自行決定的。如下幾種狀況會觸發分配動做：

• 新索引的創建
• 索引的刪除
• 新增副本分片
• 節點增減引起的數據均衡

　　在動態分配的時候有幾個默認值須要注意，固然對應的這些默認值都是能夠修改的，具體以下：

1. ElasticSearch 默認要求全部分片都正常啓動成功之後，才能夠進行數據均衡操做，不然的話，在集羣重啓階段，會浪費太多的流量
2. ElasticSearch 默承認以有 2 個任務同時運行數據均衡。若是有節點增減且集羣壓力不高的狀況下，能夠適當增大(可經過 cluster.routing.alloction.cluster_concurrent_rebalance 參數來控制)
3. ElasticSearch 默承認以有 2 個任務同時運行數據恢復操做，前提是除了主分片重啓恢復之外的狀況下。因此，節點重啓時，能夠看到主分片迅速恢復完成，副本分片的恢復卻很慢。除了副本分片自己數據要經過網絡複製之外，併發線程自己也減小一半（默認同時又4個主分片恢復）。固然這種設置也是有道理的--> 主分片必定是本地恢復，副本分片卻須要走網絡，帶寬是有限的。
4. ElasticSearch 默認當數據磁盤使用量佔當前磁盤總空間的 85% 時，新索引分片就不會再分配到這個節點上了。在達到 90% 時，就會觸發該節點現存分片的數據均衡，把數據挪到其餘節點上去。

2. reroute 接口應用（數據遷移）

　　reroute 接口支持三種指令：allocate、move 和 cancel，咱們最經常使用的就是 allocate 和 move 指令。

　　allocate 指令：

　　　　由於負載太高等緣由，有時候個別分片可能長期處於 unassigned 狀態，咱們就能夠手動分配到指定節點上。默認狀況下不容許手動分配副本分片，因此若是是 主分片 故障，咱們須要單獨加一個 allow_primary 選項：

　　curl -XPOST 192.168.1.92:9201/_cluster/reroute -d '{
    　　"commands": [
          　　{
              　　"allocate": {
                  　　"index": "test-index",
                  　　"shard": 3,
                  　　"node": "192.168.1.95",
                  　　"allow_primary": true
              　　}
          　　}
      　　]
　　}'

　　注意：

　　　　若是是歷史數據的話，須要提早確認一下哪一個節點上保留有這個分片的實際目錄，且目錄大小最大，而後手動分配到這個節點上，以此來減小數據的丟失。

　　move 指令：

　　　　由於負載太高，磁盤利用率太高，服務器須要下線，更換磁盤等狀況。咱們此時須要從該節點一走部分分片數據到其餘節點上，那麼 move 指令就頗有用了：

　　curl -XPOST 192.168.1.92:9201/_cluster/reroute -d '{
    　　"move": [
          {
              "allocate": {
                  "index": "test-index",
                  "shard": 0,
                  "from_node": "192.168.1.95",
                  "to_node": "192.168.1.93"
              }
          }
      　]
　　}'

3. 冷熱數據讀寫分離

 　　ElasticSearch集羣一個比較突出的問題是：用戶作一次大的查詢的時候，很是大量的讀 I/O 以及 聚合計算致使機器 Load 升高，CPU 使用率上升，會阻塞到新數據的寫入，這個過程甚至會持續幾分鐘。因此，可能須要仿照MySQL集羣同樣，進行讀寫分離。具體步驟以下所示：

1. N 臺機器作熱數據的存儲，上面只存放當天的數據。這 N 臺熱數據節點上的 elasticsearch.yml 中配置： node.tag:hot
2. 除今天以外的以前的數據存放到另外 M 臺機器上。這 M 臺冷數據節點上的 elasticsearch.yml 中配置：node.tag:code
3. 模板中控制對新建的索引添加 hot 標籤

{
    "order": 0,
      "template": "test-index-2018-*",
      "settings": {
            "index.routing.allocation.require.tag": "hot"
      }
}

　　 4. 天天計劃任務更新索引的配置，將 tag 更改成 code，ElasticSearch中的索引會自動遷移到 M 臺冷數據節點上

curl -XPUT http://192.168.1.92:9201/test-index-2018-12-28/_settings -d '{
    "index": {
         "routing": {
             "allocation": {
                 "require": {
                     "tag": "code"
                }
            }
        }
    }
}'

　　這樣，寫操做集中在 N 臺熱數據節點上，大範圍的讀操做集中在 M 臺冷數據節點上。避免了堵塞影響。

4. 節點自動發現原理與機制

前提概要：

　　ElasticSearch 是一個 P2P 類型的分佈式系統，使用了 gossip 協議。

　　P2P 含義：即 peer-to-peer , 意爲 同等位置 對 同等位置，即常說的點對點類型，各個網絡中的節點是互相平等的位置，具體含義能夠經過下面介紹的 gossip 協議來進行理解。

　　gossip含義：在一個有界網絡中，每一個節點都隨機地與其餘節點通訊，通過一番雜亂無章的通訊，最終全部節點的狀態都會達成一致。每一個節點可能知道全部其餘節點，也可能僅知道幾個鄰居節點，只要這些節點能夠經過網絡連通，最終他們的狀態都是一致的，相似於疫情傳播的特色。簡單的說，要想傳播內容就須要有 「種子節點」。「種子節點」 每秒都會隨機向其餘節點發送本身所擁有的節點列表，以及須要傳播的消息。任何新加入的節點，就在這種傳播方式下很快地被全網所知道。這個協議的神奇就在它從設計開始就沒想到信息必定要傳遞給全部的節點，可是隨着時間的增加，在最終的某一時刻，全網會獲得相同的信息。

自動發現機制：

　　咱們知道，ElasticSearch 除了集羣狀態管理須要 master 節點來控制外，其餘全部的請求均可以發送到集羣內任意一節點上，這個節點能夠本身找到須要轉發給哪些節點，而且直接跟這些節點通訊。因此，從網絡架構及服務配置上來講，構建集羣所須要的配置機器簡單。在無阻礙的網絡下，全部配置了相同 cluster.name 的節點都自動歸屬到一個集羣中。ElasticSearch支持兩種自動發現策略，分別以下：

　　multicast(組播) 方式

　　只配置 cluster.name 的集羣，實際上是採用了默認的自動發現協議，即 組播(multicast) 方式。節點會在本機全部網卡接口上，使用組播地址 224.2.2.4 以 port=54328 創建組播發送 clustername 信息。

　　可是，並非全部的路由交換設備都支持且開啓了組播信息傳輸！甚至能夠說，默認狀況下，都是不開啓組播信息傳輸的。

　　因此在沒有網絡工程師的狀況下，ElasticSearch 以默認組播方式，只有在同一個交換機下的節點，才能自動發現，跨交換機的節點是沒法收到組播信息的。

　　unicast(單播) 方式

　　ElasticSearch 除了組播方式，還支持 單播(unicast) 方式。配置裏需提供幾臺節點的地址，ElasticSearch 將其視做 gossip router 角色，藉以完成集羣的發現。因爲這只是 ElasticSearch 內一個很小的功能，因此 gossip router 角色並不須要單獨配置，每一個 ElasticSearch 節點均可以擔任。因此，採用單播方式的集羣，各節點都須要配置相同的幾個節點列表做爲 router 便可。配置以下：

discovery.zen.minimum_master_nodes:3
discovery.zen.ping.unicast.hosts: ["192.168.1.92", "192.168.1.93"]