Elasticsearch---分布式原理

NoLongerConfused

已于 2022-02-11 19:04:38 修改

阅读量371

点赞数

分类专栏： Elasticsearch系列文章文章标签： elasticsearch java

于 2021-10-08 13:45:19 首次发布

本文链接：https://blog.csdn.net/qq_51702676/article/details/120650178

版权

Elasticsearch系列文章专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1、单机服务有哪些问题

性能有限
可用性差
难以扩展

2、分布式的好处

高可用性：集群可容忍部分节点宕机而保持服务的可用性和数据的完整性
易扩展：当集群的性能不满足业务要求时，可以方便快速的扩容集群，而无需停止服务。
高性能：集群通过负载均衡器分摊并发请求压力，可以大大提高集群的吞吐能力和并发能力。

3、集群环境选择

选择本地多节点部署，

自动发现

集群中节点之间通过 9300端口通信，并发现彼此的存在。ES不需要修改任何配置，节点之间即可发现彼此的存在从而形成集群。

开发模式和生产模式

开发模式：开发模式是默认配置（未配置集群发现设置），如果用户只是出于学习目的，而引导检查会把很多用户挡在门外，所以ES提供了一个设置项discovery.type=single-node。此项配置为指定节点为单节点发现以绕过引导检查。
生产模式：当用户修改了有关集群的相关配置会触发生产模式，在生产模式下，服务启动会触发ES的引导检查或者叫启动检查（bootstrap checks）（或者叫启动检查），所谓引导检查就是在服务启动之前对一些重要的配置项进行检查，检查其配置值是否是合理的。引导检查包括对JVM大小、内存锁、虚拟内存、最大线程数、集群发现相关配置等相关的检查，如果某一项或者几项的配置不合理，ES会拒绝启动服务，并且在开发模式下的某些警告信息会升级成错误信息输出。引导检查十分严格，之所以宁可拒绝服务也要阻止用户启动服务是为了防止用户在对ES的基本使用不了解的前提下启动服务而导致的后期性能问题无法解决或者解决起来很麻烦。因为一旦服务以某种不合理的配置启动，时间久了之后可能会产生较大的性能问题，但此时集群已经变得难以维护，ES为了避免这种情况而做出了引导检查的设置。这种设定虽然增加了用户的使用门槛，但是避免了日后产生更大的问题

单节点模式

单节点启动，节点会选举自己成为active master节点，会绕过引导检查。

discovery.type: single-node

核心配置

cluster.name：集群名称，节点根据集群名称确定是否是同一个集群。
node.name：节点名称，集群内唯一。
node.roles：节点的角色配置，不同的角色以字符串数字方式配置
network.host：节点对外提供服务的地址以及集群内通信的ip地址，如果配置为本地地址，那么当前节点仅会在本地发现其他节点。另外修改此配置会触发生产模式并执行引导检查。但是生产环境一般是每个服务器一个节点，每个节点都要和其他服务器形成发现，所以此项配置一般配置文为本机的内网ip。
http.port: 对外提供服务的端口号，默认9200-9299
transport.port：节点之间的通讯端口，默认9300-9399
discovery.seed_hosts: 集群初始化的种子节点，可配置部分或全部节点，大型集群可通过嗅探器发现剩余节点，考试环境配置全部节点即可
cluster.initial_master_nodes：节点初始active master节点, 必须是有master角色的节点，即必须是候选节点，但并不是必须配置所有候选节点。生产模式下启动新集群时，必须明确列出应在第一次选举中计算其选票的候选节点。第一次成功形成集群后，cluster.initial_master_nodes从每个节点的配置中删除设置。重新启动集群或向现有集群添加新节点时，请勿使用此设置。
path.data：节点的数据文件的存放位置
path.logs：节点的日志文件存放位置

注意：本地部署多个节点时，多个节点的path.data和path.log必须配置为不同路径，并且最好不要保存在默认目录里，因为如果在默认目录，一旦执行服务升级操作，数据会被覆盖。

可执行以下命令启动一个9节点集群

