基于Elasticsearch集群的shard分配方法与流程

基于elasticsearch集群的shard分配方法
技术领域
1.本技术涉及于elasticsearch集群技术领域，特别是涉及一种基于elasticsearch集群的shard分配方法。


背景技术：

2.shard，也称分片。单台服务器无法存储大量数据，由于elasticsearch集群具有分布式存储的特点，因此elasticsearch集群可以将一个索引(index)中的数据切分为多个shard，分布在多个节点上存储。
3.传统elasticsearch集群的shard分配规则主要针对的是非存储计算分离模式下的shard分配，主要在于新建索引(index)时的shard分配、节点失联时的shard分配、以及整个elasticsearch集群重启时的shard分配。非存储计算分离模式下，各个节点的shard数据独立存储在各个节点上，互相独立，无法互相调取。传统shard分配规则中，分配是根据每个索引(index)在每个节点(node)上的shard数量决定的，其中夹杂着一些用户的自定义规则以及elasticsearch集群自己的存储阈值限制。新建索引时，非存储计算分离模式单纯考虑每个节点(node)上的shard数、自定义规则和elasticsearch集群的存储阈值，而未考虑节点(node)的状态，例如内存状态、cpu状态等，可能因各个索引(index)的使用情况不同最终导致最终集群存在不均衡性和不稳定性。而在存储计算分离模式下，各个节点的shard数据存储在共享存储器中，并且可以互相共享，那么此时各个节点(node)的内存状态、cpu状态就变得非常重要。


技术实现要素：

