elasticsearch—分布式特性及分布式搜索的机制

 维护并且更新 Cluster State 集群分布式模型及选主与脑裂问题

分布式特性

● Elasticsearch 的分布式架构带来的好处

• 存储的⽔平扩容，⽀持 PB 级数据

• 提⾼系统的可⽤性，部分节点停⽌服务，整个集群的服务不受影响

● Elasticsearch 的分布式架构

• 不同的集群通过不同的名字来区分，默认名字 “elasticsearch”

• 通过配置⽂件修改，或者在命令⾏中 -E cluster.name=geektime 进⾏设定

节点

节点是⼀个 Elasticsearch 的实例

• 其本质上就是⼀个 JAVA 进程

• ⼀台机器上可以运⾏多个 Elasticsearch 进程，但是⽣产环境⼀般建议⼀台机器上就 运⾏⼀个 Elasticsearch 实例

每⼀个节点都有名字，通过配置⽂件配置，或者启动时候 -E node.name=geektime 指定

每⼀个节点在启动之后，会分配⼀个 UID，保存在 data ⽬录下

Coordinating Node （协调节点）

处理请求的节点，叫 Coordinating Node

• 路由请求到正确的节点，例如创建索引的请求，需要路由到 Master 节点

所有节点默认都是 Coordinating Node

通过将其他类型设置成 False，使其成为 Dedicated Coordinating Node

Demo – 启动节点，Cerebro 介绍

命令行方式启动集群

bin/elasticsearch -E node.name=node1 -E cluster.name=geektime -E path.data=node1_data -E http.port=9200 -E network.host=0.0.0.0 -E node.master=true
bin/elasticsearch -E node.name=node2 -E cluster.name=geektime -E path.data=node2_data -E http.port=9201 -E network.host=0.0.0.0 -E node.master=true
bin/elasticsearch -E node.name=node3 -E cluster.name=geektime -E path.data=node3_data -E http.port=9202 -E network.host=0.0.0.0 -E node.master=true

Cerebro 下载地址

• https://github.com/lmenezes/cerebro/releases

访问cerobro

• http://192.168.163.131:9000/

 创建索引 test 分片数设置3 副本数设置为1

 Data Node

可以保存数据的节点，叫做 Data Node 

• 节点启动后，默认就是数据节点。可以设置 node.data: false 禁⽌

Data Node的职责

• 保存分⽚数据。在数据扩展上起到了⾄关重要的作⽤（由 Master Node 决定如何把 分⽚分 发到数据节点上）

通过增加数据节点

• 可以解决数据⽔平扩展和解决数据单点问题

Master Node

Master Node 的职责

• 处理创建，删除索引等请求 /决定分⽚被分配到哪个节点 / 负责索引的创建与删除

• 维护并且更新 Cluster State

Master Node 的最佳实践

• Master 节点⾮常重要，在部署上需要考虑解决单点的问题

• 为⼀个集群设置多个 Master 节点 / 每个节点只承担 Master 的单⼀⻆⾊

Master Eligible Nodes & 选主流程

⼀个集群，⽀持配置多个 Master Eligible 节点。这些节点可以在必要时(如 Master 节点出 现故障，⽹络故障时)参与选主流程，成为 Master 节点

每个节点启动后，默认就是⼀个 Master eligible 节点

• 可以设置 node.master: false 禁⽌

当集群内第⼀个 Master eligible 节点启动时候，它会将⾃⼰选举成 Master 节点

集群状态

集群状态信息（Cluster State），维护了⼀个集群中，必要的信息

• ○ 所有的节点信息

• ○ 所有的索引和其相关的 Mapping 与 Setting 信息

• ○ 分⽚的路由信息

在每个节点上都保存了集群的状态信息

但是，只有 Master 节点才能修改集群的状态信息，并负责同步给其他节点，因为，任意节点都能修改信息会导致 Cluster State 信息的不⼀致