./elasticsearch -Ecluster.name=cluster -Enode.name=node1 -Enode.roles=master -Epath.data=../node1/data -Epath.logs=../node1/logs -Ehttp.port=9201 -Etransport.port=9301 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309 -Ecluster.initial_master_nodes=node1,node2,node3
./elasticsearch -Ecluster.name=cluster -Enode.name=node2 -Enode.roles=master -Epath.data=../node2/data -Epath.logs=../node2/logs -Ehttp.port=9202 -Etransport.port=9302 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309 -Ecluster.initial_master_nodes=node1,node2,node3
./elasticsearch -Ecluster.name=cluster -Enode.name=node3 -Enode.roles=master -Epath.data=../node3/data -Epath.logs=../node3/logs -Ehttp.port=9203 -Etransport.port=9303 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309 -Ecluster.initial_master_nodes=node1,node2,node3
./elasticsearch -Ecluster.name=cluster -Enode.name=node4 -Enode.roles=data -Epath.data=../node4/data -Epath.logs=../node4/logs -Ehttp.port=9204 -Etransport.port=9304 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309
./elasticsearch -Ecluster.name=cluster -Enode.name=node5 -Enode.roles=data -Epath.data=../node5/data -Epath.logs=../node5/logs -Ehttp.port=9205 -Etransport.port=9305 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309
./elasticsearch -Ecluster.name=cluster -Enode.name=node6 -Enode.roles=data -Epath.data=../node6/data -Epath.logs=../node6/logs -Ehttp.port=9206 -Etransport.port=9306 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309
./elasticsearch -Ecluster.name=cluster -Enode.name=node7 -Enode.roles=data -Epath.data=../node7/data -Epath.logs=../node7/logs -Ehttp.port=9207 -Etransport.port=9307 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309
./elasticsearch -Ecluster.name=cluster -Enode.name=node8 -Enode.roles=data -Epath.data=../node8/data -Epath.logs=../node8/logs -Ehttp.port=9208 -Etransport.port=9308 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309
./elasticsearch -Ecluster.name=cluster -Enode.name=node9 -Enode.roles=data -Epath.data=../node9/data -Epath.logs=../node9/logs -Ehttp.port=9209 -Etransport.port=9309 -d -Ediscovery.seed_hosts=localhost:9301,localhost:9302,localhost:9303,localhost:9304,localhost:9305,localhost:9306,localhost:9307,localhost:9308,localhost:9309

引导检查—Bootstrap Checks

在启用生产模式时，节点启动之前ES会自动对节点的相关配置逐项检查，目的是避免开发者在对其配置项不了解的前提下做出不合理的配置。如果配置不符合性能或者兼容性要求，ES会阻止服务启动以保证服务的性能和可用性。

检查项：

堆大小检查
文件描述符检查
内存锁检查
最大线程数检查
最大文件大小检查
虚拟内存检查
文件系统映射数检查
客户端JVM检查
串行收集器检查
系统调用过滤器检查
OnError和OnOOMError检查
早期访问检查
所有权限检查
发现配置检查

4、主从模式（Leader/Follower）

Elasticsearch使用的主从架构模式，其实除此之外，还可以使用分布式哈希表（DHT），其区别在于：

主从模式适合节点数量不多，并且节点的状态改变（加入集群或者离开集群）不频繁的情况。
分布式哈希表支持每小时数千个节点的加入或离开，响应约为4-10跳。

ES的应用场景一般来说单个集群中一般不会有太多节点（一般来说不超过一千个），节点的数量远远小于单个节点（只的是主节点）所能维护的连接数。并且通常主节点不必经常处理节点的加入和离开，处于相对稳定的对等网络中，因此使用主从模式。

5、ES常见模块：Mudules

Cluster

Cluster模块是Master节点执行集群管理的封装实现，管理集群状态，维护集群级（除了集群级，还有索引级分片级等级别）的配置信息。其主要功能包括：

管理集群状态，将新生成的集群状态发布到集群的所有节点
调用allocation模块执行分片分配感知，决策分片分配行为
在集群各个节点直接迁移分片，保证数据平衡，shard rebalance

