Elasticsearch由浅入深（二）ES基础分布式架构、横向扩容、容错机制

Elasticsearch的基础分布式架构

Elasticsearch是一套分布式系统，分布式是为了应对大数据量。

Elasticsearch隐藏了复杂的分布式机制：

扩容方案：

　　6台服务器，每台容纳1T的数据，马上数据量要增长到8T，这个时候有两个方案。

（1）垂直扩容：重新购置两台服务器，每台服务器的容量就是2T，替换掉老的两台服务器，那么现在6台服务器的总容量就是 4 * 1T + 2 * 2T = 8T。

（2）水平扩容：新购置两台服务器，每台服务器的容量就是1T，直接加入到集群中去，那么现在服务器的总容量就是8 * 1T = 8T

垂直扩容：采购更强大的服务器，成本非常高昂，而且会有瓶颈，假设世界上最强大的服务器容量就是10T，但是当你的总数量达到5000T的时候，你要采购多少台最强大的服务器啊。

水平扩容：业界经常采用的方案，采购越来越多的普通服务器，性能比较一般，但是很多普通服务器组织在一起，就能构成强大的计算和存储能力。

比如现在有4个node,其中3个node中有一个shard,1个node中有2个shard,但是这个时候如果有一个新的node加入进来，则es会自动把其中一个shard分配到刚加入的node上去。

一个es集群中总会有一个node是master节点：

一个索引(index)包含多个shard
每个shard都是一个最小工作单元，承载部分数据，lucene实例，完整的建立索引和处理请求的能力。
增减节点时，shard会自动在nodes中负载均衡。
primary shard和replica shard,每个document肯定只存在于某一个primary shard以及其对应的replica shrad中，不可能存在于多个primary shard。
replica shard是primary shard的副本，负责容错，以及承担读请求负载。
primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改。
primary shard的默认数量是5，replica shrad默认数量是1。
primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机时，primary shard和replica shard都丢失了，起不到容错的作用。），但是可以和其它primary shard的replica shard放在同一个节点上。

单node环境下，创建一个index: 有3个primary shard、3个replica shard

PUT /test_index
{
   "settings" : {
      "number_of_shards" : 3,
      "number_of_replicas" : 1
   }
}

此时的情况，1个node、3个primary shard、3个replica shard

如果此时新增一个node进来，构成了一个由2个node组成的es集群，如下:

并且：

primary shard 和 replica shard自动负载均衡
目前情况：2个node， 3个primary shard，3个replica shard

如果此时给es集群增加一个节点(node),es会自动对primary shard和replica shard进行负载均衡
每个Node有更少的shard, IO/CPU/Memory资源给每个shard分配更多，每个shard性能更好
扩容的极限，6个shard(3个primary shard,3个replica shard),最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好
超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量
3台机器下，9个shard（3 primary，6 replica），资源更少，但是容错性更好，最多容纳2台机器宕机，6个shard只能容纳0台机器宕机
这里的这些知识点，你综合起来看，就是说，一方面告诉你扩容的原理，怎么扩容，怎么提升系统整体吞吐量；另一方面要考虑到系统的容错性，怎么保证提高容错性，让尽可能多的服务器宕机，保证数据不丢失

master选举、replica容错、数据恢复
目前es集群情况：3个node，9个shard(3个primary shard,6个replica shard)

如果此时master node宕机：

因为Node1节点宕机了，所以primary shard0、replica shard1、replica shard2三个3shard就丢失了。master node宕机的一瞬间，primary shard0这个shard就没有了，此时就不是active status,所以集群的状态为red.
容错第一步：master选举，自动选举另外一个node成为新的master，承担起master的责任来：
容错第二步：新master将丢失的primary shard的某个replica shard提升为primary shard，此时cluster status会变为Yellow，因为所有的primary shard都变成了active status，但是，少了一个replica shard，所以不是所有的replica shard都是active。
容错第三步：重启故障的node, new master节点将会把缺失的副本都copy一份到该node上去，而且该node会使用之前已有的shard数据，只是同步一下宕机之后发生的改变。

此时es cluster的状态为green，因为所有的primary shard和replica shard都是active状态。