Master Eligible Nodes & 选主的过程

● 互相 Ping 对⽅，Node Id 低的会成为被选举的节点

● 其他节点会加⼊集群，但是不承担 Master 节点的⻆⾊。⼀旦发现被选中的主节点丢失， 就会选举出新的 Master 节点

 脑裂问题

Split-Brain，分布式系统的经典⽹络问题，当出现⽹络问题，⼀个节点和其他节点⽆法连接

• Node 2 和 Node 3 会重新选举 Master

• Node 1 ⾃⼰还是作为 Master，组成⼀个集群，同时更新 Cluster State

• 导致 2 个 master，维护不同的 cluster state。当⽹络恢复时，⽆法选择正确恢复 node 1 node 2 node 3 ⽹络断开

 如何避免脑裂问题

限定⼀个选举条件，设置 quorum(仲裁)，只有在 Master eligible 节点数⼤于 quorum 时，才能 进⾏选举

• Quorum = （master 节点总数 /2）+ 1

• 当 3 个 master eligible 时，设置 discovery.zen.minimum_master_nodes 为 2，即可避免脑裂

从 7.0 开始，⽆需这个配置

• 移除 minimum_master_nodes 参数，让Elasticsearch⾃⼰选择可以形成仲裁的节点

• 典型的主节点选举现在只需要很短的时间就可以完成。集群的伸缩变得更安全、更容易，并且可能造成丢 失数据的系统配置选项更少了

• 节点更清楚地记录它们的状态，有助于诊断为什么它们不能加⼊集群或为什么⽆法选举出主节点

配置节点类型

⼀个节点默认情况下是⼀个 Master eligible，data and ingest node

 分⽚与集群的故障转移

Primary Shard （主分片）- 提升系统存储容量

分⽚是 Elasticsearch 分布式存储的基⽯

• 主分⽚ / 副本分⽚

通过主分⽚，将数据分布在所有节点上

• Primary Shard，可以将⼀份索引的数据，分散在多个 Data Node 上，实现存储的⽔平扩展

• 主分⽚(Primary Shard)数在索引创建时候指定，后续默认不能修改，如要修改，需重建索引

Replica Shard （副本分片）- 提⾼数据可⽤性

数据可⽤性

• 通过引⼊副本分⽚ (Replica Shard) 提⾼数据的可⽤性。⼀旦主分⽚丢失，副本分⽚可以 Promote 成主分 ⽚。副本分⽚数可以动态调整。每个节点上都有完备的数据。如果不设置副本分⽚，⼀旦出现节点硬件故 障，就有可能造成数据丢失

提升系统的读取性能

• 副本分⽚由主分⽚(Primary Shard)同步。通过⽀持增加 Replica 个数，⼀定程度可以提⾼读取的吞吐量

分⽚数的设定（默认一个主分片 0个副本分片）

如何规划⼀个索引的主分⽚数和副本分⽚数

• 主分⽚数过⼩：例如创建了 1 个 Primary Shard 的 Index，如果该索引增⻓很快，集群⽆法通过增加节点实现对这个索引的数据扩展

• 主分⽚数设置过⼤：导致单个 Shard 容量很⼩，引发⼀个节点上有过多分⽚，影响性能

• 副本分⽚数设置过多，会降低集群整体的写⼊性能

集群健康状态

 ⽂档分布式存储

⽂档存储在分⽚上

⽂档会存储在具体的某个主分⽚和副本分⽚上：例如 ⽂档 1， 会存储在 P0 和 R0 分⽚上

⽂档到分⽚的映射算法

• 确保⽂档能均匀分布在所⽤分⽚上，充分利⽤硬件资源，避免部分机器空闲，部分机器繁忙

• 潜在的算法

  • 随机 / Round Robin。当查询⽂档 1，分⽚数很多，需要多次查询才可能查到 ⽂档 

  • 维护⽂档到分⽚的映射关系，当⽂档数据量⼤的时候，维护成本⾼

  • 实时计算，通过⽂档 1，⾃动算出，需要去那个分⽚上获取⽂档