Allocation

此模块是实现了对节点分片的分配感知策略，新节点加入离开、动态扩容都需要分片分配感知，此模块由主节点调用，常见的使用场景如：跨机架强制感知实现高可用，冷热集群架构设计等。

Bootstrap

引导检查模块，不再赘述

Ingest

预处理模块负责数据索引之前的一些预操作，比如数据类型处理、数据的结构转换等，很多场景下课替代logstash处理管道消息，Elastic认证考试考点之一。

Monitor

监控功能提供了一种方式来了解 Elasticsearch 集群的运行状况和性能

Discovery

发现模块负责管理如发现集群中新加入的节点，或者节点退出之后将状态信息移除，其作用类似于ZooKeeper。发现木块是用于elasticsearch和的内置发现模块默认值。它提供单播发现，但可以扩展到支持云环境和其他形式的发现

Gateway

负责说对收到Master广播下来的集群状态数据的持久化存储，并在集群完全重启时恢复他们

Indices

索引模块管理全局级索引配置，不包括索引级及索引以下级。集群启动阶段需要主副本分片恢复就是在这个模块完成的

HTTP

HTTP模块允许通过JSON over HTTP的方式访问ES的API，HTTP模块本质上是完全异步的，这一位置没有阻塞线程等待响应。使用异步通信进行HTTP的好处是解决了C10k的问题。

Transport

传输模块用于集群内部节点通信。传输模块使用TCP协议，每个节点都与其他节点维持若干个TCP长连接，通信本质也是完全异步的。

6、节点

候选节点/投票节点（master-eligible，有时候也叫master节点）

默认情况下，master-eligible节点是那些在集群状态发布期间参与选举并执行某些任务的节点，配置了master角色的节点都是有效的投票节点，可以参与选举也可以投票

硬件要求：

CPU：高

内存：高

网络：高

存储：高

仅投票节点

配置了master和voting_only角色的节点将成为仅投票节点，仅投票节点虽然也是候选节点，但是在选举过程中仅可以投票而不参与竞选。不过仅投票节点可以同时也是数据节点，这样的话，其不具备被选举为Master的资格，但是参与投票，可以在选举过程中发挥关键票的作用。

硬件要求：

CPU：高

内存：低

网络：高

存储：高

主节点（active master）

避免重负载：主节点负责轻量级集群范围的操作，例如创建或删除索引、跟踪哪些节点是集群的一部分以及决定将哪些分片分配给哪些节点。拥有一个稳定的主节点对于集群健康很重要。当选的主节点拥有履行其职责所需的资源，这对于集群的健康非常重要。如果所选的主节点承载了其他任务，那么集群将不能很好地运行。避免 master 被其他任务超载的最可靠方法是将所有符合 master 的节点配置为仅具有 master 角色的专用 master 节点，使它们能够专注于管理集群。专用master节点仍将充当协调节点，将请求从客户端路由到集群中的其他节点，但是不要以负载均衡器的目的而设置候选节点。
一般来说，如果小型或轻负载集群的主节点具有其他角色和职责，则其可能运行良好，但是一旦您的集群包含多个节点，使用专用的主节点通常是有意义的。
任何不是voting-only的master-eligible节点都可以被选举为active master。
主节点必须有一个path.data目录，其内容在重启后仍然存在，就像数据节点一样，因为这是存储集群元数据的地方。集群元数据描述了如何读取存储在数据节点上的数据，因此如果丢失，则无法读取存储在数据节点上的数据。
高可用性 (HA) 集群需要至少三个候选节点，其中至少两个不是仅投票节点。这样即使其中一个节点发生故障，也可以保证剩下的节点能够选举出一个主节点。

硬件要求：

CPU：高

内存：高

网络：高

存储：高但是无需大

数据节点

数据节点保存包含已编入索引的文档的分片。数据节点处理数据相关操作，如 CRUD、搜索和聚合。这些操作是 I/O 密集型、内存密集型和 CPU 密集型的。监控这些资源并在它们过载时添加更多数据节点非常重要。

硬件要求：

CPU：高

