AZ概念
AZ(可用区，Availability Zone)这个是AWS发明的概念，AWS引入可用区设计主要是为了提升用户应用程序的高可用性。因为可用区与可用区之间在设计上是相互独立的，也就是说它们会有独立的供电、独立的网络等，这样假如一个可用区出现问题时也不会影响另外的可用区。在一个区域内，可用区与可用区之间是通过高速网络连接，从而保证有很低的延时。
ES脑裂问题
说完可用区，再来看看ES(Elastic Search)主动选举机制：
elasticsearch集群一旦建立起来以后，会选举出一个master，其他都为slave节点。但是具体操作的时候，每个节点都提供写和读的操作。就是说，你不论往哪个节点中做写操作，这个数据也会分配到集群上的所有节点中。
这里有某个节点挂掉的情况，如果是slave节点挂掉了，那么首先关心，数据会不会丢呢?不会。如果你开启了replicate，那么这个数据一定在别的机器上是有备份的。别的节点上的备份分片会自动升格为这份分片数据的主分片。这里要注意的是这里会有一小段时间的yellow状态时间。
如果是主节点挂掉怎么办呢?当从节点们发现和主节点连接不上了，那么他们会自己决定再选举出一个节点为主节点。但是这里有个脑裂的问题，假设有5台机器，3台在一个机房，2台在另一个机房，当两个机房之间的联系断了之后，每个机房的节点会自己聚会，推举出一个主节点。这个时候就有两个主节点存在了，当机房之间的联系恢复了之后，这个时候就会出现数据冲突了。
解决的办法就是设置参数：
- discovery.zen.minimum_master_nodes
为3(超过一半的节点数)，那么当两个机房的连接断了之后，就会以大于等于3的机房的master为主，另外一个机房的节点就停止服务了。
AZ可用 + 脑裂放一块怎么办?
其实很难办，为了做到不脑裂，就要设置最小可用节点要超过整个集群的一半。但是同样，但是这样做同样，AZ通信断了或者挂了一个AZ，整个服务可能节点数就不到集群的一半，服务就无法使用了，好像AZ的可靠性就没有起到作用。
AWS是怎么弄的?
看AWS的开发文档里面有如下说明：
每个 AWS 区域都是一个独立的地理区域，其中包含多个相互隔离的位置，这些位置称为可用区。为避免数据损失，并***限度地减少节点和数据中心故障时导致的停机时间，您可以使用 Amazon ES 控制台，在同一区域的两个可用区之间，分配属于 Elasticsearch 群集的节点和副本索引分片。此分配称为区域感知。如果启用区域感知，则您还必须使用本机 Elasticsearch API 为您的群集创建副本分片。Amazon ES 在可用区的各节点之间分配副本，这会增加您的群集的可用性。为群集启用区域感知会略微增加网络延迟。
Important
区域感知要求实例数量为偶数。所有索引的默认配置均为副本数量等于 1。如果您为一个索引指定。副本数量等于 0，则区域感知不复制分片到第二个可用区。如果没有副本分片，则无需将副本分发。到第二个可用区，启用该功能不提供数据损失保护。
下图显示了启用区域感知的四节点群集。该服务将所有主索引分片放在一个可用区中，将所有副本分片放在第二个可用区中。
不难看出来，AWS并没有解决这个问题，而是做了一个取舍，要求两个AZ节点数都为偶数，更多的是为了AZ之间更好的数据均衡。
【本文为51CTO专栏作者“大数据和云计算”的原创稿件，转载请通过微信公众号获取联系和授权】