⽂档到分⽚的路由算法

shard = hash(_routing) % number_of_primary_shards

• Hash 算法确保⽂档均匀分散到分⽚中

• 默认的 _routing 值是⽂档 id

• 可以⾃⾏制定 routing数值，例如⽤相同国家的商品，都分配到指定的 shard

• 设置 Index Settings 后， Primary 数，不能随意修改的根本原因

 更新⼀个⽂档

 删除⼀个文档

 分⽚及其⽣命周期

 分⽚的内部原理

 什么是 ES 的分⽚

•  ES 中最⼩的⼯作单元 / 是⼀个 Lucene 的 Index

 ⼀些问题：

•  为什么 ES 的搜索是近实时的(1 秒后被搜到)

•  ES 如何保证在断电时数据也不会丢失

•  为什么删除⽂档，并不会⽴刻释放空间

 倒排索引不可变性

 倒排索引采⽤ Immutable Design，⼀旦⽣成，不可更改

•  不可变性，带来了的好处如下：

•  ⽆需考虑并发写⽂件的问题，避免了锁机制带来的性能问题

•  ⼀旦读⼊内核的⽂件系统缓存，便留在哪⾥。只要⽂件系统存有⾜够的空间，⼤部分请求就会直接请求内 存，不会命中磁盘，提升了很⼤的性能

•  缓存容易⽣成和维护 / 数据可以被压缩

 不可变更性，带来了的挑战：如果需要让⼀个新的⽂档可以被搜索，需要重建整个索引。

 Lucene Index

 什么是 Refresh

 什么是 Transaction Log

 什么是 Flush

 Merge

Segment 很多，需要被定期被合并

• 减少 Segments / 删除已经删除的⽂档

ES 和 Lucene 会⾃动进⾏ Merge 操作

• POST my_index/_forcemerge

 剖析分布式查询及相关性算分

 分布式搜索的运⾏机制

Elasticsearch 的搜索，会分两阶段进⾏

• 第⼀阶段 - Query

• 第⼆阶段 - Fetch

Query-then-Fetch

Query 阶段

 Fetch 阶段

 Query Then Fetch 潜在的问题

性能问题

• 每个分⽚上需要查的⽂档个数 = from + size

• 最终协调节点需要处理：number_of_shard * ( from+size )

• 深度分⻚

相关性算分

• 每个分⽚都基于⾃⼰的分⽚上的数据进⾏相关度计算。这会导致打分偏离的情况，特别是 数据量很少时。相关性算分在分⽚之间是相互独⽴。当⽂档总数很少的情况下，如果主分 ⽚⼤于 1，主分⽚数越多 ，相关性算分会越不准

解决算分不准的⽅法

数据量不⼤的时候，可以将主分⽚数设置为 1

• 当数据量⾜够⼤时候，只要保证⽂档均匀分散在各个分⽚上，结果⼀般就不会出现 偏差

使⽤ DFS Query Then Fetch

• 搜索的URL 中指定参数 “_search?search_type=dfs_query_then_fetch”

• 到每个分⽚把各分⽚的词频和⽂档频率进⾏搜集，然后完整的进⾏⼀次相关性算分， 耗费更加多的 CPU 和内存，执⾏性能低下，⼀般不建议使⽤

POST message/_search?search_type=dfs_query_then_fetch
{
  "query": {
    "term": {
      "content": {
        "value": "good"
      }
    }
  }
}

排序及 Doc Values & Field Data　　

排序　

• Elasticsearch 默认采⽤相关性算分对结果进⾏ 降序排序

• 可以通过设定 sorting 参数，⾃⾏设定排序

• 如果不指定_score，算分为 Null

POST /kibana_sample_data_ecommerce/_search
{
  "size": 5,
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "order_date": {
        "order": "desc"
      }
    }
  ]
}