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

Elasticsearch的基础分布式架构

Elasticsearch对复杂分布式机制的透明隐藏特性

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

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

• 分片：咱们以前随随便便就将一些document插入到es集群中去了，咱们没有关心过数据是如何进行分配的、数据到哪一个shard中去了。
• 集群发现机制(cluster discovery):若是启动一个新的es进程，那么这个es进程会做为一个node而且发现es集群，而后自动加入进去。
• shard负载均衡：举例，假设如今有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均分分配，以保证每一个节点的均衡的读写负载请求
• shard副本
• 请求路由
• 集群扩容
• shard重分配

Elasticsearch的垂直扩容与水平扩容

扩容方案：

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

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

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

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

水平扩容：业界常常采用的方案，采购愈来愈多的普通服务器，性能比较通常，可是不少普通服务器组织在一块儿，就能构成强大的计算和存储能力。

增减或减小节点时的数据rebalance

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

master节点

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

• 管理es集群的元数据：好比说索引的建立和删除、维护索引元数据；节点的增长和移除、维护集群的数据
• 默认状况下，会自动选择出一台节点做为master节点
• master节点不承载全部的请求，因此不会是单点瓶颈

节点平等的分布式架构

1. 节点对等，每一个节点都能接收全部的请求
2. 自动请求路由：任何一个节点接收到请求后，均可以把这个请求自动路由到相关节点上去处理该请求。
3. 响应收集：最原始节点会从其余节点接收响应数据，而后把这些数据返回给客户端。

primary shard 和 replica shard机制再次梳理

1. 一个索引(index)包含多个shard
   

    

2. 每一个shard都是一个最小工做单元，承载部分数据，lucene实例，完整的创建索引和处理请求的能力。
   

    

3. 增减节点时，shard会自动在nodes中负载均衡。

    

4. primary shard和replica shard,每一个document确定只存在于某一个primary shard以及其对应的replica shrad中，不可能存在于多个primary shard。
5. replica shard是primary shard的副本，负责容错，以及承担读请求负载。
6. primary shard的数量在建立索引的时候就固定了，replica shard的数量能够随时修改。
7. primary shard的默认数量是5，replica shrad默认数量是1。
8. primary shard不能和本身的replica shard放在同一个节点上（不然节点宕机时，primary shard和replica shard都丢失了，起不到容错的做用。），可是能够和其它primary shard的replica shard放在同一个节点上。

单node环境下建立index是什么样子的？

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

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

2. 集群状态是yellow
3. 这个时候，只会将3个primary shard分配到仅有的一个node上去，另外3个replica shard是没法分配的
4. 集群能够正常工做，可是一旦出现节点宕机，数据所有丢失，并且集群不可用，没法承担任何请求
   

两个node环境下replica shard是如何分配的？ 

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

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

而且：

1. primary shard会自动把数据同步到对应的replica shard上去
2. 客户端的读请求能够发送到primary shard上去，也能够发送到replica shard上去

Elasticsearch横向扩容

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

Elasticsearch容错机制

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

   若是此时master node宕机：
   

   由于Node1节点宕机了，因此primary shard0、replica shard一、replica shard2三个3shard就丢失了。master node宕机的一瞬间，primary shard0这个shard就没有了，此时就不是active status,因此集群的状态为red.

2. 容错第一步：master选举，自动选举另一个node成为新的master，承担起master的责任来：
   

3. 容错第二步：新master将丢失的primary shard的某个replica shard提高为primary shard，此时cluster status会变为Yellow，由于全部的primary shard都变成了active status，可是，少了一个replica shard，因此不是全部的replica shard都是active。
   

4. 容错第三步：重启故障的node, new master节点将会把缺失的副本都copy一份到该node上去，并且该node会使用以前已有的shard数据，只是同步一下宕机以后发生的改变。
   

   此时es cluster的状态为green，由于全部的primary shard和replica shard都是active状态。