主要内容：ES的基础分布式架构，shard&replica机制，横向扩容过程，容错机制

1、ES的基础分布式架构

1. Elasticsearch对复杂分布式机制的透明隐藏特性
2. Elasticsearch的垂直扩容与水平扩容
3. 增减或减少节点时的数据rebalance
4. master节点
5. 节点对等的分布式架构

1、Elasticsearch隐藏了复杂分布式机制

Elasticsearch是一套应对大数据量的分布式系统，它隐藏了复杂的分布式机制，包括：

1、分片机制

2、cluster discovery（集群发现机制）

3、shard负载均衡（es会自动进行均匀分配，以保持每个节点的均衡的读写负载请求）

4、shard副本，请求路由，集群扩容，shard重分配

2、Elasticsearch的垂直扩容与水平扩容

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

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

3、增减或减少节点时的数据rebalance

增加和减少节点之后，ES会分配分片到新的节点上，保持负载均衡

4、master节点

master节点不承载所有的请求，不会是单节点瓶颈

（1）管理ES集群的元数据，创建和删除索引，节点的增加和移除，维护集群的元数据
（2）默认情况下，会自动选出一个master节点

5、节点平等的分布式架构

（1）节点对等，每个节点都能接收所有的请求
（2）自动请求路由
（3）响应请求的节点收集其他节点返回的数据

2、shard&replica机制

1、shard&replica机制梳理
2、单node环境下创建index

1、shard&replica机制梳理

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

2、单node环境下创建index

（1）单node环境下，创建一个index，有3个primary shard，3个replica shard
（2）集群status是yellow
（3）这个时候，只会将3个primary shard分配到仅有的一个node上去，另外3个replica shard是无法分配的
（4）集群可以正常工作，但是一旦出现节点宕机，数据全部丢失，而且集群不可用，无法承接任何请求

建立索引时指定primary shard和replica shard

示例：primary shard 指定为3个，每个primary shard 分配一个 replica shard

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

3、2个node环境下replica shard是如何分配的

（1）3个replica shard会被分配到另一个node上
（2）primary和 replica会自动进行同步
（3）primary/replica同时承载查询请求

3、横向扩容过程

（1）primary&replica自动负载均衡， 分片会被均匀分摊到每一个node上
（2）每个node有更少的shard，IO/CPU/Memory资源给每个shard分配更多，每个shard性能更好
（3）扩容的极限，6个shard（3 primary，3 replica），最多扩容到6台机器，每个shard可以占用单台服务器的所有资源，性能最好
（4）超出扩容极限，动态修改replica数量，9个shard（3primary，6 replica），扩容到9台机器，比3台机器时，拥有3倍的读吞吐量
（5）3台机器下，9个shard（3 primary，6 replica），资源更少，但是容错性更好，最多容纳2台机器宕机，6个shard只能容纳1台机器宕机
（6）一方面：扩容的原理，怎么扩容，怎么提升系统整体吞吐量；另一方面要考虑到系统的容错性，怎么保证提高容错性，尽可能多的服务器宕机，但保证数据不丢失

4、Elasticsearch容错机制

流程：master选举->replica容错->数据恢复

以三个节点 9个分片（3个primary 6个replica）的情况为例：

（1）master node宕机，缺少一个primary shard，此时不是所有的primary shard 为active，集群状态为 red

（2）集群通过选举产生新的master

（3）replica容错：新master将replica提升为primary shard，此时不是所有的副本是active， 集群状态为yellow
（4）重启宕机node，master copy replica到该node，补充缺失的副本，而且该node会使用之前的shard数据，并同步宕机后的修改，集群状态为green

补充知识点：

灾难描述：

通过错误日志分析：超长关键词模糊查询触发lucene内部错误，导致整个集群全部宕机

灾难恢复面临问题

• 1. 重启整个集群
• 1. 打开被close的索引
     POST */_open
• 1. 查看集群健康状态
     GET _cat/health 集群状态RED
• 1. 查看索引分片状态
     GET _cat/shards 商品索引2号shard主副分片全部UNASSIGNED，提供的服务的数据只有60%

灾难恢复方案

• 1. 重启ElasticSearch集群
• 1. 恢复UNASSIGNED分片
     elasticsearch集群索引分片丢失的处理
• 1. 重建商品索引，重导全量数据(主副分片全部UNASSIGNED,分片恢复尝试无效)

灾难恢复

重建商品索引，重导全量数据

灾难总结及预防方案

• 1. 换掉模糊查询或者限制其关键字长度
• 1. 索引setting主副分片设置方案，主分片数量1 副分片数量2以上
• 1. 建立ElasticSearch快照(每隔2小时 视需求而定)
     Elasticsearch模块功能之-快照和恢复（snapshot and restore）

参考资料：

ElasticSearch集群宕机总结_大数据_weixin_33726313的博客-CSDN博客

https://blog.csdn.net/weixin_33726313/article/details/91406882