一、概述

Elasticsearch是一个基于Lucene的搜索引擎。它提供了具有HTTP Web界面和无架构JSON文档的分布式，多租户能力的全文搜索引擎。Elasticsearch是用Java开发的，根据Apache许可条款作为开源发布。

二、节点类型&作用

1）master节点(主节点)

配置

node.master:true
node.data:false(这里也可以配置成node.data:true)

【注意】node.master和node.data默认都是true, 但还是建议显式配置

作用

• 索引的创建或删除
• 跟踪哪些节点是集群的一部分
• 决定哪些分片分配给相关的节点

2）data节点(数据节点)

配置

node.master:false(这里也可以配置成node.master:true)
node.data:true

作用

• 存储索引数据
• 对文档进行增删改查,聚合操作

3）Coordinating节点(协调节点/Client节点)

每一个节点都隐式的是一个协调节点，Coordinating节点是负责接收任何 Client 的请求，包括 REST Client 等。该节点将请求分发到合适的节点，最终把结果汇集到一起。一般来说，每个节点默认起到了 Coordinating节点 的职责。
配置

node.master:false
node.data:false

作用

• 处理路由请求
• 处理搜索
• 分发索引

4）Ingest节点(预处理节点)

在索引数据之前可以先对数据做预处理操作，所有节点其实默认都是支持 Ingest 操作的，也可以专门将某个节点配置为 Ingest 节点。
配置

node.ingest:true

作用

• Ingest节点和集群中的其他节点一样，但是它能够创建多个处理器管道，用以修改传入文档。类似 最常用的Logstash过滤器已被实现为处理器。
• Ingest节点 可用于执行常见的数据转换和丰富。 处理器配置为形成管道。 在写入时，Ingest Node有20个内置处理器，例如grok，date，gsub，小写/大写，删除和重命名
• 在批量请求或索引操作之前，Ingest节点拦截请求，并对文档进行处理。

三、Elasticsearch 是如何实现 master 选举的

前提条件

• 只有候选主节点（master：true）的节点才能成为主节点。
• 最小主节点数（min_master_nodes）的目的是防止脑裂。

实现步骤

• 第一步：确认候选主节点数达标，elasticsearch.yml 设置的值discovery.zen.minimum_master_nodes;
• 第二步：对所有候选主节点根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。
• 第三步：如果对某个节点的投票数达到一定的值（候选主节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。

【补充】master 节点的职责主要包括集群、节点和索引的管理，不负责文档级别的管理；data 节点可以关闭 http 功能。

四、如何解决ES集群的脑裂问题

【原因】

所谓集群脑裂，是指 Elasticsearch 集群中的节点（比如共 20 个），其中的 10 个选了一个 master，另外 10 个选了另一个 master 的情况。

【解决】

当集群 master 候选数量不小于 3 个时，可以通过设置最少投票通过数量（discovery.zen.minimum_master_nodes）超过所有候选节点一半以上来解决脑裂问题；

五、调优

1）部署时，对 Linux 的设置优化方法

• 关闭缓存 swap;
• 堆内存设置为：Min（节.点内存/2,理想是 32GB）;
• 设置最大文件句柄数；
• 线程池+队列大小根据业务需要做调整；
• 磁盘存储 raid 方式——存储有条件使用 RAID10，增加单节点性能以及避免单节点存储故障。

2）写入调优

• 写入前副本数设置为 0；
• 写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
• 写入过程中：采取 bulk 批量写入；
• 写入后恢复副本数和刷新间隔；
• 尽量使用自动生成的 id。

3）查询调优

• 禁用 wildcard（wildcard 检索可以定义为：支持通配符的模糊检索。类似于mysql的like）；
• 禁用批量 terms（成百上千的场景）；
• 充分利用倒排索引机制，能 keyword 类型尽量 keyword；
• 据量大时候，可以先基于时间敲定索引再检索；
• 设置合理的路由机制。

