发现机制 负责发现集群中的节点，以及选择主节点。每次集群状态发生更改时，集群中的其他节点都会知道状态（具体方式取决于使用的是哪一种发现机制）。
ES目前主要推荐的自动发现机制，有如下几种：
Azure classic discovery 插件方式，多播
EC2 discovery 插件方式，多播
Google Compute Engine (GCE) discovery 插件方式多播
Zen discovery 默认实现，多播/单播
这里额外介绍下单播，多播，广播的定义和区别，方便我们更好的理解发现机制。
单播，多播，广播的区别：
单播(unicast)：网络节点之间的通信就好像是人们之间的对话一样。如果一个人对另外一个人说话，那么用网络技术的术语来描述就是“单播”，此时信息的接收和传递只在两个节点之间进行。例如，你在收发电子邮件、浏览网页时，必须与邮件服务器、Web服务器建立连接，此时使用的就是单播数据传输方式。
多播(multicast)：“多播”也可以称为“组播”，多播”可以理解为一个人向多个人（但不是在场的所有人）说话，这样能够提高通话的效率。因为如果采用单播方式，逐个节点传输，有多少个目标节点，就会有多少次传送过程，这种方式显然效率极低，是不可取的。如果你要通知特定的某些人同一件事情，但是又不想让其他人知道，使用电话一个一个地通知就非常麻烦。多播方式，既可以实现一次传送所有目标节点的数据，也可以达到只对特定对象传送数据的目的。多播在网络技术的应用并不是很多，网上视频会议、网上视频点播特别适合采用多播方式。
广播(broadcast)：可以理解为一个人通过广播喇叭对在场的全体说话，这样做的好处是通话效率高，信息一下子就可以传递到全体，广播是不区分目标、全部发送的方式，一次可以传送完数据，但是不区分特定数据接收对象。
上面列举的发现机制中， Zen Discovery 是 ES 默认内建发现机制。它提供单播和多播的发现方式，并且可以扩展为通过插件支持云环境和其他形式的发现。所以我们接下来重点介绍下 Zen Discovery是如何在Elasticsearch中使用的。
集群是由相同cluster.name的节点组成的。当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。
单播主机列表通过discovery.zen.ping.unicast.hosts来配置。这个配置在 elasticsearch.yml 文件中：
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]具体的值是一个主机数组或逗号分隔的字符串。每个值应采用host：port或host的形式（其中port默认为设置transport.profiles.default.port，如果未设置则返回transport.tcp.port）。请注意，必须将IPv6主机置于括号内。此设置的默认值为127.0.0.1，[:: 1]。
Elasticsearch 官方推荐我们使用 单播 代替 组播。而且 Elasticsearch 默认被配置为使用 单播 发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
虽然 组播 仍然作为插件提供， 但它应该永远不被使用在生产环境了，否则你得到的结果就是一个节点意外的加入到了你的生产环境，仅仅是因为他们收到了一个错误的 组播 信号。对于 组播 本身并没有错，组播会导致一些愚蠢的问题，并且导致集群变的脆弱（比如，一个网络工程师正在捣鼓网络，而没有告诉你，你会发现所有的节点突然发现不了对方了）。
使用单播，你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 master 节点，并加入集群。
这意味着你的单播列表不需要包含你的集群中的所有节点，它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。如果你使用 master 候选节点作为单播列表，你只要列出三个就可以了。
关于 Elasticsearch 节点发现的详细信息，请参阅 Zen Discovery。
应对故障对于分布式系统的熟悉，我们应该知道分布式系统设计的目的是为了提高可用性和容错性。在单点系统中的问题在 ES 中同样也会存在。
单节点的问题如果我们启动了一个单独的节点，里面不包含任何的数据和索引，那我们的集群就是一个包含空内容节点的集群，简称空集群。