elasticsearch elastic 源码解决之 - 为什么需要仅投票节点

通过源码和官网文档学习, 我发现es有个仅投票节点. 有些文档说仅投票节点是为了解决关键一票的问题, 但是我依然有些疑问

我见过很多其他集群,他们没有仅投票节点,然后算法也类似,为什么他们能良好的工作?
我指的是他们不需要仅投票节点角色就能解决关键一票的问题.
那么es设置仅投票节点角色的意义在哪里? 相对于其他实现来说它增加了复杂性.
那么它背后有一些其他好处吗?

经过多方求证, 其实这个可以通过节省资源方面进行解释, 这里的节省资源是什么意思呢?

首先你要了解的是如果是master节点,一般不会让它处理繁重的数据相关的业务操作, 它主要负责集群状态等管理工作, 这样这个节点必然会造成浪费. 但是呢候选节点又是集群高可用和分区容忍性的关键. 所以仅投票节点的优势就在这里,它参与投票却不参与管理. 所以它投票的同时依然可以提供数据服务. 这就是它存在的意义

主节点必须遵循以下分配原则：

• 避免重负载任务

主节点负责轻量级集群范围的操作，例如创建或删除索引、跟踪哪些节点是集群的一部分以及决定将哪些分片分配给哪些节点。拥有一个稳定的主节点对于集群健康很重要。当选的主节点拥有履行其职责所需的资源，这对于集群的健康非常重要。如果所选的主节点承载了其他任务，比如数据的增删改查等资源密集型人物，会对集群的稳定运行造成较大影响。避免主节点负载过重的最可靠方法是把所有配置了master角色的节点配置为专用主节点（或者称之为专用候选节点），使它们能够专注于管理集群。

• 负载均衡器

专用master节点仍将充当协调节点，也就是集群中的负载均衡器，将请求从客户端路由到集群中的其他节点，但是不要以负载均衡器的目的而设置候选节点。另外负载均衡节点
任何不是 voting-only的 master-eligible节点都可以被选举为 active master。
主节点必须有一个 path.data目录，其内容在重启后仍然存在，就像数据节点一样，因为这是存储集群元数据的地方。集群元数据描述了如何读取存储在数据节点上的数据，因此如果丢失，则无法读取存储在数据节点上的数据。
高可用性 (HA) 集群需要至少三个候选节点，其中至少两个不是仅投票节点。这样即使其中一个节点发生故障，也可以保证剩下的节点能够选举出一个主节点。