该模块主要负责集群中节点的自动发现和Master节点的选举。节点之间使用p2p的方式进行直接通信，不存在单点故障的问题。Elasticsearch中，Master节点维护集群的全局状态，比如节点加入和离开时进行shard的重新分配。 自动发现机制在目前版本（1.3.1）提供了四种选择，一种是默认实现，其他都是通过插件实现。

• 1. Azure discovery 插件方式，多播
• 2. EC2 discovery 插件方式，多播
• 3. Google Compute Engine (GCE)discovery 插件方式多播
• 4. zen discovery默认实现 多播/单播

多播也叫组播，指一个节点可以向多台机器发送请求。生产环境中ES不建议使用这种方式，对于一个大规模的集群，组播会产生大量不必要的通信。

单播，当一个节点加入一个现有集群，或者组建一个新的集群时，请求发送到一台机器。当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系Master节点，并加入集群。

弹性伸缩 Elastic

Elasticsearch 的弹性体现在两个方面：

1. 服务发现机制让节点很容易加入和退出。

2. 丰富的设置以及allocation API。

1. 网络问题

2. 节点负载

3. 内存回收

directory类对外最简单的实现基于文件的随机读写,对于简单的应用来说，这种实现方式足够了。它主要的瓶颈是在文件的多线程存取时性能很差。在ElasticSearch中，通常建议使用基于新IO的系统存储来替代简单的文件系统存储。只是如果用户希望使用简单的文件系统存储，可以设置index.store.type属性值为simplefs。

新IO文件系统存储

这种存储类型使用的directory类是基于java.nio包中的FileChannel类实现的，该类映射到Apache Lucene的NIOFSDirectory类这种实现方式使得多个线程同时读写文件时不会出现性能下降的问题。通过设置index.store.type属性值为niofs使用该存储类型。

它使用mmap系统调用来通过读取和随机方式完成写文件操作。在进程中，它将文件映射到相同尺寸的虚拟内存地址空间中。由于没有任何的锁操作，多线程存取索引文件时就程序就具有可伸缩性了(可伸缩性是指当增加计算资源时，程序的吞吐量或者处理能力相应的增加)。当我们使用mmap读取索引文件，在操作系统看来，该文件已经被缓存(文件会被映射到虚拟内存中)。基于这个原因，从Lucene索引中读取一个文件时，文件不必加载到操作系统的缓存中，读取速度就会快一些。这基本上就是允许Lucene，也就是ElasticSearch直接操作I/O缓存，索引文件的存取当然会快很多。

这种存储类型是几种类型中唯一不基于Apache Lucene directory实现的(当然也可以用Lucene的RAMDirectory类来实现)。内存存储类型允许用户直接把索引数据存储到内存中，所以硬盘上不会存储索引数据。记住这一点至关重要，因为这意味着数据并没有持久化：只要整个集群重启，数据就会丢失。然而，如果你的应用需要一个微型的、存取快速的，能有多个片分和分片副本的而且重建过程很快的索引，内存存储类型可能是你需要的。把index.store.type属性值设置为memeory即可使用该存储类型。

存储在内存中的索引数据，与其它存储类型相似，也会在允许存数据的节点上保留分片副本。

默认情况下，ElasticSearch会使用基于文件系统的存储。尽管不同的存储类型用于不同的操作系统，被选定的存储类型依然基于文件系统。

图

1. cluster-level 恢复机制的配置

2. index-level 恢复机制的配置

1. 分片

2. 副本