六、Elasticsearch 索引文档的过程

这里的索引文档应该理解为文档写入 ES，创建索引的过程。
文档写入包含：单文档写入和批量 bulk 写入，这里只解释一下：单文档写入流程。

• 第一步：客户写集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，请求的节点扮演路由节点的角色。）
• 第二步：节点 1 接受到请求后，使用文档_id 来确定文档属于分片 0。请求会被转到另外的节点，假定节点 3。因此分片 0 的主分片分配到节点 3 上。
• 第三步：节点 3 在主分片上执行写操作，如果成功，则将请求并行转发到节点 1和节点 2 的副本分片上，等待结果返回。所有的副本分片都报告成功，节点 3 将向协调节点（节点 1）报告成功，节点 1 向请求客户端报告写入成功。

七、索引模板

索引模板，简而言之，是一种复用机制，就像一些项目的开发框架如 Laravel 一样，省去了大量的重复，体力劳动。当新建一个 Elasticsearch 索引时，自动匹配模板，完成索引的基础部分搭建。

典型的如下所示：

{
  "order": 0,
  "template": "sample_info*",
  "settings": {
    "index": {
      "number_of_shards": "64",
      "number_of_replicas": "1"
    }
  },
  "mappings": {
    "info": {
      "dynamic_templates": [
        {
          "string_fields": {
            "mapping": {
              "analyzer": "only_words_analyzer",
              "index": "analyzed",
              "type": "string",
              "fields": {
                "raw": {
                  "ignore_above": 512,
                  "index": "not_analyzed",
                  "type": "string"
                }
              }
            },
            "match_mapping_type": "string",
            "match": "*"
          }
        }
      ]，
    "properties": {
        "user_province": {
          "analyzer": "lowercase_analyzer",
          "index": "analyzed",
          "type": "string",
          "fields": {
            "raw": {
              "ignore_above": 512,
              "index": "not_analyzed",
              "type": "string"
            }
          }
        }
      }
    }
  },
  "aliases": {}
}

上述模板定义，看似复杂，拆分来看，主要为如下几个部分：

{
  "order": 0,                               // 模板优先级
  "template": "sample_info*",               // 模板匹配的名称方式
  "settings": {...},                        // 索引设置
  "mappings": {...},                        // 索引中各字段的映射定义
  "aliases": {...}                          // 索引的别名
}

1）模板优先级

一个模板可能绝大部分符合新建索引的需求，但是局部需要微调，此时，如果复制旧的模板，修改该模板后，成为一个新的索引模板即可达到我们的需求，但是这操作略显重复。此时，可以采用模板叠加与覆盖来操作。模板的优先级是通过模板中的 order 字段定义的，数字越大，优先级越高。

如下为定义所有以 te 开头的索引的模板：

{
    "order": 0
    "template" : "te*",
    "settings" : {
        "number_of_shards" : 1
    },
    "mappings" : {
        "type1" : {
            "_source" : { "enabled" : false }
        }
    }
}

索引模板是有序合并的。如何想单独修改某一小类索引的一两处单独设置，可以在累加一层模板：

{
    "order" : 1,
    "template" : "tete*",
    "settings" : {
        "number_of_shards" : 2
    },
    "mappings" : {
        "type1" : {
            "_all" : { "enabled" : false }
        }
    }
}

上述第一个模板的 order 为0，第二个模板的 order 为1，优先级高于第一个模板，其会覆盖第一个模板中的相同项。所以对于所有以 tete 开头的索引模板效果如下：

{
    "settings" : {
        "number_of_shards" : 2
    },
    "mappings" : {
        "type1" : {
            "_source" : { "enabled" : false },
            "_all" : { "enabled" : false }
        }
    }
}

两个模板叠加了，项目的字段，优先级高的覆盖了优先级低的，如分片数。

2）索引模板的匹配

