分布式系统内存回收的方法、装置及分布式系统

技术领域

本说明书实施例涉及计算机技术领域，特别涉及分布式系统内存回收的方法。本说明书一个或者多个实施例同时涉及分布式系统内存回收的装置，分布式系统，计算设备，以及计算机可读存储介质。

背景技术

GC(Garbage Collection，内存回收)，是用于在空闲时间不定时回收无任何对象引用的对象占据的内存空间的一种机制，可以提升系统执行效率和稳定性。例如，编译执行广泛用于OLAP数据数据库的优化。在数据库动态执行过程中，编译执行针对不同的执行计划生成出不同的代码，所以会产生大量的中间代码文件。具体到Java语言环境中，编译执行会产生大量的class字节码文件，存储于JVM的MetaSpace中。Java的自动内存回收机制会在不同的条件下被触发，对这些中间代码文件进行清理。在分布式系统中，工作节点为执行计算的节点，由工作节点各自基于JVM自动内存回收机制进行GC，以提升分布式系统的执行效率。

但是，工作节点的JVM自动内存回收有时不易发生，有时还会导致整个分布式系统的不可用，对分布式系统的执行效率带来一定影响。

发明内容

有鉴于此，本说明书实施例提供了分布式系统内存回收的方法。本说明书一个或者多个实施例同时涉及分布式系统内存回收的装置，分布式系统，计算设备，以及计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种分布式系统内存回收的方法，包括：响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息；根据所述可用性信息，确定需要执行内存回收的工作节点；向需要执行内存回收的工作节点，发送内存回收命令。

可选地，所述响应于满足内存回收条件包括：响应于工作节点的内存水位超过预设内存水位阈值，或者，响应于进入定期执行内存回收的新一轮周期。

可选地，所述向需要执行内存回收的工作节点，发送内存回收命令包括：根据所述可用信息，确定需要执行内存回收的工作节点的节点顺序；根据所述节点顺序，发送内存回收命令。

可选地，所述方法还包括：接收工作节点针对所述内存回收命令的响应；如果接收到的响应为拒绝，放弃对所述响应的工作节点的内存回收；如果响应超时，重试或者放弃对响应超时的工作节点的内存回收。

根据本说明书实施例的第二方面，提供了一种分布式系统内存回收的装置，配置于分布式系统的主节点，包括：信息获取模块，被配置为响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息。节点确定模块，被配置为根据所述可用性信息，确定需要执行内存回收的工作节点。命令发送模块，被配置为向需要执行内存回收的工作节点，发送内存回收命令。

根据本说明书实施例的第三方面，提供了一种分布式系统内存回收的方法，应用于工作节点，包括：为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令；接收主节点发送的内存回收命令；判断所述工作节点是否允许执行所述内存回收命令；如果允许，执行所述内存回收命令。

可选地，所述方法还包括：在所述工作节点的JVM自动内存回收机制被触发的情况下，判断所述工作节点是否允许执行JVM自动内存回收；如果允许，执行JVM自动内存回收。

可选地，所述判断所述工作节点是否允许执行所述内存回收命令包括：判断所述工作节点上一次内存回收的时刻与当前时刻的时间间隔是否达到允许执行内存回收的时间间隔范围，和/或者，判断所述工作节点的内存水位是否超过预设内存水位阈值。

可选地，所述工作节点上一次内存回收包括：响应于所述主节点或其他主节点上一次发送的内存回收命令而执行的内存回收，或者，所述工作节点上一次的JVM自动内存回收机制被触发而执行的内存回收。

可选地，还包括：如果不允许，向所述主节点反馈拒绝内存回收的响应消息，和/或，在所述内存回收命令执行完成的情况下，向所述主节点反馈内存回收成功完成的响应消息。

可选地，所述方法还包括：在工作节点重启的情况下，将所述工作节点的可用性信息默认设置为可用；在执行内存回收命令时，将所述工作节点的可用性信息更新为不可用；在内存回收命令执行完成的情况下，将所述工作节点的可用性信息更新为可用。

可选地，在执行内存回收之前，还包括：检查所述工作节点是否存在任务未完成；如果存在，在所述工作节点的任务完成之后，进入执行内存回收的步骤；如果不存在，进入执行内存回收的步骤。

根据本说明书实施例的第四方面，提供了一种分布式系统内存回收的装置，配置于工作节点，包括：信息提供模块，被配置为为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令。命令接收模块，被配置为接收主节点发送的内存回收命令。执行判断模块，被配置为判断所述工作节点是否允许执行所述内存回收命令。命令执行模块，被配置为如果所述执行判断模块判定为允许，执行所述内存回收命令。

