高可用 Elasticsearch 集群的分片设计解析

Elasticsearch 的一个分片对应 Lucene 的一个索引，Elasticsearch 的核心就是将这些 Lucene 索引分布式化，提供索引和检索服务。可见，如何设计分片是至关重要的。

一个索引到底该设置几个主分片呢？由于单个分片只能处于 Elasticsearch 集群中的单个节点，分片太少，影响索引入库的并发度，以及以后的横向扩展性，如果分片过大会引发查询、更新、迁移、恢复、平衡等性能问题。

3.1 主分片数量确定

我们建议综合考虑分片物理大小因素、查询压力因素、索引压力因素，来设计分片数量。

3.1.1 物理大小因素

建议单个分片的物理大小不大于 50GB，之所以这样建议，基于如下几个因素：

• 更快的恢复速度

集群故障后，更小的分片相对大分片来讲，更容易使集群恢复到 Green 状态。

• merge 过程中需要的资源更少

Lucene 的 segment merge 过程需要两倍的磁盘空间，如果分片过大，势必需要更大的临时磁盘空间用于 merge，同时，分片过大 merge 过程持续时间更长，将对 IO 产生持续的压力。

• 集群分片分布更容易均衡

分片过大，Elasticsearch 内部的平衡机制需要更多的时间。

• 提高 update 操作的性能

对 Elasticsearch 索引进行 update 操作，底层 Lucene 采用的是先查找，再删除，最后 index 的过程。如果在分片比较大的索引上有比较多的 update 操作，将会对性能产生很大的影响。

• 影响缓存

节点的物理内存是有限的，如果分片过大，节点不能缓存分片必要的数据，对一些数据的访问将从物理磁盘加载，可想而知，对性能会产生多大的影响。

3.1.2 查询压力因素

单个 shard 位于一个节点，如果索引只有一个 shard，则只有一个节点执行查询操作。如果有多个 shard 分部在不同的节点，多个节点可以并行执行，最后归并。

但是过多的分片会增加归并的执行时间，所以考虑这个因素，需要根据业务的数据特点，以贴近真实业务的查询去测试，不断加大分片数量，直到查询性能开始降低。

• 索引压力因素

单个 shard 只能位于一块单个节点上，索引过程是 CPU 密集型操作，单个节点的入库性能是有限的，所以需要把入库的压力分散到多个节点来满足写入性能。单纯考虑索引性能，可以根据单个节点的索引性能和需要索引的总性能来估算分片数量。

3.2 副本数量

副本是主分片的拷贝，可以响应查询请求、防止数据丢失、提高集群可用性等，但是副本不是“免费”的，需要占用与主分片一样的资源，包括 CPU、内存、磁盘，副本数量的确定等涉及多方面的因素。

3.2.1 数据可靠性

明确自己的业务需要多高的可靠性和可用性。依据 Elasticsearch 的内部分片分布规则，同一索引相同编号的分片不会处于同一个 node，多一份副本就多一份数据安全性保障。

3.2.2 索引性能

副本和主分片在索引过程中执行和主分片一样的操作，如果副本过多，有多少副本就会有几倍的 CPU 资源消耗在索引上，会拖累整个集群的索引吞吐量，对于索引密集型的业务场景影响巨大。所以要在数据安全型和索引性能上做权衡处理来确定副本的数量。

3.2.3 查询性能

副本可以减轻对主分片的查询压力，这里可能说查询次数更为合理。节点加载副本以提供查询服务和加载主分片消耗的内存资源是完全相同的，增加副本的数量势必增加每个 node 所管理的分片数，因此会消耗更多的内存资源，Elasticsearch 的高速运行严重依赖于操作系统的 Cache。

如果节点本身内存不充足，副本数量的增加会导致节点对内存的需求的增加，从而降低 Lucene 索引文件的缓存效率，使 OS 产生大量的换页，最终影响到查询性能。当然，在资源充足的情况下，扩大副本数是肯定可以提高集群整体的 QPS。

3.3 分片分布

ELasticsearch 提供的关于 shard 平衡的两个参数是 cluster.routing.allocation.balance.shard和 cluster.routing.allocation.balance.index。

第一个参数的意思是让每个节点维护的分片总数尽量平衡，第二个参数的意思是让每个索引的的分片尽量平均的分散到不同的节点。

如果集群中有不同类型的索引，而且每个类型的索引的索引方式、物理大小不一致，很容易造成节点间磁盘占用不均衡、不同节点间堆内存占用差异大的问题，从而导致集群不稳定。

所以我们建议尽量保证不同索引的 shard 大小尽量相近，以获得实质意义上的均衡分片分布。

3.4 集群分片总数控制

由于 Elasticsearch 的集群管理方式还是中心化的，分片元信息的维护在选举出来的 master 节点上，分片过多会增加查询结果合并的时间，同时增加集群管理的负担。

根据我们的经验，单个集群的分片超过 10 万时，集群维护相关操作例如创建索引、删除索引等就会出现缓慢的情况。所以在实践中，尽量控制单个集群的分片总数在 10 万以内。

3.5 【案例分析】大分片数据更新引发的 IO 100% 异常

大分片数据更新引发的 IO 100% 异常。