4.基于此，有必要针对传统基于elasticsearch集群的shard分配方法用于存储计算分离模式下，容易导致elasticsearch集群存在不均衡性和不稳定性的问题，提供一种基于elasticsearch集群的shard分配方法。
5.本技术提供一种基于elasticsearch集群的shard分配方法，应用于elasticsearch集群的存储计算分离模式，所述方法包括：
6.判断是否接收到客户端发送的创建索引请求；
7.若接收到客户端发送的创建索引请求，则依据所述创建索引请求构建shard分配规则；
8.依据shard分配规则获取从节点中的可分配从节点；
9.依据每一个可分配从节点的cpu利用状态和内存利用状态，计算每一个可分配从节点的权重，并选取权重最小的可分配从节点作为shard分配节点；
10.在所述shard分配节点处创建一个shard；
11.返回所述依据每一个可分配从节点的cpu利用状态和内存利用状态的步骤，创建下一个shard，直至创建的shard总数达到预设shard数量，完成索引的创建。
12.本技术涉及一种基于elasticsearch集群的shard分配方法，在创建新索引时，主
节点在分配一个新的shard时，先考虑当前每一个可分配从节点的cpu状态和内存状态再进行分配，可以实现将新的shard分配在当前cpu利用率和内存利用率综合最小的可分配从节点上，避免将新的shard创建在已经负载很高的可分配从节点上，从而使得elasticsearch集群运行更均衡，更稳定。
附图说明
13.图1为本技术一实施例提供的基于elasticsearch集群的shard分配方法的流程示意图。
具体实施方式
14.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
15.本技术提供一种基于elasticsearch集群的shard分配方法。
16.此外，本技术提供的基于elasticsearch集群的shard分配方法不限制其执行主体。可选地，本技术提供的基于elasticsearch集群的shard分配方法的执行主体的可以为一种基于elasticsearch集群的shard分配系统。所述shard分配系统包括主节点服务器，多个从节点服务器和共享存储器。每一个从节点服务器均与主节点服务器通信连接。每一个从节点服务器均与共享存储器通信连接。主节点服务器和多个从节点服务器构成elasticsearch集群。
17.如图1所示，在本技术一实施例中，所述基于elasticsearch集群的shard分配方法包括如下s100至s600：
18.s100，判断是否接收到客户端发送的创建索引请求。
19.具体地，shard分配系统中的主节点服务器(以下主节点服务器简称“主节点”)判断是否接收到客户端发送的创建索引请求。elasticsearch集群可以包括一个主节点服务器(以下简称“主节点”)和多个从节点服务器(以下从节点服务器简称“从节点”)。elasticsearch集群还包括一个共享存储器，用于存储所有节点的shard数据。shard数据是以文件形式存储的数据。
20.客户端和elasticsearch集群是连接的，即客户端和每一个从节点服务器连接。客户端可以通过其他从节点服务器录入数据。客户端向主节点去发起创建索引请求，主节点判断是否接收到客户端发送的创建索引请求。
21.s200，若接收到客户端发送的创建索引请求，则依据所述创建索引请求构建shard分配规则。
22.具体地，主节点若接收到客户端发送的创建索引请求，则依据所述创建索引请求构建shard分配规则。可选地，主节点依据elasticsearch集群自身的allocation策略和用户自定义的规则创建shard分配规则。shard分配规则觉得了哪些从节点是可以分配该新建索引的shard，哪些从节点无法或者不适合分配该新建索引的shard。
23.s300，依据shard分配规则获取从节点中的可分配从节点。
24.具体地，依据shard分配规则，主节点可以获知在从节点中哪些从节点是可以分配
该新建索引的shard，这些从节点被定义为可分配从节点。
25.s400，依据每一个可分配从节点的cpu利用状态和内存利用状态，计算每一个可分配从节点的权重，并选取权重最小的可分配从节点作为shard分配节点。
26.具体地，可分配从节点的cpu利用状态可以为可分配从节点的的可分配从节点的cpu利用率。可分配从节点的内存利用状态可以为可分配从节点的内存利用率。可以根据可分配从节点的cpu利用率和内存利用率计算权重。可分配从节点的权重越小，代表可分配从节点的cpu利用率和内存利用率综合越小，代表可分配从节点的负载越低。主节点将权重最小的可分配从节点作为shard分配节点。
27.s500，在所述shard分配节点处创建一个shard。
28.具体地，在shard分配节点创建shard是最优的，因为此时shard分配节点一定是当前所有可分配节点中负载最小的。
29.s600，返回所述s400，创建下一个shard，直至创建的shard总数达到预设shard数量，完成索引的创建。
30.具体地，创建一个新索引时，可能会需要创建多个shard，创建shard的数量由具体索引创建的需求决定，这个数量定义为预设shard数量。由于在shard分配节点处创建一个shard后，该shard分配节点的cpu利用状态和内存利用状态也会产生变化，创建下一个shard时，就需要返回s400，重新获取各个可分配从节点的cpu利用状态和内存利用状态，再去计算权重进行下一个shard的分配，如此循环往复。
31.本实施例中，在创建新索引时，主节点在分配一个新的shard时，先考虑当前每一个可分配从节点的cpu状态和内存状态再进行分配，可以实现将新的shard分配在当前cpu利用率和内存利用率综合最小的可分配从节点上，避免将新的shard创建在已经负载很高的可分配从节点上，从而使得elasticsearch集群运行更均衡，更稳定。
32.在本技术一实施例中，所述s400包括如下s410至s492：
33.s410，选取一个可分配从节点。
34.具体地，本实施例中s410至s491阐述了一个shard分配的过程。一个shard分配的过程包括了多个可分配从节点的权重计算过程。本步骤为第一步，选取一个可分配从节点，进行后续的权重计算。
35.s420，获取预设索引权重平衡因子、预设节点权重平衡因子、所述索引在所述可分配从节点上的shard总数、以及所述索引在所有可分配从节点上的shard平均数。
36.具体地，预设索引权重平衡因子和预设节点权重平衡因子由用户设定或者查阅历史资料设定，也可以直接提取历史计算权重的数据记录中的数据进行使用。
37.所述索引在所述可分配从节点上的shard总数，所述索引在所有可分配从节点上的shard平均数，这两个数据是和索引相关的数据。初始状态下，这两个数据是0，因为还没有任何shard已分配完毕，而在后续shard不断分配的过程中，这两个数据的值都可能会上升。
38.例如，可分配从节点包括从节点a，从节点b，从节点c和从节点d，s410中选取的可分配从节点为从节点a，那么本步骤中获取的就是索引在从节点a上的shard总数，以及索引在所有可分配从节点(从节点a，从节点b，从节点c和从节点d)上的shard平均数。
39.s430，获取所述可分配从节点上当前已有的shard总数、以及所有可分配从节点上
当前已有的shard平均数。
40.具体地，所述可分配从节点上当前已有的shard总数，所有可分配从节点上当前已有的shard平均数，这两个数据是和索引无关的数据。由于不同的业务会创建不同的索引，因此在本次创建索引之前，可能存在其他索引已经在一些可分配从节点上创建了shard。
41.例如，可分配从节点包括从节点a，从节点b，从节点c和从节点d，s410中选取的可分配从节点为从节点a，那么本步骤中获取的就是从节点a上的shard总数，以及所有可分配从节点(从节点a，从节点b，从节点c和从节点d)上的shard平均数。
42.s440，依据公式1分别计算所述可分配从节点的索引权重和节点权重。
[0043][0044]
其中，weight
index
(node,index)为所述可分配从节点的索引权重。weight
node
(node,index)为所述可分配从节点的节点权重。indexbalance为预设索引权重平衡因子。shardbalance为预设节点权重平衡因子。node.numshards(index)为所述索引在所述可分配从节点上的shard总数。avgshardspernode(index)为所述索引在所有可分配从节点上的shard平均数。node.numshards为所述可分配从节点上当前已有的shard总数。avgshardspernode为所有可分配从节点上当前已有的shard平均数。
[0045]
具体地，公式1使用了s420和s430中所获取的参数。
[0046]
s450，获取所述可分配从节点的当前cpu利用率和当前内存利用率，以及第一配置参数、第二配置参数和第三配置参数。
[0047]
具体地，可以使用cpu的处理能力基准计算实时cpu利用率，或者运行cpu测试程序获取cpu利用率。
[0048]
linux系统下，可以调取/proc/meminfo或者更直观的free命令来获取当前内存利用率，或者运行内存测试程序获取内存利用率。
[0049]
s460，依据公式2计算所述可分配从节点的cpu权重和内存权重。
[0050][0051]
其中，weight
cpu
为所述可分配从节点的cpu权重。weight
mem
为所述可分配从节点的内存权重。ratio
cpu
为所述可分配从节点的当前cpu利用率。ratio
mem
为所述可分配从节点的当前内存利用率。θ0为第一配置参数。θ1为第二配置参数。θ2为第三配置参数。
[0052]
具体地，第一配置参数、第二配置参数和第三配置参数在设置时，需要保证三者的和为1。
[0053]
s470，依据公式3计算所述可分配从节点的平衡权重。
[0054]
weight
node,index
＝[weight
index
(node,index) weight
inode
(node,index)]
×
θ
2 公式3
[0055]
其中，weight
node,index
为所述可分配从节点的平衡权重。weight
index
(node,index)为所述可分配从节点的索引权重。weight
inode
(node,index)为所述可分配从节点的节点权重。θ2为第三配置参数。
[0056]
s480，依据公式4计算所述可分配从节点的权重。
[0057][0058]
其中，weight
node
为所述可分配从节点的权重。weight
cpu
为所述可分配从节点的cpu权重。weight
mem
为所述可分配从节点的内存权重。weight
node,index
为所述可分配从节点的平衡权重。
[0059]
具体地，通过公式4最终计算出所述s410选出的可分配从节点的权重，可选地，可以将该可分配从节点的权重置入一个权重列表中。
[0060]
s491，返回s410，直至所有可分配从节点的权重均计算完毕。
[0061]
具体地，反复执行s410直至s480，直至创建的shard总数达到预设shard数量为止。由于shard创建了预设shard数量个，那么权重也相应的计算出预设shard数量个。此时，权重列表中的权重数量就等于预设shard数量。
[0062]
s492，选取权重最小的可分配从节点作为shard分配节点。
[0063]
具体地，可以将权重列表中的所有权重按从小到大的顺序排序，最终筛选出最小权重。将最小权重对应的可分配从节点作为shard分配节点。
[0064]
本实施例中，通过索引在所述可分配从节点上的shard总数，索引在所有可分配从节点上的shard平均数，可分配从节点上当前已有的shard总数，以及所有可分配从节点上当前已有的shard平均数这四个参数计算当前的可分配节点的权重，考虑了cpu利用和内存利用的实时变化性，使得每一个新的shard分配在当前cpu利用率和内存利用率综合最小的可分配从节点上，避免将新的shard创建在已经负载很高的可分配从节点上。
[0065]
在本技术一实施例中，在s400之后，在s500之前，所述基于elasticsearch集群的shard分配方法还包括如下步骤：
[0066]
s493，向各个可分配从节点下发分配状态信息。所述分配状态信息包括shard分配规则。
[0067]
具体地，本步骤s493包括：
[0068]
s493a，依据所述shard分配节点，更新分配状态信息。分配状态信息包括shard分配规则，
[0069]
s493b，向各个可分配从节点下发更新后的分配状态信息。
[0070]
在s400步骤之后，已经选取权重最小的可分配从节点作为shard分配节点，那么需要更新分配状态信息。更新分配状态信息最主要的是更新shard分配规则，这样做的目的是让其他从节点知晓本次shard分配的结果，从而让其他从节点知晓本次shard将会创建在哪一个从节点，便于其他从节点后续的数据调度。后续主节点向各个可分配从节点下发更新后的分配状态信息。更新的时候还会更新elasticsearch集群的其他信息
[0071]
本实施例中，向各个可分配从节点下发分配状态信息，有助于其他从节点知晓本次shard将会创建在哪一个从节点，便于其他从节点后续的数据调度。后续主节点向各个可分配从节点下发更新后的分配状态信息。
[0072]
在本技术一实施例中，所述s400包括如下步骤：
[0073]
s410，依据所述shard分配规则，在所述shard分配节点处创建一个shard。在创建该shard时，写入shard状态元数据。所述shard状态元数据包括所述shard分配节点的节点id。
[0074]
具体地，shard状态元数据又称为shard state，主要用作elasticsearch重启时的shard分配判断依据。节点id又称为node id，在从节点第一次启动的时候会生成一个节点id，并记录下来，再次启动该从节点时节点id不会变更，是一个从节点的唯一标识符。
[0075]
本实施例中，通过在创建shard时，同步写入shard状态元数据，使得节点id和shard分配建立映射关系，使得在elasticsearch集群重启后，elasticsearch可以保留记忆，记住当时分配该shard时具体分配在哪一个从节点了。
[0076]
在本技术一实施例中，在s600之后，所述基于elasticsearch集群的shard分配方法还包括如下s710至s772：
[0077]
s710，判断elasticsearch集群是否正在重启。
[0078]
具体地，s100至s600介绍了本技术的创建索引时的shard分配流程。在s600之后，通过执行s710判断elasticsearch集群是否正在重启。如果elasticsearch集群正在重启，则需要执行后续s720至s772的集群重启时的shard分配流程。
[0079]
s720，若elasticsearch集群正在重启，则在elasticsearch集群重启时，主节点获取各个可分配从节点的索引信息。
[0080]
具体地，反之，若elasticsearch集群没有正在重启，则返回s710，继续监控elasticsearch集群是否正在重启。
[0081]
s730，依据各个从节点的索引信息，获取各个从节点的shard信息。所述shard信息包括shard状态元数据。
[0082]
具体地，通过获取一个从节点的索引信息，可以获知该从节点的shard信息。而shard信息包括shard状态元数据，shard状态元数据又可能包括节点id，因此可以通过是否包括节点id后续确定是否在该节点上分配过shard。
[0083]
s740，选取一个从节点，读取所述从节点的shard状态元数据。
[0084]
具体地，shard信息包括shard状态元数据。
[0085]
s750，判断所述从节点的shard状态元数据是否包含节点id。
[0086]
具体地，shard状态元数据可能包括节点id，也可能不包括节点id。
[0087]
s760，若所述从节点的shard状态元数据包含节点id，则进一步判断与该节点id对应的从节点是否处于可用状态。
[0088]
具体地，若所述从节点的shard状态元数据包含节点id，则表明该从节点之前被分配过shard(或者换言之在这个从节点上创建过shard)，留下了节点id，那么进一步判断与该节点id对应的从节点是否处于可用状态。
[0089]
反之，若所述从节点的shard状态元数据未包含节点id，则表明该从节点之前未被分配过shard，或者存在极端情况是该从节点的shard状态元数据损坏丢失了节点id的数据，但是，无论是这两种中的哪一种情况，实际上结果是一样的，该从节点的shard状态元数据未包含节点id。此时，返回s740，读取下一个从节点的shard状态元数据。
[0090]
s771，若与该节点id对应的从节点处于可用状态，则更新shard分配规则，向所述
从节点下发分配状态信息，以控制所述从节点从共享存储器中加载所述从节点上已分配shard的shard数据。
[0091]
具体地，若与该节点id对应的从节点处于可用状态，则表示节点id不但存在，且该从节点处于可用状态，一切正常，无需重新分配shard。本步骤中的分配状态信息的过程和前述s493b的原理是一样，此时只需要从共享存储器中加载所述从节点上已分配的所有shard的shard数据即可。
[0092]
s772，返回s740直至所有从节点的shard信息均被读取完毕。
[0093]
具体地，返回s740，直至所有从节点的shard信息均被读取并处理完毕。
[0094]
本实施例中，通过整个elasticsearch集群的分配状态信息下发时，将节点id和shard的映射关系存放至shard信息中，并实时监控elasticsearch集群重启状态。当elasticsearch集群重启时，则根据shard信息在shard对应的从节点处恢复shard的shard数据，保证elasticsearch集群重启后的集群状态和上次elasticsearch集群停止前的集群状态一致，最大化保证了elasticsearch集群的稳定性和均衡性。
[0095]
在本技术一实施例中，在s760之后，述基于elasticsearch集群的shard分配方法还包括如下s781至s782：
[0096]
s781，若与该节点id对应的从节点处于不可用状态，则返回所述s300，重新分配处于不可用状态的从节点的shard。
[0097]
具体地，若与该节点id对应的从节点处于不可用状态，则这个从节点可能出现某些数据错误，无法再使用，此时需要将该处于不可用状态的从节点的所有shard进行重新分配。重新分配时，返回s300，执行s300至s500来分配每一个shard。
[0098]
s782，更新shard分配规则，向所述从节点下发分配状态信息，以控制重新分配到所述shard的从节点从共享存储器中加载所述shard的shard数据。
[0099]
具体地，由于shard进行了重新分配，因此shard分配规则需要更新并重新下各个从节点下发分配状态信息，以让各个从节点知晓这些shard重新分配到了哪些从节点上。并且从共享存储器中加载这些重新分配的shard的shard数据。
[0100]
s783，返回s740直至所有从节点的shard信息均被读取完毕。
[0101]
具体地，本从节点的shard重分配处理完毕，返回s740读取下一个从节点的shard信息。
[0102]
本实施例中，当elasticsearch集群重启时，若shard对应的从节点不可用，通过重新分配shard，尽量保证elasticsearch集群重启后的集群状态和上次elasticsearch集群停止前的集群状态接近一致，最大化保证了elasticsearch集群的稳定性和均衡性。
[0103]
在本技术一实施例中，在s600之后，所述基于elasticsearch集群的shard分配方法还包括如下s810至s840：
[0104]
s810，实时监控每一个从节点和主节点的通信状态。
[0105]
s820，当一个从节点和主节点的通信状态处于失联状态时，将该从节点定义为失联从节点。
[0106]
s830，该失联从节点向任意一个备用主节点发送ping请求，判断是否可以和任意一个备用主节点建立通信连接。
[0107]
s840，若该失联从节点可以和任意一个备用主节点建立通信连接，则维持该失联
从节点所持有的shard的数据锁。
[0108]
具体地，本实施例s810至s840介绍了s600之后的另一个监控从节点失联状态的流程。需要注意的是，本实施例中的s810至s840是和s710至s772的监控集群重启状态和当集群重启时的shard分配流程是异步进行的，即可以同时进行监控集群重启和监控从节点失联状态。
[0109]
因为shard目录存在数据锁机制，当一个线程占用，其他线程无法对该shard目录进行写入操作。因此，本实施例在主节点和从节点失联的情况下，先判断是该失联从节点存在问题，还是其他问题导致失联。如果该失联从节点可以和另一个备用主节点正常通行，则认为失联从节点是正常的，是其他问题导致失联。
[0110]
由于此时认为失联主节点是正常的，因此无需解开该失联从节点所持有的shard的数据锁，维持该失联从节点所持有的shard的数据锁。此时可能是由于网络抖动等其他问题导致失联，可以重新启动elasticsearch集群来重新建立主节点和从节点的通信连接。
[0111]
在本技术一实施例中，在所述s830之后，所述基于elasticsearch集群的shard分配方法还包括如下s850至s860：
[0112]
具体地，若该失联从节点无法和任何一个备用主节点建立通信连接，则表明就是这个失联从节点存在问题，此时需要将该失联从节点的shard进行转移。
[0113]
s850，若该失联从节点无法和任何一个备用主节点建立通信连接，则释放该失联从节点所持有的shard的数据锁。
[0114]
具体地，先释放失联从节点数据锁。
[0115]
s860，主节点返回所述s300，将该失联从节点所持有的shard重新分配到其他通信状态正常的可分配从节点上。
[0116]
具体地，重新分配shard时，还是执行s300至s500的步骤。
[0117]
本实施例中，在主节点和从节点失联时，通过排查失联从节点是否有通信状态问题，并在确定失联从节点有通信状态问题时释放shard的数据锁，并将失联从节点所持有的shard重新分配到其他通信状态正常的可分配从节点上，保证了elasticsearch集群的正常运行和shard数据的正常调取。
[0118]
在本技术一实施例中，在s600之后，所述基于elasticsearch集群的shard分配方法还包括如下s910至s930：
[0119]
s910，判断是否接收到客户端发送的集群路由请求。
[0120]
本实施例s910至s930介绍了s600之后的另一个监控流程，即监控集群路由请求的流程。前述s710至s772介绍了监控集群重启状态的流程，前述s810至s840介绍了监控从节点失联状态的流程。需要注意的是，本实施例中的s910至s930，和s810至s840，s710至s772三者可以异步进行的，即在索引创建后，可以同时进行监控集群重启状态，监控从节点失联状态和监控集群路由请求。
[0121]
集群路由请求又称为shard reroute请求，是由客户端发起的。主节点接受集群路由请求后，开始执行集群路由过程。集群路由就是将一个指定shard由一个指定源从节点至另一个指定从节点。简言之，就是shard在两个从节点之间的转移。
[0122]
s920，若接收到客户端发送的集群路由请求，则进一步判断是否可以将指定shard由指定源从节点至指定从节点。
[0123]
具体地，由于存在shard转移的障碍的可能性，因此需要在本步骤中进行判断是否可以移动该shard。是否可以将指定shard由指定源从节点至指定从节点的判断，也是通过集群的allocation策略和集群的自定义策略来确定。
[0124]
s930，若不可以将指定shard转移至指定从节点，则向客户端返回无法转移所述指定shard的消息，终止后续步骤。
[0125]
在非存储计算分离模式下，传统的shard分配方法中，由于传统的集群结构shard数据是不共享的，从节点之间的shard转移需要远程先将数据拷贝，本身相当于要预留存储两份shard数据的存储空间，而本实施例中，shard数据是存在共享存储器中的，无需数据拷贝，只需要一份shard数据的存储空间，大大节省了存储空间。
[0126]
在本技术一实施例中，在s920之后，所述基于elasticsearch集群的shard分配方法还包括如下
[0127]
s941，若可以将指定shard转移至指定从节点，则更新shard转移之后的shard分配规则。
[0128]
具体地，shard分配规则更新的流程和目的前述多个实施例已经提及，这里不再赘述。
[0129]
s942，将更新后的shard分配规则存储于shard状态元数据中，并下发至各个从节点。
[0130]
具体地，这个步骤也是和前述多个实施例中提及的下发步骤同理，为了让各个从节点知晓本次shard的转移，便于后续的shard数据的调取方便。
[0131]
s943，当指定目标从节点收到shard状态元数据时，向指定源从节点发送转移请求。
[0132]
具体地，当指定目标从节点收到shard状态元数据时，知晓了它是转移的被动方，触发向指定源从节点，即转移的主动方发送转移请求的步骤。
[0133]
s944，指定源从节点释放shard的数据锁，并向指定目标从节点返回释放数据锁成功的消息。
[0134]
具体地，转移前需要释放shard的数据锁，否则无法转移shard。
[0135]
s945，在指定目标从节点收到释放数据锁成功的消息后，从共享存储器读取所述指定shard的shard数据并加载，并向主节点发送转移完成消息。
[0136]
具体地，注意到，此时不需要远程拷贝shard数据，由于所有shard数据都是在共享存储器存储，因此，直接从共享存储器读取所述指定shard的shard数据并加载加载即可，大大节省时间。
[0137]
s946，主节点收到转移完成消息后，更新整个elasticsearch集群的shard分配状态信息，生成新的shard分配状态信息，以广播的形式下发到各个从节点。
[0138]
具体地，更新整个elasticsearch集群的shard分配状态信息，以更新整个elasticsearch集群的集群状态，广播至各个从节点让各个从节点知晓。
[0139]
在非存储计算分离模式下，传统的shard分配方法中，由于传统的集群结构shard数据是不共享的，从节点之间的shard转移需要远程先将数据拷贝，速度慢消耗时间长，而本实施例中，shard数据是存在共享存储器中的，无需数据拷贝，速度快消耗的时间短。
[0140]
本技术还提供一种基于elasticsearch集群的shard分配系统。
[0141]
在本技术一实施例中，所述基于elasticsearch集群的shard分配系统包括主节点服务器，多个从节点服务器和共享存储器。每一个从节点服务器均与主节点服务器通信连接。每一个从节点服务器均与共享存储器通信连接。主节点服务器和多个从节点服务器构成elasticsearch集群。
[0142]
以上所述实施例的各技术特征可以进行任意的组合，各方法步骤也并不做执行顺序的限制，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0143]
以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术的保护范围应以所附权利要求为准。