根据本说明书实施例的第五方面，提供了一种分布式系统，包括：一个或多个主节点以及与所述主节点通信的多个工作节点。所述主节点，被配置为响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息；根据所述可用性信息，确定需要执行内存回收的工作节点；向需要执行内存回收的工作节点，发送内存回收命令。所述工作节点，被配置为为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令；接收主节点发送的内存回收命令；判断所述工作节点是否允许执行所述内存回收命令；如果允许，执行所述内存回收命令。

根据本说明书实施例的第六方面，提供了一种计算设备，包括：存储器和处理器；所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息；根据所述可用性信息，确定需要执行内存回收的工作节点；向需要执行内存回收的工作节点，发送内存回收命令。

根据本说明书实施例的第七方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现本说明书任意实施例所述应用于主节点的分布式系统内存回收的方法的步骤。

根据本说明书实施例的第八方面，提供了一种计算设备，包括：存储器和处理器；所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令；接收主节点发送的内存回收命令；判断所述工作节点是否允许执行所述内存回收命令；如果允许，执行所述内存回收命令。

根据本说明书实施例的第九方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现本说明书任意实施例所述应用于工作节点的分布式系统内存回收的方法的步骤。

本说明书一方面的实施例提供了应用于主节点的分布式系统内存回收的方法，由于主节点响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息，根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令，因此，主节点从全局视角出发确定需要内存回收的工作节点，主动有选择地控制工作节点进行内存回收，既能够实现主动有效地触发，又不会发生在某一时刻所有的节点都进行GC而导致的整个系统处于不可用状态的问题，提高了系统的执行效率；

本说明书另一方面的实施例提供了应用于工作节点的分布式系统内存回收的方法，由于工作节点为主节点提供针对内存回收的可用性信息，接收主节点根据可用性信息发送的内存回收命令，因此，工作节点能够受主节点从全局视角触发的对内存回收的控制，并且结合自身情况对是否允许执行内存回收命令进行判断，如果允许，再执行所述内存回收命令，从而既能够有效触发工作节点进行内存回收，又能确保主节点触发的GC不会对自身状态造成不良影响，有效提高了系统的执行效率。

附图说明

图1是本说明书一个实施例提供的应用于主节点的分布式系统内存回收的方法的流程图；

图2是本说明书一个实施例提供的应用于主节点的分布式系统内存回收的方法的处理过程流程图；

图3是本说明书一个实施例提供的配置于主节点的分布式系统内存回收的装置的结构示意图；

图4是本说明书另一个实施例提供的配置于主节点的分布式系统内存回收的装置的结构示意图；

图5是本说明书一个实施例提供的应用于工作节点的分布式系统内存回收的方法的流程图；

图6是本说明书一个实施例提供的应用于工作节点的分布式系统内存回收的方法的处理过程流程图；

图7是本说明书一个实施例提供的主节点与工作节点的通信交互示意图。

图8是本说明书一个实施例提供的配置于工作节点的分布式系统内存回收的装置的结构示意图；

图9是本说明书另一个实施例提供的配置于工作节点的分布式系统内存回收的装置的结构示意图；

图10是本说明书一个实施例提供的分布式系统的结构框图；

图11是本说明书一个实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

内存回收(GC，Garbage Collection)：一种用于在空闲时间不定时回收无任何对象引用的对象占据的内存空间的一种机制。

MPP(Massively Parallel Processing，大规模并行处理)，是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果的架构。采用MPP架构的数据库称为MPP数据库。

可用性信息，是用于描述工作节点的内存回收是否处于可用状态的信息。例如，在可用性信息为“ACTIVE”的情况下，表示可用，在可用性信息为“INACTIVE”的情况下，表示不可用。

在本说明书中，提供了分布式系统内存回收的方法，本说明书同时涉及分布式系统内存回收的装置，分布式系统，计算设备，以及计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本说明书一个实施例提供的一种分布式系统内存回收的方法的流程图。本实施例提供的方法可以应用于主节点。所述方法包括步骤102至步骤106。

步骤102：响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息。

步骤104：根据所述可用性信息，确定需要执行内存回收的工作节点。

步骤106：向需要执行内存回收的工作节点，发送内存回收命令。

