通过前面章节的了解，我们已经知道 Elasticsearch 是一个实时的分布式搜索分析引擎，它能让你以一个之前从未有过的速度和规模，去探索你的数据。它被用作全文检索、结构化搜索、分析以及这三个功能的组合。 Elasticsearch 可以横向扩展至数百（甚至数千）的服务器节点，同时可以处理PB级数据。
虽然说 Elasticsearch 是分布式的，但是对于我们开发者来说并未过多的参与其中，我们只需启动对应数量的 ES 实例(即节点)，并给它们分配相同的 cluster.name 让它们归属于同一个集群，创建索引的时候只需指定索引 分片数 和 副本数 即可，其他的都交给了 ES 内部自己去实现。
这和数据库的分布式和 同源的 solr 实现分布式都是有区别的，数据库分布式(分库分表)需要我们指定路由规则和数据同步策略等，solr的分布式也需依赖 zookeeper，但是 Elasticsearch 完全屏蔽了这些。
所以我们说，Elasticsearch 天生就是分布式的，并且在设计时屏蔽了分布式的复杂性。Elasticsearch 在分布式方面几乎是透明的。我们可以使用笔记本上的单节点轻松地运行Elasticsearch 的程序，但如果你想要在 100 个节点的集群上运行程序，一切也依然顺畅。
Elasticsearch 尽可能地屏蔽了分布式系统的复杂性。这里列举了一些在后台自动执行的操作：
分配文档到不同的容器 或 分片 中，文档可以储存在一个或多个节点中。
按集群节点来均衡分配这些分片，从而对索引和搜索过程进行负载均衡。
复制每个分片以支持数据冗余，从而防止硬件故障导致的数据丢失。
将集群中任一节点的请求路由到存有相关数据的节点。
集群扩容时无缝整合新节点，重新分配分片以便从离群节点恢复。
虽然我们可以不了解 Elasticsearch 分布式内部实现机制也能将Elasticsearch使用的很好，但是了解它们将会从另一个角度帮助我们更完整的学习和理解 Elasticsearch 知识。接下里我们从以下几个部分来详细讲解 Elasticsearch 分布式的内部实现机制。
集群的原理对于我们之前的分布式经验，我们知道，提升分布式性能可以通过购买性能更强大（ 垂直扩容 ，或 纵向扩容 ） 或者数量更多的服务器（ 水平扩容 ，或 横向扩容 ）来实现。
虽然Elasticsearch 可以获益于更强大的硬件设备，例如将存储硬盘设为SSD，但是 垂直扩容 由于硬件设备的技术和价格限制，垂直扩容 是有极限的。真正的扩容能力是来自于 水平扩容 --为集群添加更多的节点，并且将负载压力和稳定性分散到这些节点中。
对于大多数的数据库而言，通常需要对应用程序进行非常大的改动，才能利用上横向扩容的新增资源。 与之相反的是，ElastiSearch天生就是 分布式的 ，它知道如何通过管理多节点来提高扩容性和可用性。 这也意味着你的应用无需关注这个问题。那么它是如何管理的呢？
主节点启动一个 ES 实例就是一个节点，节点加入集群是通过配置文件中设置相同的 cluste.name 而实现的。所以集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
与其他组件集群(mysql，redis)的 master-slave模式一样，ES集群中也会选举一个节点成为主节点，主节点它的职责是维护全局集群状态，在节点加入或离开集群的时候重新分配分片。具体关于主节点选举的内容可以阅读选举主节点。
所有主要的文档级别API（索引，删除，搜索）都不与主节点通信，主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。如果集群中就只有一个节点，那么它同时也就是主节点。
所以如果我们使用 kibana 来作为视图操作工具的话，我们只需在kibana.yml的配置文件中，将elasticsearch.url: "http://localhost:9200"设置为主节点就可以了，通过主节点 ES 会自动关联查询所有节点和分片以及副本的信息。所以 kibana 一般都和主节点在同一台服务器上。
作为用户，我们可以将请求发送到 集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。
发现机制ES 是如何实现只需要配置相同的cluste.name就将节点加入同一集群的呢？答案是发现机制（discovery module）。