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" : ,
         "number_of_replicas" :
      }
   }

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 shard1、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状态。