由于主节点响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息，根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令，因此，主节点能够获取分布式系统全局工作节点针对内存回收的可用性信息，从全局视角出发确定需要内存回收的工作节点，主动有选择地控制工作节点进行内存回收，既能够实现主动有效地触发内存回收，又不会发生在某一时刻所有的节点都进行GC而导致的整个系统处于不可用状态的问题，提高了系统的执行效率。

需要说明的是，本说明书实施例对所述内存回收条件并不进行限制，具体可以根据实施场景的需要，设置相应的内存回收条件。例如，本说明书一个或多个实施例中，为了能够在工作节点内存水位较高时或者定期主动地进行内存回收，所述响应于满足内存回收条件可以包括：响应于工作节点的内存水位超过预设内存水位阈值，或者，响应于进入定期执行内存回收的新一轮周期。

另外，为了提高分布式系统的可用性，主节点在从全局视角出发确定需要执行内存回收的工作节点之后，还可以从全局视角出发，以保证分布式系统的服务可持续性为目标，确定节点顺序，以使各个工作节点有序地进行内存回收，保证有足够的工作节点在提供服务。具体地，例如，所述向需要执行内存回收的工作节点，发送内存回收命令包括：根据所述可用信息，确定需要执行内存回收的工作节点的节点顺序；根据所述节点顺序，发送内存回收命令。

例如，在实际实施时，可以根据节点顺序，首先向排在首位的工作节点发送内存回收命令；接收工作节点针对内存回收命令的响应；根据工作节点针对内存回收命令的响应，向下一个或多个工作节点发送内存回收命令；如果根据所述节点顺序确定还存在未被发送内存回收命令的工作节点，返回到所述接收工作节点针对内存回收命令的响应的步骤。

在工作节点接收到内存回收命令之后，为了确保主节点触发的GC不会对自身状态造成不良影响，工作节点还可以判断自身情况是否允许执行所述内存回收命令，如果允许，执行所述内存回收命令。因此，在主节点向工作节点发内存回收命令之后，主节点可以同步等待工作节点针对内存回收命令的响应，下面，结合三种可能的响应情况，对主节点的相应处理进行分析：

响应情况一：主节点收到工作节点顺利完成GC的响应。在这种情况下，主节点可以记录好收到的响应，并开始按顺序向后面的工作节点发送内存回收命令。

响应情况二：主节点收到工作节点拒绝进行GC的响应。在这种情况下，主节点可以记录好收到的响应，并放弃在这轮分布式GC中对此工作节点进行分布式GC。

响应情况三：主节点发出的内存回收命令的响应超时。在这种情况下，主节点可以选择重试或者放弃次轮对此Worker进行分布式GC。

通过上述分析可见，工作节点有可能执行内存回收命令，成功完成了内存回收，也有可能拒绝内存回收，也有可能因为网络的问题而导致没能接收到内存回收命令。为了保证主节点准确有效地对内存回收进行控制，避免反复发送内存回收命令带来的资源消耗，本说明书一个或多个实施例中，主节点还可以接收工作节点针对所述内存回收命令的响应；如果接收到的响应为拒绝，放弃对所述响应的工作节点的内存回收；如果响应超时，重试或者放弃对响应超时的工作节点的内存回收。

下述结合附图2，对结合了上述多个实施例的分布式系统内存回收的方法进行进一步说明。图2示出了本说明书一个实施例提供的一种分布式系统内存回收的方法的处理过程流程图，具体步骤包括步骤202至步骤218。

步骤202：响应于工作节点的内存水位超过预设内存水位阈值，或者，响应于进入定期执行内存回收的新一轮周期，获取分布式系统中全局工作节点的可用性信息。

例如，所述可用性信息获取的方式可以通过Worker定期向Master发起心跳报文进行汇报，也可以由Master主动向Worker发起信息收集报文。

步骤204：根据所述可用性信息，确定需要执行内存回收的N个工作节点。

步骤206：判断是否N大于零。

步骤208：如果否，睡眠等待。

步骤210：如果是，向N个工作节点中的一个或多个发送内存回收命令。

步骤212：接收工作节点针对所述内存回收命令的响应。

步骤214：针对响应超时的工作节点，重试或者放弃对响应超时的工作节点的内存回收。

步骤216：针对响应为拒绝的工作节点，放弃对所述响应的工作节点的内存回收。

步骤218：判断N个工作节点中是否还有未被发送内存回收命令的工作节点。

如果有，返回到步骤210，向未被发送内存回收命令的工作节点发送内存回收命令。