索引模板中的 "template" 字段定义的是该索引模板所应用的索引情况。如 "template": "tete*" 所表示的含义是，当新建索引时，所有以 tete 开头的索引都会自动匹配到该索引模板。利用该模板进行相应的设置和字段添加等。

3）setting 部分

索引模板中的 setting 部分一般定义的是索引的主分片、拷贝分片、刷新时间、自定义分析器等。常见的 setting 部分结构如下：

"settings": {
    "index": {
      "analysis": {...},                // 自定义的分析器
      "number_of_shards": "32",         // 主分片的个数
      "number_of_replicas": "1",        // 主分片的拷贝分片个数
      "refresh_interval": "5s"          // 刷新时间
    }
  }

八、冷热数据分离

ES集群的索引写入及查询速度主要依赖于磁盘的IO速度，冷热数据分离的关键为使用SSD磁盘存储数据。若全部使用SSD，成本过高，且存放冷数据较为浪费，因而使用普通SATA磁盘与SSD磁盘混搭，可做到资源充分利用，性能大幅提升的目标。为了解决控制成本的前提下读写性能问题，Elasticsearch冷热分离架构应运而生。

• 冷数据索引：查询频率低，基本无写入，一般为当天或最近2天以前的数据索引
• 热数据索引：查询频率高，写入压力大，一般为当天数据索引

1）实现原理

• Hot节点设置：索引节点（写节点），同时保持近期频繁使用的索引。 属于IO和CPU密集型操作，建议使用SSD的磁盘类型，保持良好的写性能；节点的数量设置一般是大于等于3个。将节点设置为hot类型：

node.attr.box_type: hot

• Warm节点设置： 用于不经常访问的read-only索引。由于不经常访问，一般使用普通的磁盘即可。内存、CPU的配置跟Hot节点保持一致即可；节点数量一般也是大于等于3个。将节点设置为warm类型：

node.attr.box_type: warm

es1：master节点

# elasticsearch.yml
node.name: "master"
cluster.name: "test-cluster"
network.host: 0.0.0.0
node.master: true
node.data: false

es2、es3、es4 热数据节点

# elasticsearch.yml
node.name: "hot-datanode-00x" # 提示：自行修改其他节点的名称
cluster.name: "test-cluster"
network.host: 0.0.0.0
node.master: false
node.data: true
discovery.zen.ping.unicast.hosts: ["master"]
node.attr.box_type: "hot"  # 标识为热数据节点

es5、es6 冷/温数据节点

# elasticsearch.yml
node.name: "cold-datanode-00x" # 提示：自行修改其他节点的名称cluster.name: "docker-cluster" network.host: 0.0.0.0 node.master: false node.data: true discovery.zen.ping.unicast.hosts: ["master"] node.attr.box_type: "warm" # 标识为温数据节点

九、分片不均衡原因&解决方案

原因

可能存在的部分原因有以下几种：

• Shard设置不合理。

说明：大多数负载不均问题是由于shard设置不合理导致，建议优先排查。

• Segment大小不均。
• 存在典型的冷热数据需求场景。

说明：例如查询中添加了routing或查询频率较高的热点数据，则必然导致数据出现负载不均。

• 没有释放长连接，导致流量不均。

说明：该问题时常暴露于采用负载均衡及多可用区架构部署时。

解决方案

1）方案一：手动移动分片

例如移动node-1的分片0到node-4

curl -XPOST 'http://localhost:9200/_cluster/reroute' -d '{
  "commands":[{
  "move":{
    "index":"indexName",
    "shard":0,
    "from_node":"node-1",
    "to_node":"node-4"
}}]}'

• 优点：操作简单，恢复时间短；不必修改master node的配置，master node长期负载后高
• 缺点：索引大，移动时有很高的IO，索引容易损坏，需要做备份，不能解决master node既是数据节点又是负载均衡转发器的问题

【注意】分片和副本无法移动到同一个节点

2）方案二：重建索引，从另外一个集群导入