内存：高

网络：高

存储：速度快、容量大

协调节点

如果主动关闭了master、data和ingest的角色配置，当前节点就剩下一个只能路由请求、处理搜索减少阶段和分发批量索引功能的仅协调节点。本质上，仅协调节点的就相当于一个智能负载均衡器。换句话说，你是没有办法配置一个不具备协调转发能力的节点的。
仅协调节点过多会增加集群负担，因为主节更新集群状态必须等待每个节点的确认，而仅协调节点从这个角度上讲纯粹是一种负担。数据节点可以愉快地完成转发任务。

7、分片：Shard

Shard即数据分片，是ES的数据载体。在ES中数据分为primary shard（主分片）和replica shard（副本分片），每一个primary承载单个索引的一部分数据，分布于各个节点，replica为某个primary的副本，即备份。分片分配的原则是尽量均匀的分配在集群中的各个节点，以最大程度降低部分shard在出现意外时对整个集群乃至服务造成的影响。

每个分片就是一个Lucene的实例，具有完整的功能。

索引分片分配：Index Shard Allocation
- 分片均衡：
- 分片过滤：
分片分配感知：Shard Allocation Awareness

8、高可用系统架构设计 ★★★

高可用性即：High Availability（HA），高可用性是分布式系统架构设计的重要因素之一，简单来说，可用性越高的集群在发生意外情况（如断电、节点宕机）的时候，服务发生故障而不可用的可能性越低，也就是降低了意外情况而对整体服务产生的影响的可能性。

高可用性原理

ES使用数据分片（shard）来提高服务的可用性，将数据分散保存在不同的节点上以降低当单个节点发生故障时对数据完整性的影响，同时使用副本（repiica）来保证数据的完整性。关于分片的默认分配策略，在7.x之前，默认5个primary shard，每个primary shard默认分配一个replica，即5主1副，而7.x之后，默认1主1副
ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总是能均匀地分布。
Paimary只能在索引创建时配置数量，而replica可以在任何时间分配，并且primary支持读和写操作，而replica只支持客户端的读取操作，数据由es自动管理，从primary同步。
ES不允许Primary和它的Replica放在同一个节点中，并且同一个节点不接受完全相同的两个Replica
同一个节点允许多个索引的分片同时存在。

ES的容错机制

容错性可以理解系统容忍的局部发生异常情况的比率和当异常发生时自行恢复的能力。在ES中表现为对节点宕机的处理机制。

步骤：

Master选举：选出集群中的Leader。
Replica容错：新的Active Master会将丢失的Primary的某个Replica提升为Primary。
重启故障机：Master尝试重启故障节点。
数据同步：Master将宕机期间丢失的数据同步到重启节点对应的分片上去，从而使服务恢复正常。

高可用性集群：

高可用性的中心思想就是采取一切可能的策略，降低集群中任意一部分节点出现问题后导致服务整体不可用的概率。其包含数据的完整性，集群的存活概率以及选主等。

小规模集群

单节点集群：