通过上述实施例可见，根据本发明实施例提供的方法，分布式系统内存回收分为主节点和工作节点两个部分。主节点根据全局的工作节点的可用性信息制定分布式GC计划，包括确定需要执行GC的工作节点以及执行顺序，向需要执行GC的工作节点发起内存回收命令。工作节点收到内存回收命令后，可以根据自己的状态选择进行GC或者拒绝执行GC，并向主节点反馈。两个部分的处理可以以线程的方式附着在对应的主节点和工作节点上，共同协作完成分布式GC逻辑。每当主节点完成一轮的分布式内存回收后，主节点上分布式GC线程进入睡眠状态，等待一段时间后开始下一轮的分布式GC。

与上述方法实施例相对应，本说明书还提供了分布式系统内存回收的装置实施例，图3示出了本说明书一个实施例提供的一种分布式内存回收的装置的结构示意图。该装置可以配置于分布式系统的主节点。如图3所示，该装置包括：信息获取模块302、节点确定模块304及命令发送模块306。

该信息获取模块302，可以被配置为响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息。

例如，该信息获取模块302，可以被配置为响应于工作节点的内存水位超过预设内存水位阈值，或者，响应于进入定期执行内存回收的新一轮周期，获取工作节点针对内存回收的可用性信息。

该节点确定模块304，可以被配置为根据所述可用性信息，确定需要执行内存回收的工作节点。

该命令发送模块306，可以被配置为向需要执行内存回收的工作节点，发送内存回收命令。

由于主节点响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息，根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令，因此，主节点能够获取分布式系统全局工作节点针对内存回收的可用性信息，从全局视角出发确定需要内存回收的工作节点，主动有选择地控制工作节点进行内存回收，既能够实现主动有效地触发内存回收，又不会发生在某一时刻所有的节点都进行GC而导致的整个系统处于不可用状态的问题，提高了系统的执行效率。

图4示出了本说明书另一个实施例提供的一种分布式内存回收的装置的结构示意图。如图4所示，该装置的命令发送模块306可以包括：顺序确定子模块3062及命令发送子模块3064。

该顺序确定子模块3062，可以被配置为根据所述可用信息，确定需要执行内存回收的工作节点的节点顺序。

该命令发送子模块3064，可以被配置为根据所述节点顺序，发送内存回收命令。

上述实施例中，为了提高分布式系统的可用性，主节点在从全局视角出发确定需要执行内存回收的工作节点之后，还可以从全局视角出发，以保证分布式系统的服务可持续性为目标，确定节点顺序，使各个工作节点有序地进行内存回收，保证有足够的工作节点在提供服务。

可以理解的是，工作节点在接收内存回收命令后，有可能执行内存回收命令，成功完成了内存回收，也有可能拒绝内存回收，也有可能因为网络的问题而导致没能接收到内存回收命令。为了保证主节点准确有效地对内存回收进行控制，避免反复发送内存回收命令带来的资源消耗，本说明书一个或多个实施例中，如图4所示，所述装置还可以包括：响应接收模块308及响应处理模块310。

该响应接收模块308，可以被配置为接收工作节点针对所述内存回收命令的响应；

该响应处理模块310，可以被配置为如果接收到的响应为拒绝，放弃对所述响应的工作节点的内存回收；如果响应超时，重试或者放弃对响应超时的工作节点的内存回收。

上述为本实施例的一种分布式系统内存回收的装置的示意性方案。需要说明的是，该分布式系统内存回收的装置的技术方案与上述的分布式系统内存回收的方法的技术方案属于同一构思，分布式系统内存回收的装置的技术方案未详细描述的细节内容，均可以参见上述分布式系统内存回收的方法的技术方案的描述。

与上述方法实施例相对应，本说明书还提供了应用于工作节点的分布式系统内存回收的方法实施例，图5示出了本说明书一个实施例提供的一种分布式内存回收的方法的流程图。如图5所示，所述方法包括步骤502至步骤508。

步骤502：为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令。

步骤504：接收主节点发送的内存回收命令。

步骤506：判断所述工作节点是否允许执行所述内存回收命令。

步骤508：如果允许，执行所述内存回收命令。

由于工作节点为主节点提供针对内存回收的可用性信息，接收主节点根据可用性信息发送的内存回收命令，因此，工作节点能够受主节点从全局视角发出的对内存回收的控制，并且结合自身情况对是否允许执行内存回收命令进行判断，如果允许，再执行所述内存回收命令，从而既能够有效触发工作节点进行内存回收，又能确保主节点触发的GC不会对自身状态造成不良影响，有效提高了系统的执行效率。