删除原来的索引，重新建立索引，；利用elasticsearch dump等工具从另一个集群中把数据导入到新的索引中

• 优点：可以重新配置master node和data node，主从负载均匀
• 缺点：费时间，容易数据丢失，需要验证数据的一致性

3）方案三：配置平衡参数

使用下面的命令恢复平衡

PUT_cluster/settings
{
	"persistent": {
		"cluster.routing.rebalance.enable": "all"
	}
}

十、解决Elasticsearch分片未分配的问题

原因整体概述：

• 出现这个问题的原因是原有分片未正常关闭和清理，所以当分片要重新分配回出问题节点的时候没有办法获得分片锁。
• 这不会造成分片数据丢失，只需要重新触发一下分配。

unassigned 分片问题可能的原因如下:

1. INDEX_CREATED: 由于创建索引的API导致未分配。
2. CLUSTER_RECOVERED: 由于完全集群恢复导致未分配。
3. INDEX_REOPENED: 由于打开open或关闭close一个索引导致未分配。
4. DANGLING_INDEX_IMPORTED: 由于导入dangling索引的结果导致未分配。
5. NEW_INDEX_RESTORED: 由于恢复到新索引导致未分配。
6. EXISTING_INDEX_RESTORED: 由于恢复到已关闭的索引导致未分配。
7. REPLICA_ADDED: 由于显式添加副本分片导致未分配。
8. ALLOCATION_FAILED: 由于分片分配失败导致未分配。
9. NODE_LEFT: 由于承载该分片的节点离开集群导致未分配。
10. REINITIALIZED: 由于当分片从开始移动到初始化时导致未分配（例如，使用影子shadow副本分片）。
11. REROUTE_CANCELLED: 作为显式取消重新路由命令的结果取消分配。
12. REALLOCATED_REPLICA: 确定更好的副本位置被标定使用，导致现有的副本分配被取消，出现未分配。

解决方案如下：
执行修复命令

POST /_cluster/reroute?retry_failed

十一、ES读写数据过程

1）ES写入数据的过程

• 客户端发送任何一个请求到任意一个node，这个节点就成为协调节点（coordinate node）
• 协调节点对document（可以手动设置doc id，也可以由系统分配）进行hash路由，将请求转发给对应的node
• node上的primary shard处理请求，然后将数据同步到replica node
• 协调节点如果发现primary shard所在的node和所有的replica shard所对应的node都搞定之后，就会将请求返回给客户端

2）ES读数据过程

可以通过doc id来查询，根据doc id进行hash，判断当时写这个document时是分配到哪个shard上去了，然后就去那个shard上查询。

• 客户端发送任何一个请求到任意一个node，这个节点就成为协调节点（coordinate node）
• 协调节点对doc id进行hash路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及所有的replica shard中随机选择一个，让读请求负载均衡
• 接受请求的node，返回document给协调节点
• 协调节点再将数据返回给客户端

十二、在海量数据中提高效率的几个手段

• filesystem cache：ES的搜索引擎严重依赖底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的index segment file索引数据文件
• 数据预热：对于那些你觉得比较热的数据，即经常会有人访问的数据，最好做一个专门的缓存预热子系统，对于热数据，每隔一段时间，系统本身就提前访问一下，让数据进入filesystem cache里面去，这样下次访问的时候，性能会更好一些。
• 冷热分离：冷数据索引：查询频率低，基本无写入，一般为当天或最近2天以前的数据索引，这种数据可以存储在机械硬盘HDD中热数据索引：查询频率高，写入压力大，一般为当天的数据索引，这种数据可以存储在SSD中
• document的模型设计：不要在搜索的时候去执行各种复杂的操作，尽量在document模型设计和数据写入的时候就将复杂操作处理掉
• 分页性能优化：翻页的时候，翻得越深，每个shard返回的数据越多，而且协调节点处理的时间越长，此时，要用scroll，scroll会一次性的生成所有数据的快照，然后每次翻页都是通过移动游标来完成