一般用于学习或者开发、测试环境，不推荐在生产环境中使用单节点集群。由于集群只有单个节点，为了适应这一点，ES默认会给集群分配所有角色。单节点角色不具备高可用性，并且无法分配副本分片。为了使集群保持健康，单节点模式下创建索引，需要使用index.number_of_replicas设置副本数量为0。
两节点集群：
- 如果处于硬件成本考虑，集群中只允许有两个节点，那么一般来说最好把两个节点都设置成数据节点。还应该通过在每个不是可搜索快照索引的索引上设置index.number_of_replicas为来确保每个分片都冗余存储在两个节点 1上。这是默认行为，但可能会被索引模板覆盖。Auto-expand replicas也可以达到同样的效果，但是在这么小的集群中没有必要使用这个功能。
- 推荐在两个节点之一设置node.master: false明确告知其不具备候选节点资格。目的是为了确定哪个节点是主节点。集群可以容忍另一个不具备候选资格的节点的丢失。如果不做此设置，这时两个节点都会具有候选资格，但是其中一个节点如果宕机，由于选主需要票数过半（票数>N/2+1），也就是票数必须是两票才能选出active master，所以会导致无法选主。此时集群无法容忍任何一个节点宕机
- 默认情况下，ES会为每个节点分配所有角色，如果手动分配角色，一般建议为每个节点分配所有角色，如果其中一个节点宕机，另一个节点可以取而代之。
- 两个节点的集群，只允许其中一个固定的节点宕机，而不是任意一个节点。因为如果允许两个节点可以独立选举，那么如果集群由于网络或者其他原因导致节点连接断开，那么两个节点没办法确定另一个节点是否是宕机了，也就是会产生所谓的”脑裂“问题，而产生多主的情况。Elasticsearch 避免了这种情况并通过不选择任何一个节点作为主节点来保护您的数据，直到该节点可以确保它具有最新的集群状态并且集群中没有其他主节点。这可能导致集群在连接恢复之前没有主节点。
三节点集群：
- 三节点部署：如果整个集群中所有节点一共只有三个，建议把三个节点全部部署为数据节点和候选节点。虽然active master节点一般只负责轻量级任务不做数据节点。但是通常来说三节点集群一般不会承载很大的业务量，也就不必考虑那么多了。这也是处于成本考虑不得已而为之。三节点集群的容错能力是1，即允许一台节点故障。
- 二加一部署：即两个候选节点，一个仅投票节点，若干数据节点。这种配置的最大好处就是在保证高可用的前提下性价比更高，适用于小规模集群。由于在避免脑裂的前提下，要选举出主节点的最小节点数量是3，也就是选主的必要条件是票数过半也就是2票。而候选节点一般是不负责其他的任务的，也就不会为其分配data角色，那么集群通常会出现三个节点不存放数据的局面。此时会产生造成资源浪费。因为active master只存在一个，另外两个master作为候选节点，在及群众仅仅是充当了负载均衡器。为了避免这种资源浪费，通常的做法是把其中一个候选节点设置为仅投票节点，即node.roles: [ data, master, voting_only ]，此时，当前节点在选举过程中，仅有选举权而没有被选举权，这样就可以同时给他分配数据节点的角色，因为其不会被选举为active master。三节点集群中，三个节点必须都具有master角色，并且仅投票节点最多只能有一个。仅投票节点由叫仲裁节点起着决胜票的作用。
多节点集群
- 一旦集群增长到三个以上的节点，可以开始根据它们的职责对这些节点做职责专一化。主要根据需要配置尽可能多的数据节点、预处理节点、机器学习节点等来均衡工作负载。随着集群变大，一般建议给每个角色使用专用节点，以便为每个任务独立扩展资源。
  
  但是，最好将集群中候选节点数量限制为三个。主节点不像其他节点类型那样扩展，因为集群总是只选择其中之一作为集群的主节点。如果有太多候选节点，那么主选举可能需要更长的时间才能完成。在较大的集群中，一般建议把候选节点设置为专用候选节点，即不分配其他角色，并避免向这些专用节点发送任何客户端请求。以免候选节点被不必要的额外工作所拖累导致集群服务不稳定。
  
  但是可以把候选节点之一配置为仅投票节点以便它永远不会被选为主节点。例如，集群可能有两个专用的候选节点和一个既是数据节点又是仅投票的候选节点的第三个节点。这第三个仅投票节点将在Master选举中投出决胜票，但是自己永远不会被选举为active master。

大规模集群

