elasticsearch之life inside a cluster

选择性的翻译一些个人感觉比较重要的东西。

es集群中的机器是如何发现别的机器的呢？通过cluster.name这个配置项。这让我联想到“脑裂”现象。是的，在网络分化的时候，es集群也会发生脑裂现象。当然es有关于recovery的一些配置来防止这种现象的发生。

master节点只是管理一些集群级别的变化，比如增加/删除索引，增加/删除节点等。对于文档级别的操作（查询/更新）根本不涉及，所以不必过分担心单个master节点会成为系统的瓶颈。再者，任何节点都可以成为master。这也是一种健壮性的表现。

集群中的每一个节点的都知晓某一个文档位于哪里，因此任何节点都可以直接将对应请求直接定位到承载对应数据的目的地。我们客户端直接交互的任何一个集群中的节点都会负责结果的收集汇总，然后将最终结果返回给客户端。

集群的三种健康状态：

green：所有主分片和副本都分配了，都是可用的

yellow：所有主分片都分配了，存在副本未分配的情况

red：存在主分片未分派的情况，集群不可用

index是一个逻辑上的命名空间，实际存储数据的是shard。shard是一个完整的lucene查询引擎。我们的应用并不直接跟shard交互，而是跟index交互。

shard分布在集群中的各个node上。当集群增删机器的时候，为了数据的平衡在集群机器之间移动的也是shard。

shard有两种角色：主分片和副本。一条记录一定只属于一个主分片，所以主分片的数据客观上决定了索引的大小，而且这个数目一旦设定就无法改变。副本数据是可以随时增加或者减少的。副本是主分片的一个拷贝，二者承载的数据是一样的（注意：这并不意味着二者结构完全一致），副本的存在是对主分片的一种备份，同时可以承接查询等各种请求，跟主分片无差异。

假设刚开始我们启动了一个节点，创建了一个索引，带有3个主分片，1个副本（总共6个shard）。在健壮性方面，这肯定是不好的，因为万一这个节点挂掉，我们数据就丢失了。所以我们陆续启动多个节点。根据我们shard的数目，最多可以分布在6个node上，再加多余的node也没有意义了。但是，我们可以动态增加副本的数目，来扩展node数目。副本个数增加，就会增加系统的吞吐。这里需要注意：如果在我们固有的node上增加了多余的副本并不一定能提升系统的性能，因为同一个node上的shard是要共享node上的资源的，shard数目多了，每一个shard分到的资源就是有限的，而node上的总体资源又不会改变。但是更多的副本意味着更多的冗余，即使我们挂掉多台机器的情况下，es集群也有可能是可以正常工作的。

如果集群中的node挂掉，而且这个node上还承载着某些主分片，在丢失主分片的时候我们的系统无法正常工作，显然集群现在的健康状态是red。幸运的是，对于丢失的主分片我们在其他nodes上有完整的副本，这时候master节点会迅速提升副本的地位，直接变成主分片，这个过程非常迅速，就像打开一个开关一样，然后再根据设定的副本数目从新的主分片来copy副本出来。如果master挂掉呢？就会先从剩余的node上选举一个node出来行使master的权利，作为新的master节点。