ES分布式文档系统

ES如何实现高可用（生产环境均为一台机器一个节点）

1. ES在分配单个索引的分片时会将每个分片尽可能分配到更多的节点上。但是，实际情况取决于集群拥有的分片和索引的数量以及它们的大小，不一定总是能均匀地分布。
2. ES不允许Primary和它的Replica放在同一个节点中，并且同一个节点不接受完全相同的两个Replica
3. 同一个节点允许多个索引的分片同时存在。

容错机制

• 啥叫容错？
  ①傻X的代码你能看懂，牛X的代码你也能看懂
  ②只能看懂自己的代码，容错性低
  ③PS：各种情况（支持的情况越多，容错性越好）下，都能保证work 正常运行
  ④换到咱们ES上就是，就是在局部出错异常的情况下，保证服务正常运行并且有自行恢复能力。

• ES-node

• 节点分类：

• • 1)Master：主节点，每个集群都有且只有一个
    a.尽量避免Master节点 node.data ＝ true
• • 2)voting：投票节点
    a.Node.voting_only = true（仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点）。
• • 3)coordinating：协调节点
    每一个节点都隐式的是一个协调节点，如果同时设置了data.master = false和data.data=false，那么此节点将成为仅协调节点。
• • 4)Master-eligible node（候选节点）
• • 5)Data node（数据节点）
• • 6)Ingest node：（预处理节点）
• • 7）Machine learning node（机器学习节点）

• 两个配置：

• • 1)node.master = true node.data = true
    这是ES节点默认配置，既作为候选节点又作为数据节点，这样的节点一旦被选举为Master，压力是比较大的，通常来说Master节点应该只承担较为轻量级的任务，比如创建删除索引，分片均衡等。
• • 2)node.master = true node.data = false
    只作为候选节点，不作为数据节点，可参选Master节点，当选后成为真正的Master节点。
• • 3)node.master = false node.data = false
    既不当候选节点，也不作为数据节点，那就是仅协调节点，负责负载均衡
• • 4)node.master=false node.data=true
    不作为候选节点，但是作为数据节点，这样的节点主要负责数据存储和查询服务。

• (3)图解容错机制
  ①第一步：Master选举（假如宕机节点是Master）
  1)脑裂：可能会产生多个Master节点
  ②第二步：Replica容错，新的（或者原有）Master节点会将丢失的Primary对应的某个副本提升为Primary
  ③第三步：Master节点会尝试重启故障机
  ④第四步：数据同步，Master会将宕机期间丢失的数据同步到重启机器对应的分片上去

• 选举过程
  

• 脑裂过程

• • 脑裂”问题可能的成因
    1.网络问题：集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片
    2.节点负载：主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
    3.内存回收：data节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。
• • 脑裂问题解决方案：
    1.减少误判：discovery.zen.ping_timeout节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。
    2.选举触发 discovery.zen.minimum_master_nodes:1
    该参数是用于控制选举行为发生的最小集群主节点数量。
    当备选主节点的个数大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为（n/2）+1，n为主节点个数（即有资格成为主节点的节点个数）
    增大该参数，当该值为2时，我们可以设置master的数量为3，这样，挂掉一台，其他两台都认为主节点挂掉了，才进行主节点选举。
    3.角色分离：即master节点与data节点分离，限制角色
    主节点配置为：
    node.master: true node.data: false
    从节点配置为：
    node.master: false node.data: true

如何提高ES分布式系统的可用性以及性能最大化

• （1）每台节点的Shard数量越少，每个shard分配的CPU、内存和IO资源越多，单个Shard的性能越好，当一台机器一个Shard时，单个Shard性能最好。
• （2）稳定的Master节点对于群集健康非常重要！理论上讲，应该尽可能的减轻Master节点的压力，分片数量越多，Master节点维护管理shard的任务越重，并且节点可能就要承担更多的数据转发任务，可增加“仅协调”节点来缓解Master节点和Data节点的压力，但是在集群中添加过多的仅协调节点会增加整个集群的负担，因为选择的主节点必须等待每个节点的集群状态更新确认。
• （3）反过来说，如果相同资源分配相同的前提下，shard数量越少，单个shard的体积越大，查询性能越低，速度越慢，这个取舍应根据实际集群状况和结合应用场景等因素综合考虑。
• （4）数据节点和Master节点一定要分开，集群规模越大，这样做的意义也就越大。
• （5）数据节点处理与数据相关的操作，例如CRUD，搜索和聚合。这些操作是I /
  O，内存和CPU密集型的，所以他们需要更高配置的服务器以及更高的带宽，并且集群的性能冗余非常重要。
• （6）由于仅投票节不参与Master竞选，所以和真正的Master节点相比，它需要的内存和CPU较少。但是，所有候选节点以及仅投票节点都可能是数据节点，所以他们都需要快速稳定低延迟的网络。
• （7）高可用性（HA）群集至少需要三个主节点，其中至少两个不是仅投票节点。即使其中一个节点发生故障，这样的群集也将能够选举一个主节点。生产环境最好设置3台仅Master候选节点（node.master
  = true node.data = true）
• （8）为确保群集仍然可用，集群不能同时停止投票配置中的一半或更多节点。只要有一半以上的投票节点可用，群集仍可以正常工作。这意味着，如果存在三个或四个主节点合格的节点，则群集可以容忍其中一个节点不可用。如果有两个或更少的主机资格节点，则它们必须都保持可用