Anatomy of an Elasticsearch Cluster part.2——深度解析ElasticSearch（2）

在本文中，我们会探讨ES是如何处理三个C问题的(共识consensus, 并发性concurrency and 一致性consistency)。

Consensus（共识） - Split-brain problem and importance of quorum

Consensus——Split-brain问题以及群体的重要性

Consensus是所有分布式系统面临的挑战，他需要系统中的所有的进程/节点都默认(agree on)一个给定的数值或状态。现有的很多共识算法（如Raft,Paxos等）都在数理上被证明可行。然而，ES有自己的一套共识系统（zen discovery），对此ES的开发者Shay Banon解释如下：

The Zen Discovery有以下两个模块：

·Ping：节点用来发现其他节点的进程。

·Unicast：一个包含了许多hostnames列表的模块，用来控制节点的ping行为。

ES是一个P2P的系统，所有的节点都与系统中的其他节点通信。 有一个活动的主要节点用于更新和控制集群内的状态和操作。一个新的ES集群在Ping过程中，需要从所有符合成为主节点条件的节点中选出主节点，然后其他节点进入主节点的控制范围（other nodes join the master）。 默认的ping_interval是1sec，ping_timeout是3sec。当节点加入后，他们给主节点发送一个join request，默认join_timeout为20sec。如果主节点没有回应，该节点就再选择另一个主节点重新ping。当一个节点意外发现主节点没有回应时，ping进程同样可以帮助该节点通过其他节点寻找其他主节点。

【NOTE】client nodes 和 data nodes 默认对于选择节点的进程没有影响。当然这可以通过在elasticsearch.yml把discovery.zen.master_election.filter_client 以及discovery.zen.master_election.filter_data设置为false来改变。

如果检测到错误，主节点就会ping所有其他节点来查看它们是否alive，其他节点ping回主节点以确认。

如果使用默认设置，ES会遇到split-brain问题：为了防止network partition，在当其他节点认为主节点无反应（dead）后，它把自己变为主节点。这样就会造成一个集群中有许多个主节点，这可能造成数据负担，同时有可能造成数据的合并错误。

以上情况可以通过对符合主节点条件的节点进行以下设置来避免：

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

这种设置需要所有活跃的符合主节点条件的节点共同进入一个新的选出的主节点的控制范围，该主节点专门用来处理election process，原来网络中的主节点需要符合该主节点的控制。对于确保集群稳定以及在集群大小变化时能进行动态更新，以上设置非常重要的。

图a和图b展示了discovery.zen.minimum_master_nodes设置前后在防止network partition方面产生的变化。

【NOTE】对于production cluster来说，一般推荐设置3个候选主节点，每次只设置其中1个主节点为active。这些主节点不接受任何客户请求，专用于控制。

Concurrency（并发性）

ES是分布式系统，支持并发请求。create/update/delete请求不仅被发送到primary shard，也被并行地发送到replica shards。然而，这些请求有可能乱序到达，在这些情况下， ES使用优化并发控制来确保新version的文档不被旧version的版本覆盖。

每个文档索引都拥有一个版本号，每次被修改后版本号就会相应增加。这些版本号是用来确保所有的修改请求都是按顺序执行的。为了保证应用的更新请求不会造成数据负担，ES的API允许你自己指定当前修改后对应的版本号，如果请求中的版本号低于当前分片中文档的版本号，就意味着该文档已经被其他进程更新过，当前请求就失败了。application level中可以控制如何处理失败的请求，当然也有其他的locking option可以选择，你可以在此处阅读--> here

向ES发送了并发请求之后，接下来就应该考虑——我们如何保证这些请求的一致性？（有一些讨论本章暂时不会讨论到）

Consistency（一致性） - Ensuring consistent writes and reads

· 对于Write来说，ES支持 consistency levels ，可以预检查到底那些分片允许进行write操作。  The available options are quorum, one and all. 默认会设置为quorum，这意味着只有当大多数的分片都可用时，write操作才会被允许执行。然而，即使当大部分的分片都可用，依旧可能发生写入replica shard失败的情况，此时replica会被认为是错误的，分片会在另一个node上被重建。（the replica is said to be faulty and the shard would be rebuilt on a different node. ）

·对于Read操作，新加入的文档直到被刷新后（after the refresh interval）才能被搜索。 为了保证搜索请求能返回最新的文档版本，分片会被默认设置为sync同步，这样在操作在both primary和replica shards上都执行完成后会返回write request，这样就能保证不论search request从任何分片被返回，都能返回最新的文档版本 。 但是，即使application为了得到高索引率，设置replication=async，还是可以设置_preference参数为primary，这样所有的search requests都只会被发送到primary shards，这样就保证了返回的文档是最新版本。