需要说明的是，本说明实施例提供的方法中，主节点发送内存回收命令触发的内存回收与工作节点上JVM的自动GC可以是完全独立，并且共同实施在同一分布式系统中的，从而可以基于两种内存回收机制对工作节点的GC时机的控制更为精细，进一步提高系统的执行效率。具体地，例如，所述方法还可以包括：在所述工作节点的JVM自动内存回收机制被触发的情况下，判断所述工作节点是否允许执行JVM自动内存回收；如果允许，执行JVM自动内存回收。

需要说明的是，本说明书实施例提供的方法对工作节点是否允许执行内存回收命令的判断条件并不进行限制，具体可以依据工作节点的自身特点以及实施环境的需要进行设置。例如，为了避免过于频繁的内存回收，或者，避免内存水位不合理的内存回收，本说明书一个或多个实施例中，所述判断所述工作节点是否允许执行所述内存回收命令可以包括：判断所述工作节点上一次内存回收的时刻与当前时刻的时间间隔是否达到允许执行内存回收的时间间隔范围；和/或者，判断所述工作节点的内存水位是否超过预设内存水位阈值。从而，在时间间隔过短，内存水位不高的情况下，工作节点可以拒绝执行内存回收命令。

例如，工作节点在可用性信息为“ACTIVE”的情况下，表示可以正常执行内存回收。工作节点在收到主节点发出的内存回收命令后，判断现在的时间点距离上一次GC完成的时间间隔是否小于预设的间隔阈值，如果小于，工作节点可以认为内存回收命令过于频繁，是不合理的，拒绝这一次内存回收命令，并向主节点进行反馈。如果大于等于预设的间隔阈值，工作节点认可此次内存回收命令，则可以开始执行GC。

可以理解的是，在主节点触发内存回收与工作节点上JVM的自动GC共同实施的场景下，工作节点的上一次GC，有可能是主节点通过内存回收命令触发的GC，也有可能是工作节点自身的JVM自动内存回收机制触发的内存回收。因此，本说明书一个或多个实施例中，所述工作节点上一次内存回收包括：响应于所述主节点或其他主节点上一次发送的内存回收命令而执行的内存回收，或者，所述工作节点上一次的JVM自动内存回收机制被触发而执行的内存回收。

为了便于主节点准确有效地对内存回收进行控制，工作节点在判断了是否执行内存回收命令之后，如果确定不允许执行，还可以向所述主节点反馈拒绝内存回收的响应消息。在所述内存回收命令执行完成的情况下，向所述主节点反馈内存回收成功完成的响应消息。通过本实施例的反馈，可以使主节点根据接收到的响应为拒绝，放弃对所述响应的工作节点的内存回收，根据接收到的响应为成功完成，从而实现更加准确地控制，避免反复发送内存回收命令带来的资源消耗。

另外，为了保证工作节点的内存回收的可持续性，以及系统服务的可持续性，本说明书一个或多个实施例中，可以在工作节点重启的情况下，将所述工作节点的可用性信息默认设置为可用；在执行内存回收命令时，将所述工作节点的可用性信息更新为不可用；在内存回收命令执行完成的情况下，将所述工作节点的可用性信息更新为可用。在该实施例中，即使工作节点在分布式GC过程中重启，由于默认是可用状态，不会对重启后的工作节点执行任务和分布式GC产生不良影响，保证了内存回收的持续可用，在内存回收命令执行完成的情况下，将工作节点的可用性信息更新为可用，同样也保证了内存回收的持续可用。另外，由于处于内存回收中的工作节点的可用性信息为不可用，所以不会被主节点再次确认为需要执行GC，从而确保主节点的精准控制，避免主节点让集群中所有工作节点全部处于内存回收的状态，确保集群服务的持续可用性。

为了避免内存回收对工作节点的正常任务带来干扰，影响到整个集群的可用性，本说明书一个或多个实施例中，工作节点在执行内存回收之前，还包括：检查所述工作节点是否存在任务未完成；如果存在，在所述工作节点的任务完成之后，进入执行内存回收的步骤；如果不存在，进入执行内存回收的步骤。

例如，工作节点可以检查自己的任务数量是否为0，如果不为0表示还有任务没有完成，则可以等待所有的任务完成再进行内存回收。等待可以通过线程进入睡眠状态一段时间后再来查看任务数是否为零，或者被最后一个任务完成的事件唤醒。

下述结合附图6，对结合了上述多个实施例的分布式系统内存回收的方法进行进一步说明。其中，图6示出了本说明书一个实施例提供的一种分布式系统内存回收的方法的处理过程流程图，具体步骤包括步骤602至步骤622。

