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": ,
      "template": "test-index-2018-*",
      "settings": {
            "index.routing.allocation.require.tag": "hot"
      }
}

　　 4. 每天计划任务更新索引的配置，将 tag 更改为 code，ElasticSearch中的索引会自动迁移到 M 台冷数据节点上

curl -XPUT http://192.168.1.92:/test-index---/_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:
discovery.zen.ping.unicast.hosts: ["192.168.1.92", "192.168.1.93"]