ES总结七：集群管理
<p>[TOC]</p>
<h1>集群节点</h1>
<p>Elasticsearch集群中的节点一般有3种角色，在搭建完全分布式集群以前需要在配置文件中指定节点的角色，简介如下。
<strong>•master节点</strong>
master节点主要负责元数据的处理，比如索引的新增、删除、分片分配等，每当元数据有更新时，master节点负责同步到其他节点上。
<strong>•data节点</strong>
data节点上保存了数据分片。它负责数据相关操作，比如分片的增删改查以及搜索和整合操作。
<strong>•client节点</strong>
client节点起到路由请求的作用，实际上可以看作负载均衡器，适用于高并发访问的业务场景。</p>
<p>通过以下配置，可以产生四种不同类型的Node：</p>
<pre><code class="language-java">conf/elasticsearch.yml:
node.master: true/false
node.data: true/false</code></pre>
<p>四种不同类型的Node是一个node.master和node.data的true/false的两两组合。</p>
<p>当node.master为true时，其表示这个node是一个master的候选节点，可以参与选举，在ES的文档中常被称作master-eligible node，类似于MasterCandidate。ES正常运行时只能有一个master(即leader)，多于1个时会发生脑裂。</p>
<p>当node.data为true时，这个节点作为一个数据节点，会存储分配在该node上的shard的数据并负责这些shard的写入、查询等。</p>
<p>此外，<strong>任何</strong>一个集群内的node都可以执行<strong>任何</strong>请求，其会负责将请求转发给对应的node进行处理，所以当node.master和node.data都为false时，这个节点可以作为一个类似proxy的节点，即client节点，接受请求并进行转发、结果聚合等。</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/42b700f548e97a79afdc18c417ed7c4f?showdoc=.jpg" alt="" /></p>
<p>上图是一个ES集群的示意图，其中NodeA是当前集群的Master，NodeB和NodeC是Master的候选节点（master-eligible node），其中NodeA和NodeB同时也是数据节点(DataNode)，此外，NodeD是一个单纯的数据节点，Node_E是一个proxy节点。每个Node会跟其他所有Node建立连接。</p>
<hr />
<h1>集群的读写</h1>
<h2>索引的写</h2>
<p>索引的更新、索引、删除文档都是写操作，这些操作必须在primary shard完全成功后才能拷贝至其对应的replicas上，默认情况下主分片等待所有备份完成索引后才返回客户端。如下图：</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/9c39a78c1858c378dd8922fef052cc79?showdoc=.jpg" alt="" /></p>
<p>步骤如下：</p>
<pre><code>客户端向Node1（集群中的任何一个节点都可以）发送索引文档请求。
Node1 根据文档ID(_id字段)计算出该文档应该属于shard0，然后请求路由到Node3的P0分片上
Node3在P0上执行了请求。如果请求成功，则将请求并行的路由至Node1，Node2的R0上。当所有的Replicas报告成功后，Node3向请求的Node(Node1)发送成功报告，Node1再报告至Client。
当客户端收到执行成功后，操作已经在Primary shard和所有的replica shards上执行成功了</code></pre>
<h2>索引的读</h2>
<p>一个文档可以在primary shard和所有的replica shard上读取。如下图：</p>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/b5608ac440b3e79dcda9beafac3655f3?showdoc=.jpg" alt="" /></p>
<p>步骤如下：</p>
<pre><code>客户端发送Get请求到NODE1。
NODE1使用文档的_id决定文档属于shard 0.shard 0的所有拷贝存在于所有3个节点上。这次，它将请求路由至NODE2。
NODE2将文档返回给NODE1，NODE1将文档返回给客户端。 对于读请求，请求节点(NODE1)将在每次请求到来时都选择一个不同的replica。shard来达到负载均衡。使用轮询策略轮询所有的replica shards。</code></pre>
<h2>索引的更新</h2>
<p><img src="https://www.showdoc.cc/server/api/common/visitfile/sign/038f4c025ffeceb1eb918a7346728c37?showdoc=.jpg" alt="" /></p>
<p>步骤如下：</p>
<pre><code>客户端发送更新操作请求至NODE1
NODE1将请求路由至NODE3，Primary shard所在的位置
NODE3从P0读取文档，改变source字段的JSON内容，然后试图重新对修改后的数据在P0做索引。如果此时这个文档已经被其他的进程修改了，那么它将重新执行3步骤，这个过程如果超过了retryon_conflict设置的次数，就放弃。
如果NODE3成功更新了文档，它将并行的将新版本的文档同步到NODE1和NODE2的replica shards重新建立索引。一旦所有的replica shards报告成功，NODE3向被请求的节点(NODE1)返回成功，然后NODE1向客户端返回成功。</code></pre>
<h1>节点发现</h1>
<p>ZenDiscovery是ES自己实现的一套用于节点发现和选主等功能的模块，没有依赖Zookeeper等工具。</p>
<p>简单来说，节点发现依赖以下配置：</p>
<pre><code class="language-java">conf/elasticsearch.yml:
discovery.zen.ping.unicast.hosts: [1.1.1.1, 1.1.1.2, 1.1.1.3]</code></pre>
<p>这个配置可以看作是，在本节点到每个hosts中的节点建立一条边，当整个集群所有的node形成一个联通图时，所有节点都可以知道集群中有哪些节点，不会形成孤岛。</p>
<p>官方推荐这里设置为所有的master-eligible node，即所有的节点都可以参与master选举：</p>
<pre><code class="language-java">It is recommended that the unicast hosts list be maintained as the list of master-eligible nodes in the cluster.</code></pre>
<h1>Master选举</h1>
<p>上面提到，集群中可能会有多个master-eligible node，此时就要进行master选举，保证只有一个当选master。如果有多个node当选为master，则集群会出现脑裂，脑裂会破坏数据的一致性，导致集群行为不可控，产生各种非预期的影响。</p>
<p>为了避免产生脑裂，ES采用了常见的分布式系统思路，保证选举出的master被多数派(quorum)的master-eligible node认可，以此来保证只有一个master。这个quorum通过以下配置进行配置：</p>
<pre><code class="language-java">conf/elasticsearch.yml:
discovery.zen.minimum_master_nodes: 2</code></pre>
<h2>master选举谁发起，什么时候发起？</h2>
<p>master选举当然是由master-eligible节点发起，当一个master-eligible节点发现满足以下条件时就会发起选举：</p>
<pre><code>该master-eligible节点的当前状态不是master。
该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点，没有任何节点连接到master。
包括本节点在内，当前已有超过minimum_master_nodes个节点没有连接到master
总结一句话，即当一个节点发现包括自己在内的多数派的master-eligible节点认为集群没有master时，就可以发起master选举。</code></pre>
<h2>当需要选举master时，选举谁？</h2>
<p>首先是选举谁的问题，如下面源码所示，选举的是排序后的第一个MasterCandidate(即master-eligible node)。</p>
<pre><code class="language-java">public MasterCandidate electMaster(Collection<MasterCandidate> candidates) {
assert hasEnoughCandidates(candidates);
List<MasterCandidate> sortedCandidates = new ArrayList<>(candidates);
sortedCandidates.sort(MasterCandidate::compare);
return sortedCandidates.get(0);
}</code></pre>
<p>那么是按照什么排序的？</p>
<pre><code class="language-java">public static int compare(MasterCandidate c1, MasterCandidate c2) {
// we explicitly swap c1 and c2 here. the code expects "better" is lower in a sorted
// list, so if c2 has a higher cluster state version, it needs to come first.
int ret = Long.compare(c2.clusterStateVersion, c1.clusterStateVersion);
if (ret == 0) {
ret = compareNodes(c1.getNode(), c2.getNode());
}
return ret;
}</code></pre>
<p>如上面源码所示，先根据节点的clusterStateVersion比较，clusterStateVersion越大，优先级越高。clusterStateVersion相同时，进入compareNodes，其内部按照节点的Id比较(Id为节点第一次启动时随机生成)。</p>
<p>总结一下就是：</p>
<pre><code>当clusterStateVersion越大，优先级越高。这是为了保证新Master拥有最新的clusterState(即集群的meta)，避免已经commit的meta变更丢失。因为Master当选后，就会以这个版本的clusterState为基础进行更新。(一个例外是集群全部重启，所有节点都没有meta，需要先选出一个master，然后master再通过持久化的数据进行meta恢复，再进行meta同步)。
当clusterStateVersion相同时，节点的Id越小，优先级越高。即总是倾向于选择Id小的Node，这个Id是节点第一次启动时生成的一个随机字符串。之所以这么设计，应该是为了让选举结果尽可能稳定，不要出现都想当master而选不出来的情况。</code></pre>
<h2>什么时候选举成功</h2>
<p>当一个master-eligible node(我们假设为Node_A)发起一次选举时，它会按照<strong>上述排序策略选出一个它认为的master</strong>。</p>
<p>假设Node_A选Node_B当Master：</p>
<p>Node_A会向Node_B发送join请求，那么此时：</p>
<pre><code>如果Node_B已经成为Master，Node_B就会把Node_A加入到集群中，然后发布最新的cluster_state, 最新的cluster_state就会包含Node_A的信息。相当于一次正常情况的新节点加入。对于Node_A，等新的cluster_state发布到Node_A的时候，Node_A也就完成join了
如果Node_B在竞选Master，那么Node_B会把这次join当作一张选票。对于这种情况，Node_A会等待一段时间，看Node_B是否能成为真正的Master，直到超时或者有别的Master选成功。
如果Node_B认为自己不是Master(现在不是，将来也选不上)，那么Node_B会拒绝这次join。对于这种情况，Node_A会开启下一轮选举。</code></pre>
<p>假设Node_A选自己当Master：</p>
<pre><code>此时NodeA会等别的node来join，即等待别的node的选票，当收集到超过半数的选票时，认为自己成为master，然后变更cluster_state中的master node为自己，并向集群发布这一消息。</code></pre>
<p>按照上述流程，我们描述一个简单的场景来帮助大家理解：</p>
<p>假如集群中有3个master-eligible node，分别为Node_A、 Node_B、 Node_C, 选举优先级也分别为Node_A、Node_B、Node_C。三个node都认为当前没有master，于是都各自发起选举，选举结果都为Node_A(因为选举时按照优先级排序，如上文所述)。于是Node_A开始等join(选票)，Node_B、Node_C都向Node_A发送join，当Node_A接收到一次join时，加上它自己的一票，就获得了两票了(超过半数)，于是Node_A成为Master。此时cluster_state(集群状态)中包含两个节点，当Node_A再收到另一个节点的join时，cluster_state包含全部三个节点。</p>
<h2>选举怎么保证不脑裂？</h2>
<p>基本原则还是多数派的策略，如果必须得到多数派的认可才能成为Master，那么显然不可能有两个Master都得到多数派的认可。</p>
<p>上述流程中，master候选人需要等待多数派节点进行join后才能真正成为master，就是为了保证这个master得到了多数派的认可。但是我这里想说的是，上述流程在绝大部份场景下没问题，听上去也非常合理，但是却是有bug的。</p>
<p>因为上述流程并没有限制在选举过程中，一个Node只能投一票，那么什么场景下会投两票呢？比如NodeB投NodeA一票，但是NodeA迟迟不成为Master，NodeB等不及了发起了下一轮选主，这时候发现集群里多了个Node0，Node0优先级比NodeA还高，那NodeB肯定就改投Node0了。假设Node0和NodeA都处在等选票的环节，那显然这时候NodeB其实发挥了两票的作用，而且投给了不同的人。</p>
<p>那么这种问题应该怎么解决呢，比如raft算法中就引入了选举周期(term)的概念，保证了每个选举周期中每个成员只能投一票，如果需要再投就会进入下一个选举周期，term+1。假如最后出现两个节点都认为自己是master，那么肯定有一个term要大于另一个的term，而且因为两个term都收集到了多数派的选票，所以多数节点的term是较大的那个，保证了term小的master不可能commit任何状态变更(commit需要多数派节点先持久化日志成功，由于有term检测，不可能达到多数派持久化条件)。这就保证了集群的状态变更总是一致的。</p>
<h1>健康检查</h1>
<h2>MasterFaultDetection与NodesFaultDetection</h2>
<p>这里的错误检测可以理解为类似心跳的机制，有<strong>两类错误检测</strong>，一类是Master定期检测集群内其他的Node，另一类是集群内其他的Node定期检测当前集群的Master。检查的方法就是定期执行ping请求。</p>
<p>如果Master检测到某个Node连不上了，会执行removeNode的操作，将节点从cluste_state中移除，并发布新的cluster_state。当各个模块apply新的cluster_state时，就会执行一些恢复操作，比如选择新的primaryShard或者replica，执行数据复制等。</p>
<p>如果某个Node发现Master连不上了，会清空pending在内存中还未commit的new cluster_state，然后发起rejoin，重新加入集群(如果达到选举条件则触发新master选举)。</p>
<h1>集群扩缩容</h1>
<h2>扩容DataNode</h2>
<p>假设一个ES集群存储或者计算资源不够了，我们需要进行扩容，这里我们只针对DataNode，即配置为：</p>
<pre><code class="language-java">conf/elasticsearch.yml:
node.master: false
node.data: true</code></pre>
<p>然后需要配置集群名、节点名等其他配置，为了让该节点能够加入集群，我们把discovery.zen.ping.unicast.hosts配置为集群中的master-eligible node。</p>
<pre><code class="language-java">conf/elasticsearch.yml:
cluster.name: es-cluster
node.name: node_Z
discovery.zen.ping.unicast.hosts: ["x.x.x.x", "x.x.x.y", "x.x.x.z"]</code></pre>
<p>然后启动节点，节点会自动加入到集群中，集群会自动进行rebalance，或者通过reroute api进行手动操作。</p>
<h2>缩容DataNode</h2>
<p>假设一个ES集群使用的机器数太多了，需要缩容，我们怎么安全的操作来保证数据安全，并且不影响可用性呢？</p>
<p>首先，我们选择需要缩容的节点，注意本节只针对DataNode的缩容，MasterNode缩容涉及到更复杂的问题，下面再讲。</p>
<p>然后，我们需要把这个Node上的Shards迁移到其他节点上，方法是先设置allocation规则，禁止分配Shard到要缩容的机器上，然后让集群进行rebalance。</p>
<pre><code class="language-java">PUT _cluster/settings
{
"transient" : {
"cluster.routing.allocation.exclude._ip" : "10.0.0.1"
}
}</code></pre>
<p>等这个节点上的数据全部迁移完成后，节点可以安全下线。</p>
<h2>扩容MasterNode</h2>
<p>假如我们想扩容一个MasterNode(master-eligible node)， 那么有个需要考虑的问题是，上面提到为了避免脑裂，ES是采用多数派的策略，需要配置一个quorum数：</p>
<pre><code class="language-java">conf/elasticsearch.yml:
discovery.zen.minimum_master_nodes: 2</code></pre>
<p>假设之前3个master-eligible node，我们可以配置quorum为2，如果扩容到4个master-eligible node，那么quorum就要提高到3。</p>
<pre><code class="language-java">curl -XPUT localhost:9200/_cluster/settings -d '{
"persistent" : {
"discovery.zen.minimum_master_nodes" : 3
}
}'</code></pre>
<p>这个API发送给当前集群的master，然后新的值立即生效，然后master会把这个配置持久化到cluster meta中，之后所有节点都会以这个配置为准。</p>
<p>但是这种方式有个问题在于，配置文件中配置的值和cluster meta中的值很可能出现不一致，不一致很容易导致一些奇怪的问题，比如说集群重启后，在恢复cluster meta前就需要进行master选举，此时只可能拿配置中的值，拿不到cluster meta中的值，但是cluster meta恢复后，又需要以cluster meta中的值为准，这中间肯定存在一些正确性相关的边界case。</p>
<p>总之，动master节点以及相关的配置一定要谨慎，master配置错误很有可能导致脑裂甚至数据写坏、数据丢失等场景。</p>
<h2>缩容MasterNode</h2>
<p>缩容MasterNode与扩容跟扩容是相反的流程，我们需要先把节点缩下来，再把quorum数调下来，不再详细描述。</p>
<h1>与Zookeeper、raft等实现方式的比较</h1>
<h2>与使用Zookeeper相比</h2>
<pre><code>节点发现：每个节点的配置文件中配置一下Zookeeper服务器的地址，节点启动后到Zookeeper中某个目录中注册一个临时的znode。当前集群的master监听这个目录的子节点增减的事件，当发现有新节点时，将新节点加入集群。
master选举：当一个master-eligible node启动时，都尝试到固定位置注册一个名为master的临时znode，如果注册成功，即成为master，如果注册失败则监听这个znode的变化。当master出现故障时，由于是临时znode，会自动删除，这时集群中其他的master-eligible node就会尝试再次注册。使用Zookeeper后其实是把选master变成了抢master。
健康检查：由于节点的znode和master的znode都是临时znode，如果节点故障，会与Zookeeper断开session，znode自动删除。集群的master只需要监听znode变更事件即可，如果master故障，其他的候选master则会监听到master znode被删除的事件，尝试成为新的master。
集群扩缩容：扩缩容将不再需要考虑minimum_master_nodes配置的问题，会变得更容易。</code></pre>
<p>使用Zookeeper的优劣点
使用Zookeeper的好处是，把一些复杂的分布式一致性问题交给Zookeeper来做，ES本身的逻辑就可以简化很多，正确性也有保证，这也是大部分分布式系统实践过的路子。而ES的这套ZenDiscovery机制经历过很多次bug fix，到目前仍有一些边角的场景存在bug，而且运维也不简单。</p>
<p>那为什么ES不使用Zookeeper呢，大概是官方开发觉得增加Zookeeper依赖后会多依赖一个组件，使集群部署变得更复杂，用户在运维时需要多运维一个Zookeeper。</p>
<p>那么在自主实现这条路上，还有什么别的算法选择吗？当然有的，比如raft。</p>
<h2>与使用raft相比</h2>
<p>raft算法是近几年很火的一个分布式一致性算法，其实现相比paxos简单，在各种分布式系统中也得到了应用。这里不再描述其算法的细节，我们单从master选举算法角度，比较一下raft与ES目前选举算法的异同点：</p>
<p>相同点
多数派原则：必须得到超过半数的选票才能成为master。
选出的leader一定拥有最新已提交数据：在raft中，数据更新的节点不会给数据旧的节点投选票，而当选需要多数派的选票，则当选人一定有最新已提交数据。在es中，version大的节点排序优先级高，同样用于保证这一点。
不同点
正确性论证：raft是一个被论证过正确性的算法，而ES的算法是一个没有经过论证的算法，只能在实践中发现问题，做bug fix，这是我认为最大的不同。
是否有选举周期term：raft引入了选举周期的概念，每轮选举term加1，保证了在同一个term下每个参与人只能投1票。ES在选举时没有term的概念，不能保证每轮每个节点只投一票。
选举的倾向性：raft中只要一个节点拥有最新的已提交的数据，则有机会选举成为master。在ES中，version相同时会按照NodeId排序，总是NodeId小的人优先级高。
看法
raft从正确性上看肯定是更好的选择，而ES的选举算法经过几次bug fix也越来越像raft。当然，在ES最早开发时还没有raft，而未来ES如果继续沿着这个方向走很可能最终就变成一个raft实现。</p>