步骤602：工作节点在启动后，为主节点提供的可用性信息默认为“ACTIVE”。

工作节点默认处于“ACTIVE”，表示可以正常执行任务。

步骤604：接收主节点发送的内存回收命令。

步骤606：判断是否所述工作节点上一次内存回收的时刻与当前时刻的时间间隔大于或等于预设时间间隔阈值，且所述工作节点的内存水位超过预设内存水位阈值。

可以理解的是，如果小于，工作节点可以认为内存回收命令过于频繁，是不合理的，可以拒绝这一次内存收回命令，并向主节点进行反馈。如果大于或等于阈值，工作节点允许此次内存回收命令，开始执行GC。

步骤608：如果是，则将可用性信息更新为“INACTIVE”。

在该步骤中，工作节点把可用性信息设置成“INACTIVE”，表示自己不再接收和执行任务。主节点的任务下发线程发现工作节点的可用性信息为“INACTIVE”，就不会继续向工作节点下发任务，所以在内存回收之前，工作节点的任务数量只减不增，以确保内存回收的成功触发。

步骤610：判断所述工作节点的任务数是否大于零。

工作节点检查自己的任务数是否为0，如果不为0表示还有任务没有完成，工作节点不期望自己GC会影响到任务的执行，进而影响到整个集群的可用性，所以可以等待所有的任务完成。例如，可以如以下步骤612睡眠一段时间后再来查看task是否完成，如果完成，则可以在以下的步骤614正式进行fullGC。

步骤612：如果是，睡眠等待直到工作节点的任务数等于零。

步骤614：如果工作节点的任务数等于零，判断所述工作节点的内存水位是否超过预设内存水位阈值。

步骤616：如果是，则将可用性信息更新为“INACTIVE”。

步骤618：执行内存回收命令。

步骤620：执行完成后，将可用性信息更新为“ACTIVE”。

在该步骤中，工作节点完成GC后，可以把自己置回ACTIVE表示自己可以向外提供服务。

步骤622：记录内存回收命令执行完成的时间，向主节点反馈成功完成的响应消息。

在该步骤中，记录GC完成的时间，可以为下一次收到GC命令的判断提供参考。

通过上述实施例可见，主节点与工作节点共同协作完成了分布式GC逻辑，对GC时机的控制更为精细，达到了高可用、高效率的效果。

可以理解的是，分布式场景下，有一些不可控因素的发生可能导致出现一些异常情况，基于上述实施例，能够对分布式场景下各种异常情况相应处理，确保分布式集群高可用性。为了使本说明书实施例提供的方法更加易于理解，下面，以图7所示的主节点与工作节点的通信交互示意图，对本说明书实施例提供的分布式内存回收的方法对解决这些异常情况发挥的作用进行示意性说明：

如图7所示，一个或多个主节点“Master”发起了多个“Worker gc doing”任务。其中，每个“Worker gc doing”任务用于发送内存回收命令给对应的工作节点“Worker”，并根据工作节点对该内存回收命令的响应结束、重试、或者放弃该任务。例如，“Worker gcdoing”根据工作节点的可用性信息处于“Active”状态，发送内存回收命令即图7所示“Gc”给工作节点。工作节点判断时间间隔和内存水位是否达到阈值要求。工作节点确认达到的情况下，将可用性信息更新为“Inactive”，并判断任务数是否等于零即判断“task＝＝0”。如果确定，判断内存水位是否达到阈值要求，如果是，则执行“Gc”即图7所示的“System.gc()”，否则拒绝执行“Gc”。在执行“Gc”成功之后，或者拒绝的情况下，将可用性信息更新为“Active”状态。

异常情况示例一：如图7所示，主节点主动发起的分布式GC和工作节点上JVM自动GC是完全独立的，可能导致重复GC。例如，可能在两种情况下发生重复GC。可能重复GC情况一：在工作节点刚收到GC命令时刚刚完成一次JVM自动GC，可能重复GC情况二：工作节点在等待task完成过程中触发了JVM自动GC。通过图6所示实施例以及图7所示通信交互示意图可见，工作节点在这两个可能导致重复GC的关键点上，查看了自己的内存水位，只有当超过阈值后才真正地进行GC，从而有效地避免了重复GC异常情况的发生。

