ElasticSearch集群重平衡(Shard allocation)案例分析及性能调优

何谓重平衡

ElasticSearch为了使数据平均分布在集群节点上，重平衡机制会由Master节点决定索引分片具体分配到哪个Data节点以及何时在节点之间迁移分片，使分片在数据大小、分片数量的层面上尽可能均匀分布在集群中的所有Data节点，充分发挥每个数据节点的性能。

原理及概念

ES重平衡的触发条件

初始恢复(initial recovery)
副本分配(replica allocation)
重新平衡(rebalancing)
节点的新增和删除

主分片

索引数据会通过至少一个主分片进行存储，通过增加主分片数量，使数据平均分散到多个Data节点，实现存储的水平扩展，查询时由多个节点共同进行以提高查询效率。
注意：主分片在索引创建时指定，后续想要调整则需要重建索引

副本分片

用于提高数据可用性，当一个主分片丢失，其副本分片可以Promote成主分片，如果索引的副本分片为0，一旦节点出现硬件故障时可能造成数据丢失的情况。
副本分片由主分片同步，其数量支持动态调整，在一定程度上可以提高ES查询的吞吐量

ES查询时计算分片所在节点的路由算法

shard = hash(_routing) % number_of_primary_shards

通过Hash算法确保文档均匀分布到分片中
默认的_routing值为文档id（可在写入数据时，为需要分配到同一shard的商品指定_routing值）
通过算法计算查询的数据存在于哪些分片，这也是为什么索引创建出来后，不允许调整主分片数量的原因

# 指定_routing值

POST /my-index-000001/_doc?routing=my-routing-value

{

"@timestamp": "2099-11-15T13:12:00",

"message": "GET /search HTTP/1.1 200 1070000",

"user": {

"id": "kimchy"

}

# 查询时指定_routing值确保查询执行在同个分片

GET /my-index-000001/_search?routing=my-routing-value

{

"query": {

"match": {

"user.id": "kimchy"

}

ES默认的Query Then Fetch查询

Query阶段：默认配置下，每个节点都是Coordinating角色（负责转发查询请求），用户对某个索引发起查询请求到ES节点，节点收到请求后以Coordinating节点的身份将请求转发给其他分片，这些分片执行查询并排序。每个节点都会返回(From+Size)个排序后的文档ID和排序值给Coordinating节点。
Fetch阶段：Coordinating节点会将从各个分片收到的信息重新进行排序，选取From到(From+Size)个文档的ID，以multi get请求的方式，到相应的分片获取详细的文档数据，最终返回给客户端

重平衡所引发的问题（真实案例）

出于安全原因，客户的基础设施团队每月会进行一次虚拟机安全补丁更新，更新过程会批量重启所有虚拟机。

客户的ES集群正好部署在需要重启的多台虚拟机上，在更新完安全补丁后，所有集群的虚拟机都被正常重启，同时ES集群也恢复到Green的状态。

然而，客户发现ES的查询延迟比重启前慢了超过10倍！

盘云团队介入检查后发现是由于重平衡引起的问题，盘云团队对重平衡并发量及传输速率进行优化，最终半小时完成了整个ES集群的重平衡，用户查询性能得到了显著改善，业务也得以恢复。

原因分析

一、重平衡影响ES查询效率

ES进行查询时会将查询请求转发给所有分片进行查询，以此确保数据的准确性。
Coordinating节点转发给各个分片的查询请求后，会持续等待所有分片返回查询结果，当主分片未完全从ALLOCATING状态转为STARTED状态时，此分片将无法响应Coordinating节点的请求，导致Coordinating节点不能及时将查询结果进行Fetch并响应给客户端。
最终ES因为主分片未完成分配，无法完全发挥自身的查询能力。

可通过API查询集群健康状况及分片状态观察是否所有分片正常
GET _cluster/health
注意：若relocating_shards不为0时说明仍有分片正在重平衡，即使status为green也可能出现主分片重平衡情况