单集群
- 避免跨数据中心：ES对网络和宽带要求较高，并且一般来说要尽量避免服务跨多个数据中心。因为一旦遇到分区恢复问题，它必须重新同步任何丢失的数据并重新平衡集群。如果一定要跨多个数据中心，建议在每个数据中心部署独立集群，然后配置跨集群搜索或跨集群复制。
- 部署分片分配感知：为了降低当集群出现单个或区域节点（比如一个机架）宕机对整个服务造成的影响，一般策略是通过分配感知来实现。
双区集群：
- 如果集群部署在两个区域比如两个机房内，应该在每个区域中拥有不同数量的候选节点，这样在其中一个区域出现问题的时候，会增加另一个区域的存活概率。比如两个机房部署同一个集群，那么两个机房的候选节点避免相等，因为此时如果一个机房意外断电，两个机房的服务都会停止。配置单数投票节点可避免此问题。此时其中一个机房断电，服务可用的概率为50%。
- 双区集群理论上能容忍一个区域的数据丢失，但不是任意一个区域，打个比方：服务部署在两个机房，机房A和机房B，要么是仅允许A机房出现故障而不允许B机房出现故障，也就是A机房断电服务可用，但是B机房断电服务中断；要么是仅允许B机房出现故障而不允许A机房出现故障，也就是B机房断电服务可用，但是A机房断电服务中断。从高可用的角度想，我们更希望任意一个机房断电，另一个机房的服务都不受影响，但是这是不可能的。因为没有断电的机房不知道出现故障的机房是断网了还是断电了，也就不知道应该是发起独立选举还是等待下去。如果两个机房都可以独立选主，那么就无法避免脑裂，可能会产生两个机房选出active master。解决办法是在两个区域中都配置一个仅投票节点并在独立的第三个区域添加一个额外的候选节点。这样两个区域其中之一断电，额外的投票节点就可以投出关键票。这个额外的节点也叫专用tiebreaker节点，此节点可以用低配服务器。
多区集群
- 如果集群中有三个区域，那么每个区域中应该有一个候选节点。如果集群包含三个以上的区域，那么应该选择其中的三个区域，并在这三个区域中的每一个区域中放置一个候选节点。这意味着即使其中一个区域发生故障，集群仍然可以选举主节点。
多集群
- Elasticsearch是主从结构，主节点能管理的节点上线一般不超过一千个，如果继续增加节点，可能会导致active master不稳定，如果集群想突破集群规模带来的性能瓶颈，一般可配置多集群，利用跨集群搜索单个超大集群拆分成多个小集群（相对小，千节点级别）来完成对集群的性能扩展。

总结

集群应该至少有两个区域包含数据节点。
除了主分片之外，每个不是可搜索快照索引的索引都应该有每个主分片的至少一个副本。
分片分配感知配置为避免将分片的所有副本集中在单个区域内。
集群至少有三个候选节点。这些节点中至少有两个不是仅投票节点，均衡分配在至少三个区域中。
客户端被配置为将其请求发送到多个区域中的节点，或者被配置为使用负载平衡器来平衡一组适当的节点之间的请求。所述弹性云服务提供了这样的负载平衡器。

9、Master选举 ★★★★

设计思路：所有分布式系统都需要解决数据的一致性问题，处理这类问题一般采取两种策略：

避免数据不一致情况的发生
定义数据不一致后的处理策略

ES的选举算法：ES基于Bully和Paxos两种算法实现，而非就是两种算法或之一。 ES 7.x 基于以上算法，加入了基于Raft的优化。

Bully：Bully是Leader选举的基本算法之一，基本原理就是按照节点ID进行排序，任何时候当前Leader的节点ID都是集群中最高节点ID。该算法非常易于实现但是当Leader处于不稳定状态的时候，如因负载过重而假死，此时可能会触发选主，选出第二大ID的节点为新的Leader。ES通过推迟选举直到Master失效（Master放弃Active Master资格触发选举）来解决问题，但是会产生双主或多主（也就是脑裂）问题。
Paxos：Paxos非常强大，在选举方面的灵活性比Bully算法有很大的优势，但是其原理非常复杂。
Raft：Raft是一种使用较为广泛的分布式一致性的协议，在Raft中，节点可能的状态有三种：
- Leader：
- Candidate：
- Follower：

有效选票：所有节点都会参与选举并参与投票，但是只有候选节点的投票才是有效投票。

法定票数：即当选Master所需的最小票数，可通过：discovery.zen.minimum_master_nodes配置

节点失效监测：FaultDetection类

There are two fault detection processes running. The first is by the
master, to ping all the other nodes in the cluster and verify that they
are alive. And on the other end, each node pings to master to verify if
its still alive or an election process needs to be initiated