异常情况示例二：主节点脑裂，多个主节点向工作节点发起内存回收命令。通过图6所示实施例以及图7所示通信交互示意图可见，工作节点并不会执行每一个内存回收命令，而是会比较收到内存回收命令的时间戳和上一次GC的时间间隔。例如，如果小于预设的时间间隔阈值，可以直接拒绝执行，向发起该内存回收命令发起者进行反馈。如果冗余的内存回收命令在工作节点正在执行上一内存回收命令时到达，可以直接向对应的主节点反馈正在执行内存回收的信息。

异常情况示例三：当主节点失联时，备用主节点成为新的主节点。由于原主节点发起的上一次分布式GC，使某些工作节点处于内存回收执行中。此时，新的主节点开始执行分布式GC。通过图6所示实施例以及图7所示通信交互示意图可见，由于这些工作节点的可用性信息处于“INACTIVE”状态，因此，不会被新的主节点确定为需要执行GC的工作节点。因此，本说明书实施例提供的方法能够确保不会因为主节点的更替使集群所有工作节点全部处于内存回收状态，确保集群的可用性。

异常情况示例四：工作节点失联。主节点在将收集不到失联的工作节点的可用性信息，也就不会对其进行分布式GC调度，避免了对计算资源和网络资源的浪费。

异常情况示例五：工作节点在分布式GC过程中重启。通过图6所示实施例以及图7所示通信交互示意图可见，工作节点重新启动默认是“ACTIVE”状态，不会对重启后的工作节点执行任务和分布式GC产生不良影响。

通过上述实施例可见，本说明书实施例提供的分布式系统内存回收的方法充分考虑了分布式场景下的各种异常情况，实现了完备的异常处理机制和流程，确保分布式集群在极端环境下也能确保分布式GC的正常运行，保证高可用性，进而确保整个分布式系统的高效稳定运行。

例如，本说明书实施例提供的方法可以应用于MPP架构的分布式系统，从而实现高可用、高效率的分布式MPP数据库。可以理解的是，本说明书实施例提供的方法不仅可以应用于MPP数据库场景，还可以广泛运用于其他分布式系统，在提升分布式系统执行效率和稳定性上发挥重要作用。

与上述方法实施例相对应，本说明书还提供了分布式系统内存回收的装置实施例，图8示出了本说明书一个实施例提供的一种分布式内存回收的装置的结构示意图。该装置可以配置于分布式系统的工作节点。如图8所示，该装置包括：信息提供模块802、命令接收模块804、执行判断模块806及命令执行模块808。

该信息提供模块802，可以被配置为为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令。

该命令接收模块804，可以被配置为接收主节点发送的内存回收命令。

该执行判断模块806，可以被配置为判断所述工作节点是否允许执行所述内存回收命令。

例如，所述执行判断模块806，可以被配置为判断所述工作节点上一次内存回收的时刻与当前时刻的时间间隔是否达到允许执行内存回收的时间间隔范围；和/或者，判断所述工作节点的内存水位是否超过预设内存水位阈值。

该命令执行模块808，可以被配置为如果所述执行判断模块判定为允许，执行所述内存回收命令。

由于工作节点为主节点提供针对内存回收的可用性信息，接收主节点根据可用性信息发送的内存回收命令，因此，工作节点能够受主节点从全局视角发出的对内存回收的控制，并且结合自身情况对是否允许执行内存回收命令进行判断，如果允许，再执行所述内存回收命令，从而既能够有效触发工作节点进行内存回收，又能确保主节点触发的GC不会对自身状态造成不良影响，有效提高了系统的执行效率。

图9示出了本说明书另一个实施例提供的一种分布式内存回收的装置的结构示意图。如图9所示，该装置还可以包括：自动内存回收判断模块810及自动内存回收执行模块812。

该自动内存回收判断模块810，可以被配置为在所述工作节点的JVM自动内存回收机制被触发的情况下，判断所述工作节点是否允许执行JVM自动内存回收。

该自动内存回收执行模块812，可以被配置为如果允许，执行JVM自动内存回收。

本实施例提供的装置中，主节点发送内存回收命令触发的内存回收与工作节点上JVM的自动GC是各自独立，并且共同实施在同一分布式系统中的，从而可以基于两种内存回收机制对工作节点的GC时机的控制更为精细，进一步提高系统的执行效率。

例如，所述工作节点上一次内存回收可以包括：响应于所述主节点或其他主节点上一次发送的内存回收命令而执行的内存回收，或者，所述工作节点上一次的JVM自动内存回收机制被触发而执行的内存回收。

本说明书一个或多个实施例中，如图9所示，该装置还可以包括：反馈模块814，可以被配置为如果所述执行判断模块806判定为不允许，向所述主节点反馈拒绝内存回收的响应消息，和/或，在所述内存回收命令执行完成的情况下，向所述主节点反馈内存回收成功完成的响应消息。

