十三、es集群

一、集群、分布式的概念和作用

• 三个红框彼此构成集群
• 每个红框内部构成分布式
• 合起来就是集群分布式架构

二、es集群的特点

• es天然支持分布式
• es的设计隐藏了分布式本身的复杂性

三、es集群分布式架构的相关概念

• 集群（cluster）：一组拥有共同的 cluster name 的节点
• 节点（node）：集群中的一个es实例
• 索引（index）：es存放数据的地方，相当于关系数据库中database的概念
• 分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中。
• 主分片：es会将数据分为多个分片，然后分别存放在不同的es节点中
• 副本分片：每个主分片可以有多个副本，数据和主分片意义。在存放副本分片时，副本分片并没有跟着自己对应的主分片放在同一节点中，而是错开放置的，这样做的意义是即使某个es节点挂了，其他节点也能完整获取es的数据。

四、es集群管理

• 在创建索引时，如果不指定分片配置，则默认主分片1，副本分片1
• 在创建索引时，可以通过settings设置分片

# 创建索引，设置分片
PUT test_shard_index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "name":{
        "type": "text"
      }
    }
  }
}

• “number_of_replicas” : 1 ，表示每个主分片都有1个备份分片。
• 如果某个节点挂了，es会把这个节点剔除出去，并将里面的分片自平衡到其它节点中。
• es中每个查询在每个分片的单个线程中执行，但可以并行处理多个分片。
• 分片数量一旦确定，不能修改
• 索引分片推荐配置方案：
  • 1、每个分片推荐大小 10~30GB，分片太小的话会导致每个分片存的数据量不大，从而使分片数增多，在查询时会影响效率；也不能设置的太大，因为在分片中是单线程执行的，分片过大会导致这一个分片上占用的时间太多。
  • 2、分片的数量 = 节点的数量 * 1~3倍
  • 3、举例：有1000GB的数据，可以分为40个分片，20个节点。

五、集群原理——路由原理

• es的路由指：文档存入对应的分片，es计算分片编号的过程
• es如何知道一个文档应该存到哪个分片中？（通过路由算法）
• 查询时，根据文档id查询文档，es如何知道去哪个分片中查询数据？（路由算法）
• 路由算法：shard_index = hash(id) % number_of_primary_shards
• 为什么es不让更改分片的数量？因为es分片的数量一旦改了，那所有的文档数据都需要打乱了，重新的往不同的分片里存储，对es性能的损耗是比较大的。（可以重建索引来更改分片数量）

六、脑裂

• 一个正常的es集群中只有一个主节点（master），主节点负责管理整个集群，比如创建或删除索引、决定分片分配给相关的节点
• 脑裂问题的出现是因为从节点在选择主节点上出现分歧而导致一个集群出现多个主节点的现象，这会导致集群分裂，处于异常状态。
  

产生的可能原因：

1、网络原因：网络延迟

• 一般es集群会在内网部署，也可能在外网部署，比如阿里云
• 内网一般不会出现此问题，外网的网络出现问题的可能性大些

2、节点负载

• 主节点的配置：node.master: true（是否有资格成为主节点），node.data: true（是否存储数据），这样配置后主节点既为master又为data，当数据量访问比较大时，可能导致master节点停止响应（假死状态）。

3、JVM内存回收

• 当master节点设置的JVM内存较小时，在引发JVM大规模内存回收时，可能导致es进程失去响应。

避免脑裂的方法：

1. 网络原因：discovery.zen.ping.timeout 超时时间配置大一点。默认是3s，比如改为10s
2. 节点负载：角色分离。将候选主节点配置为：node.master: true，node.data: false；数据节点配置为：node.master: false，node.data: true
3. JVM内存回收：修改 config/jvm.options 文件中的 -Xms 和 -Xmx 为服务器内存的一半。