Elasticsearch分布式一致性原理剖析之Meta篇

“Elasticsearch分布式一致性原理剖析”系列将会对Elasticsearch的分布式一致性原理进行详细的剖析，介绍其实现方式、原理以及其存在的问题等(基于6.2版本)。前一篇的内容包括了ES的集群组成、节点发现与Master选举、错误检测与集群扩缩容等。本篇将在前一篇的基础上，重点分析ES中meta更新的一致性问题，为了便于读者理解 ，本文还介绍了Master管理集群的方式、meta组成、存储方式等等。目录如下：

Master如何管理集群

Meta组成、存储和恢复

ClusterState的更新流程

如何解决当前的一致性问题

小结

Master如何管理集群

在上一篇文章中，我们介绍了ES集群的组成，如何发现节点，选举Master等。那么在选举出Master之后，Master如何管理集群呢？比如以下问题：

Master如何处理新建或删除Index？

Master如何对Shard进行重新调度，实现负载均衡？

既然要管理集群，那么Master节点必然需要以某种方式通知其他节点，从而让其他节点执行相应的动作，来完成某些事情。比如建立一个新的Index就需要将其Shard分配在某些节点上，在这些节点上需要创建出对应Shard的目录，并在内存中创建对应Shard的一些结构等。

在ES中，Master节点是通过发布ClusterState来通知其他节点的。Master会将新的ClusterState发布给其他的所有节点，当节点收到新的ClusterState后，会把新的ClusterState发给相关的各个模块，各个模块根据新的ClusterState判断是否要做什么事情，比如创建Shard等。即这是一种通过Meta数据来驱动各个模块工作的方式。

在Master进行Meta变更并通知所有节点的过程中，需要考虑Meta变更的一致性问题，假如这个过程中Master挂掉了，那么可能只有部分节点按照新的Meta执行了操作。当选举出新的Master后，需要保证所有节点都要按照最新的Meta执行操作，不能回退，因为已经有节点按照新的Meta执行操作了，再回退就会导致不一致。

ES中只要新Meta在一个节点上被commit，那么就会开始执行相应的操作。因此我们要保证一旦新Meta在某个节点上被commit，此后无论谁是master，都要基于这个commit来产生更新的meta，否则就可能产生不一致。本文会分析ES处理这一问题的策略和存在的问题。

Meta的组成、存储和恢复

在介绍Meta更新流程前，我们先介绍一下ES中Meta的组成、存储方式和恢复方式，不关心这部分内容的读者可以略过本节。

1. Meta：ClusterState、MetaData、IndexMetaData

Meta是用来描述数据的数据。在ES中，Index的mapping结构、配置、持久化状态等就属于meta数据，集群的一些配置信息也属于meta。这类meta数据非常重要，假如记录某个index的meta数据丢失了，那么集群就认为这个index不再存在了。ES中的meta数据只能由master进行更新，master相当于是集群的大脑。

ClusterState

集群中的每个节点都会在内存中维护一个当前的ClusterState，表示当前集群的各种状态。ClusterState中包含一个MetaData的结构，MetaData中存储的内容更符合meta的特征，而且需要持久化的信息都在MetaData中，此外的一些变量可以认为是一些临时状态，是集群运行中动态构建出来的。

ClusterState内容包括：

long version: 当前版本号，每次更新加1

String stateUUID：该state对应的唯一id

RoutingTable routingTable：所有index的路由表

DiscoveryNodes nodes：当前集群节点

MetaData metaData：集群的meta数据