剖析Elasticsearch集群系列之二：分布式的三个C、translog和Lucene段

我不是女神ヾ 2021-11-11 15:38 92阅读 0赞

转载：[http://www.infoq.com/cn/articles/anatomy-of-an-elasticsearch-cluster-part02][http_www.infoq.com_cn_articles_anatomy-of-an-elasticsearch-cluster-part02]

#### 共识——裂脑问题及法定票数的重要性 ####

[共识][Link 1]是分布式系统的一项基本挑战。它要求系统中的所有进程/节点必须对给定数据的值/状态达成共识。已经有很多共识算法诸如[Raft][]、[Paxos][]等，从数学上的证明了是行得通的。但是，Elasticsearch却实现了自己的共识系统(zen discovery)，Elasticsearch之父Shay Banon在[这篇文章][Link 2]中解释了其中的原因。zen discovery模块包含两个部分：

*  **Ping**: 执行节点使用ping来发现彼此
 *  **单播(Unicast)**:该模块包含一个主机名列表，用以控制哪些节点需要ping通

Elasticsearch是端对端的系统，其中的所有节点彼此相连，有一个master节点保持活跃，它会更新和控制集群内的状态和操作。建立一个新的Elasticsearch集群要经过一次选举，选举是ping过程的一部分，在所有符合条件的节点中选取一个master，其他节点将加入这个master节点。ping间隔参数**`ping_interval`**的默认值是1秒，ping超时参数**`ping_timeout`**的默认值是3秒。因为节点要加入，它们会发送一个请求给master节点，加入超时参数**`join_timeout`**的默认值是**`ping_timeout`**值的20倍。如果master出现问题，那么群集中的其他节点开始重新ping以启动另一次选举。这个ping的过程还可以帮助一个节点在忽然失去master时，通过其他节点发现master。

**注意：**默认情况下，client节点和data节点不参与这个选举过程。可以在**elasticsearch.yml**配置文件中，通过设置**`discovery.zen.master_election.filter_client`**属性和**`discovery.zen.master_election.filter_data`**属性为**`false`**来改变这种默认行为。

故障检测的原理是这样的，master节点会ping所有其他节点，以检查它们是否还活着；然后所有节点ping回去，告诉master他们还活着。

如果使用默认的设置，Elasticsearch有可能遭到[裂脑][Link 3]问题的困扰。在网络分区的情况下，一个节点可以认为master死了，然后选自己作为master，这就导致了一个集群内出现多个master。这可能会导致数据丢失，也可能无法正确合并数据。可以按照如下公式，根据有资格参加选举的节点数，设置法定票数属性的值，来避免爆裂的发生。

**`discovery.zen.minimum_master_nodes = int(# of master eligible nodes/2)+1`**

![05.jpeg][]

这个属性要求法定票数的节点加入新当选的master节点，来完成并获得新master节点接受的master身份。对于确保群集稳定性和在群集大小变化时动态地更新，这个属性是非常重要的。图a和b演示了在网络分区的情况下，设置或不设置**`minimum_master_nodes`**属性时，分别发生的现象。

**注意：**对于一个生产集群来说，建议使用3个节点专门做master，这3个节点将不服务于任何客户端请求，而且在任何给定时间内总是只有1个活跃。

我们已经搞清楚了Elasticsearch中共识的处理，现在让我们来看看它是如何处理并发的。

#### 并发 ####

Elasticsearch是一个分布式系统，支持并发请求。当创建/更新/删除请求到达主分片时，它也会被平行地发送到分片副本上。但是，这些请求到达的顺序可能是乱序的。在这种情况下，Elasticsearch使用[乐观并发控制][Link 4]，来确保文档的较新版本不会被旧版本覆盖。

每个被索引的文档都拥有一个版本号，版本号在每次文档变更时递增并应用到文档中。这些版本号用来确保有序接受变更。为了确保在我们的应用中更新不会导致数据丢失，Elasticsearch的API允许我们指定文件的当前版本号，以使变更被接受。如果在请求中指定的版本号比分片上存在的版本号旧，请求失败，这意味着文档已经被另一个进程更新了。如何处理失败的请求，可以在应用层面来控制。Elasticsearch还提供了其他的锁选项，可以通过[这篇][Link 5]来阅读。

当我们发送并发请求到Elasticsearch后，接下来面对的问题是——如何保证这些请求的读写一致？现在，还无法清楚回答，Elasticsearch应落在[CAP][]三角形的哪条边上，我不打算在这篇文章里解决这个素来已久的争辩。

![06.jpeg][]

但是，我们要一起看下如何使用Elasticsearch实现写读一致。

#### 一致——确保读写一致 ####

对于写操作而言，Elasticsearch支持的一致性级别，与大多数其他的数据库不同，允许预检查，来查看有多少允许写入的可用分片。可选的值有**quorum**、**one**和**all**。默认的设置为**quorum**，也就是说只有当大多数分片可用时才允许写操作。即使大多数分片可用，还是会因为某种原因发生写入副本失败，在这种情况下，副本被认为故障，分片将在一个不同的节点上重建。

对于读操作而言，新的文档只有在刷新时间间隔之后，才能被搜索到。为了确保搜索请求的返回结果包含文档的最新版本，可设置replication为**sync**(默认)，这将使操作在主分片和副本碎片都完成后才返回写请求。在这种情况下，搜索请求从任何分片得到的返回结果都包含的是文档的最新版本。即使我们的应用为了更高的索引率而设置了**replication=async**，我们依然可以为搜索请求设置参数**\_preference**为**primary**。这样，搜索请求将查询主分片，并确保结果中的文档是最新版本。

我们已经了解了Elasticsearch如何处理共识、并发和一致，让我们来看看分片内部的一些主要概念，正是这些特点让Elasticsearch成为一个分布式搜索引擎。

#### Translog(预写日志) ####

因为关系数据库的发展，预写日志(WAL)或者事务日志(translog)的概念早已遍及数据库领域。在发生故障的时候，translog能确保数据的完整性。translog的基本原理是，变更必须在数据实际的改变提交到磁盘上之前，被记录下来并提交。

当新的文档被索引或者旧的文档被更新时，Lucene索引将发生变更，这些变更将被提交到磁盘以持久化。这是一个很昂贵的操作，如果在每个请求之后都被执行。因此，这个操作在多个变更持久化到磁盘时被执行一次。正如我们在[上一篇文章][Link 6]中描述的那样，Lucene提交的冲洗(flush)操作默认每30分钟执行一次或者当translog变得太大(默认512MB)时执行。在这样的情况下，有可能失去2个Lucene提交之间的所有变更。为了避免这种问题，Elasticsearch采用了translog。所有索引/删除/更新操作被写入到translog，在每个索引/删除/更新操作执行之后（默认情况下是每5秒），translog会被同步以确保变更被持久化。translog被同步到主分片和副本之后，客户端才会收到写请求的确认。

在两次Lucene提交之间发生硬件故障的情况下，可以通过重放translog来恢复自最后一次Lucene提交前的任何丢失的变更，所有的变更将会被索引所接受。

**注意：**建议在重启Elasticsearch实例之前显式地执行冲洗translog，这样启动会更快，因为要重放的translog被清空。**POST /\_all/\_flush**命令可用于冲洗集群中的所有索引。

使用translog的冲洗操作，在文件系统缓存中的段被提交到磁盘，使索引中的变更持久化。现在让我们来看看Lucene的段。

#### Lucene的段 ####

Lucene索引是由多个段组成，段本身是一个功能齐全的倒排索引。段是不可变的，允许Lucene将新的文档增量地添加到索引中，而不用从头重建索引。对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗CPU的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。

为了解决这个问题，Elasticsearch会合并小段到一个较大的段（如下图所示），提交新的合并段到磁盘，并删除那些旧的小段。

![07.jpeg][]

这会在后台自动执行而不中断索引或者搜索。由于段合并会耗尽资源，影响搜索性能，Elasticsearch会节制合并过程，为搜索提供足够的可用资源。

转载于:https://www.cnblogs.com/haoxinyue/p/6506885.html

[http_www.infoq.com_cn_articles_anatomy-of-an-elasticsearch-cluster-part02]: http://www.infoq.com/cn/articles/anatomy-of-an-elasticsearch-cluster-part02
[Link 1]: https://en.wikipedia.org/wiki/Consensus_%28computer_science%29
[Raft]: https://raft.github.io/
[Paxos]: https://en.wikipedia.org/wiki/Paxos_%28computer_science%29
[Link 2]: https://www.elastic.co/blog/resiliency-elasticsearch
[Link 3]: https://en.wikipedia.org/wiki/Split-brain_%28computing%29
[05.jpeg]: http://cdn2.infoqstatic.com/statics_s2_20170228-0434_4/resource/articles/anatomy-of-an-elasticsearch-cluster-part02/zh/resources/05.jpeg
[Link 4]: https://en.wikipedia.org/wiki/Optimistic_concurrency_control
[Link 5]: https://www.elastic.co/guide/en/elasticsearch/guide/2.x/concurrency-solutions.html
[CAP]: https://en.wikipedia.org/wiki/CAP_theorem
[06.jpeg]: http://cdn2.infoqstatic.com/statics_s2_20170228-0434_4/resource/articles/anatomy-of-an-elasticsearch-cluster-part02/zh/resources/06.jpeg
[Link 6]: http://www.infoq.com/cn/articles/analysis-of-elasticsearch-cluster-part01
[07.jpeg]: http://cdn2.infoqstatic.com/statics_s2_20170228-0434_4/resource/articles/anatomy-of-an-elasticsearch-cluster-part02/zh/resources/07.jpeg