ES负载均衡及容错

1、ElasticSearch分布式基础

1.1 ES分布式机制

• 分布式机制：Elasticsearch是一套分布式的系统，分布式是为了应对大数据量。它的特性就是对复杂的分布式机制隐藏掉。
• 分片机制：数据存储到哪个分片，副本数据写入另外分片。
• 集群发现机制：新启动es实例，会自动加入集群。
• shard负载均衡：大量数据写入及查询，es会将数据平均分配。举例，假设现在有3个节点，总共有25个shard要分配到3个节点上去，es会自动进行均匀分配，以保持每个节点的均衡的读写负载请求。
• shard副本：新增副本数，分片重分配。

1.2 垂直与水平扩容

垂直扩容：使用更加强大的服务器替代老服务器。但单机存储及运算能力有上线。且成本直线上升。如10台1T的服务器1万，单个10T服务器可能20万。
水平扩容：采购更多服务器，加入集群。对于ES来说，一般采用水平扩容的方式。

1.3 rebalance

当新增或减少es实例时，或者新增加数据或者删除数据时，就会导致某些服务器负载过重或者过轻。es集群就会将数据重新分配，保持一个相对均衡的状态。

1.4 master节点

（1）管理es集群的元数据

• 创建删除节点
• 创建删除索引

（2）默认情况下，es会自动选择一台机器作为master，因为任何一台机器都可能被选择为master节点，所以单点故障的情况可以忽略不计。

1.5 节点对等

• 节点对等，每个节点都能接收所有的请求
• 自动请求路由
• 响应收集

2、节点负载均衡

elasticSearch的配置文件中有两个参数：node.master和node.data
组合一：node.master：false node.data：true
该node服务器只作为一个数据节点，只用于存储索引数据。使该node服务器功能单一，只用于数据存储和数据查询，降低其资源消耗率。
组合二：node.master：true node.data：false
该node服务器只作为一个主节点，但不存储任何索引数据。该node服务器将使用自身空闲的资源，来协调各种创建索引请求或者查询请求，讲这些请求合理分发到相关的node服务器上。
组合三：node.master：false node.data：false
该node服务器即不会被选作主节点，也不会存储任何索引数据（协调节点）。该服务器主要用于**查询负载均衡，**处理路由请求，处理搜索，分发索引操作等。在查询的时候，通常会涉及到从多个node服务器上查询数据，并请求分发到多个指定的node服务器，并对各个node服务器返回的结果进行一个汇总处理， 最终返回给客户端。
独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。
组合四：node.master：true node.data：true
这种组合表示这个节点即有成为主节点的资格，又存储数据，这个时候如果某个节点被选举成为了真正的主节点，那么他还要存储数据，这样对于这个节点的压力就比较大了。
ES默认每个节点都是这样的配置，在节点数较少的场景下，可以如此分配，但当节点的较多时，需分配好各自角色，单独划分部分节点为master节点。
目前大部分局点的节点较少，都为此模式。

3、读请求负载均衡

• 客户端发送请求到任意一个 node（协调节点）
• 协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard其中一个，用 round-robin随机轮询算法，让检索请求负载均衡
• 每个 shard 将自己的搜索结果（doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出doc id list
• coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin随机轮询算法，在primary shard和所有replica中随机选择一个，让读请求负载均衡
• 接收请求的node返回 document 给 coordinate node，由其返回 document 给客户端

什么是round-robin随机轮询算法？
名字高大上，其实就是循环、遍历这个意思，
不过它强调的一个轮转，且每个均匀，所以通常有取模的操作。

4、数据均衡

4.1 触发条件

• 新索引的建立
• 索引的删除
• 新增副本分片
• 节点增减引发的数据均衡

4.2 分配机制

分配的机制比较复杂
分布式架构的透明隐藏属性
_Elasti_csearch是一个分布式架构，隐藏了复杂的处理机制
1.一个index中包含多个shard
2.每个shard都是一个最小工作单元，承载部分数据；每个shard都是一个Lucene实例，有完整的建立索引和处理请求的能力
3.增减节点时，shard会自动在nodes中负载均衡
4.primary shard 和 relica shard,每个document只会存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard中
5.replica shard 是primary shard 的副本，负责容错，以及承担读请求的负载均衡
6.primary shard在创建索引的时候就固定了，relica shard的数量可以随时更改
7.primary shard 和 它对应的replica shard 不能放在同一台机器上，不然起不了容错的作用

5、es容错机制

以3分片，2副本数，3节点为例介绍。
master node宕机，自动master选举，集群为red
replica容错：新master将replica提升为primary shard，yellow
重启宕机node，master copy replica到该node，使用原有的shard并同步宕机后的修改，green
在node1宕机的情况下，那么P0 shard就会消失，所有的主分片不是全active，那么集群的状态是red。
容错第一步，重新选举master节点。承担master相关功能。
容错第二步，新master将丢失的P0 shard(主分片)对应的R0 replica(副本分片)提升为主分片，现在的集群状态为yellow并且少一个副本分片，但是现在集群已经可以恢复使用了。
容错第三步，重启故障node，新master会感知到新节点加入，将缺失的副本分片copy一份到新的node上面，copy的是被提升为主分片的分片。现在集群已经完全恢复，状态为green。
问题：在集群状态为green的情况下（每个分片都有副本），那么会不会出现一个noe挂了，就导致整个集群不可用的情况，主分片不是全active，集群的状态变为red，答案是不可能的，因为一个分片的主分片和副本分片不可能存在同一节点。

5、横向扩容

假如说存在一个book索引，shard3 replica1

• 分片自动负载均衡，分片向空闲机器转移。
• 每个节点存储更少分片，系统资源给与每个分片的资源更多，整体集群性能提高。
• 扩容极限：节点数大于整体分片数，则必有空闲机器。
• 超出扩容极限时，可以增加副本数，如设置副本数为2，总共3*3=9个分片。9台机器同时运行，存储和搜索性能更强。容错性更好。
• 容错性：只要一个索引的所有主分片在，集群就就可以运行。