通过本实施例的反馈，可以使主节点根据接收到的响应为拒绝，放弃对所述响应的工作节点的内存回收，根据接收到的响应为成功完成，从而实现更加准确地控制，避免反复发送内存回收命令带来的资源消耗。

另外，为了保证工作节点的内存回收的可持续性，以及系统服务的可持续性，本说明书一个或多个实施例中还对可用性信息根据流程的变化进行了相应的更新。本说明书一个或多个实施例中，如图9所示，该装置还可以包括：信息更新模块816，可以被配置为在工作节点重启的情况下，将所述工作节点的可用性信息默认设置为可用；在执行内存回收命令时，将所述工作节点的可用性信息更新为不可用；在内存回收命令执行完成的情况下，将所述工作节点的可用性信息更新为可用。

为了避免内存回收对工作节点的正常任务带来干扰，影响到整个集群的可用性，本说明书一个或多个实施例中，如图9所示，该装置还可以包括：任务量检查模块818，可以被配置为检查所述工作节点是否存在任务未完成，如果存在，在所述工作节点的任务完成之后，允许命令执行模块808和/或自动内存回收执行模块812进入执行内存回收的步骤；如果不存在，允许命令执行模块808和/或自动内存回收执行模块812进入执行内存回收的步骤。

上述为本实施例的一种分布式系统内存回收的装置的示意性方案。需要说明的是，该分布式系统内存回收的装置的技术方案与上述的分布式系统内存回收的方法的技术方案属于同一构思，分布式系统内存回收的装置的技术方案未详细描述的细节内容，均可以参见上述分布式系统内存回收的方法的技术方案的描述。

图10示出了本说明书一个实施例提供的一种分布式系统的框图。如图10所示，所述分布式系统可以包括：一个或多个主节点1002以及与所述主节点通信的多个工作节点1004。

所述主节点1002，可以被配置为响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息；根据所述可用性信息，确定需要执行内存回收的工作节点；向需要执行内存回收的工作节点，发送内存回收命令。

所述工作节点1004，可以被配置为为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令；接收主节点发送的内存回收命令；判断所述工作节点是否允许执行所述内存回收命令；如果允许，执行所述内存回收命令。

图11示出了根据本说明书一个实施例提供的一种计算设备1100的结构框图。该计算设备1100的部件包括但不限于存储器1110和处理器1120。处理器1120与存储器1110通过总线1130相连接，数据库1150用于保存数据。

计算设备1100还包括接入设备1140，接入设备1140使得计算设备1100能够经由一个或多个网络1160通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备1140可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备1100的上述部件以及图11中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图11所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备1100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备1100还可以是移动式或静止式的服务器。

一方面，处理器1120用于执行如下计算机可执行指令：

响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息；

根据所述可用性信息，确定需要执行内存回收的工作节点；

向需要执行内存回收的工作节点，发送内存回收命令。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的应用于主节点的分布式系统内存回收的方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述应用于主节点的分布式系统内存回收的方法的技术方案的描述。

另一方面，处理器1120用于执行如下计算机可执行指令：

为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令；

接收主节点发送的内存回收命令；

判断所述工作节点是否允许执行所述内存回收命令；

如果允许，执行所述内存回收命令。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的应用于工作节点的分布式系统内存回收的方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述应用于工作节点的分布式系统内存回收的方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机指令，一方面，该指令被处理器执行时以用于：

响应于满足内存回收条件，获取所述分布式系统中的工作节点针对内存回收的可用性信息；

根据所述可用性信息，确定需要执行内存回收的工作节点；

向需要执行内存回收的工作节点，发送内存回收命令。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的应用于主节点的分布式系统内存回收的方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述应用于主节点的分布式系统内存回收的方法的技术方案的描述。

另一方面，该指令被处理器执行时以用于：

为主节点提供针对内存回收的可用性信息，以使所述主节点根据所述可用性信息，确定需要执行内存回收的工作节点，向需要执行内存回收的工作节点，发送内存回收命令；

接收主节点发送的内存回收命令；

判断所述工作节点是否允许执行所述内存回收命令；

如果允许，执行所述内存回收命令。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的应用于工作节点的分布式系统内存回收的方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述应用于工作节点的分布式系统内存回收的方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书实施例并不受所描述的动作顺序的限制，因为依据本说明书实施例，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书实施例所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书实施例的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书实施例的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。