CN108900379A - 分布式网络业务调度方法、装置、计算设备和存储介质 - Google Patents

Abstract

本申请公开了一种分布式网络业务调度方法、装置、计算设备和存储介质。基于下游节点返回的业务处理结果，判断是否处理成功。分别统计上游节点的各个下游节点的业务处理失败率。将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于第一阈值的下游节点标记为正常节点。响应于上游节点存在要向下游节点下发的业务处理请求，构建候选队列，其中，将非正常节点放入候选队列的概率低于将正常节点放入候选队列。从候选队列中选择下游节点以用于执行业务处理请求。向所选择的下游节点发送业务处理请求。以及从所选择的下游节点接收业务处理结果。由此，能够识别逻辑坏点，逻辑坏点恢复正常后也能及时发现，保障了业务处理请求的顺利执行。

Description

分布式网络业务调度方法、装置、计算设备和存储介质

技术领域

本公开涉及分布式网络，特别涉及分布式网络中节点的健康状态监控及相应的业务调度。

背景技术

分布式网络是由分布在不同地点且具有多个终端的节点机互连而成的。在分布式网络中，基于系统吞吐量和容错等因素的考虑，通常情况下上游节点会同时与多个下游节点进行链接。在上游节点处，单个请求会以一定策略(例如轮询或随机等)发送到某个下游节点上。

图1示意性地示出了分布式网络中上下游节点的链接关系。上游节点与下游节点1、下游节点2、下游节点3分别链接。

当如图1所示，当下游某个节点(例如下游节点1)出现损坏(如机器宕机)时，系统需要及时自动发现该节点损坏，并切走发送至该节点上的全部(或绝大部分)请求，以保证系统的健壮性。

一般而言，当出现下游节点损坏时，上游节点需要自动发现该坏点(损坏的节点)，并将原计划发送至该节点的流量切换至其它下游节点，以保证线上流量的正常处理。

应对可能存在的坏点，当前分布式网络一般采用请求出错重试和心跳(Heartbeat)检测两种方案来应对。请求出错重试方案和心跳检测方案从不同的角度来应对坏点，两种方案可以单独使用，也可以结合使用。

图2示意性地示出了请求出错重试方案的简易流程。

在请求出错重试方案中，上游节点在尝试请求下游节点获得失败结果(例如超时等)之后，上游节点判断剩余时间是否充足，即剩余时间是否足够重新请求其它下游节点进行处理。若时间足够，则上游节点尝试请求其它下游节点，以期完成此次请求的业务处理。

请求出错重试方案的大致处理流程如下：

1.业务处理请求到达上游节点。

2.上游节点进行处理。

3.上游节点尝试发送至下游节点1。

4.下游节点1返回处理结果，在下游节点1损坏的情况下，处理结果表明处理失败。

5.上游节点判断剩余时间是否充足。

6.在剩余时间充足的情况下，尝试发送到下游节点2进行处理。

7.下游节点运行正常没有损坏，对业务处理请求进行正常处理后，返回处理结果。

在这种方案中，在下发业务处理请求时，并没有将下游节点区分为正常节点和损坏的节点。在业务处理请求被下发到损坏的节点时，通过及时发现处理失败并转发给其它下游节点来尽力保障该业务处理请求的顺利执行。而当损坏的下游节点恢复工作时，上游节点发送至该下游节点的业务处理请求将会得到正常处理，此时下游节点自然地恢复正常工作。

然而，采用请求出错重试的方式带来的风险是在整个请求链路中，若上游节点与下游坏点连接和处理过程中产生了较大的耗时，此时上游节点将没有更多的时间去选择其它下游节点，进而导致此次请求无法得到正常处理。该种情况下，将不可避免地产生流量的丢失。

图3示意性地示出了请求出错重试方案导致流量丢失的情形。

1.业务处理请求到达上游节点。

2.上游节点进行处理。

3.上游节点尝试发送业务处理请求至下游节点1。

4.下游节点1返回处理结果，在下游节点1损坏的情况下，处理结果表明处理失败。

5.上游节点判断剩余时间是否充足，发现剩余处理时间不足以重新请求其它下游节点进行处理。

6.返回处理失败。

这种情况下，虽然还有其它下游节点2可用，但是也不能再处理该业务请求，造成了任务处理请求不能得到处理的失败处理结果。

图4示意性地示出了心跳检测方案的简易流程。

设置心跳是指在下游节点中额外开通心跳服务，上游节点通过增加额外心跳检测线程的方式对该心跳服务进行定期请求，以确认下游节点是否存活。

如果心跳检测线程发现下游节点心跳服务异常时，则认为该节点失去服务能力。在业务处理请求到来时，上游节点会自动跳过出现心跳异常的下游节点。

心跳检测方案的大致处理流程如下：

1.上游节点的心跳检测线程发现下游节点1的心跳服务异常，自动将下游节点1从候选名单中移除。

2.业务处理请求到达上游节点。

3.上游节点进行处理。

4.上游节点跳过下游节点1，直接请求心跳服务正常的下游节点2来处理该业务处理请求，并得到正常的处理结果。

如果下游节点1恢复正常，则上游心跳检测线程会发现该下游节点1的心跳服务恢复正常。于是，上游节点的心跳检测线程会自动将下游节点1放入正常发送节点的列表(候选名单列表)中，完成服务恢复。由此实现坏点恢复逻辑。

然而，心跳服务主要用于检测物理坏点，并不能体现所有可能的节点损坏情形。在一些场合下，虽然下游节点的心跳服务仍然能够正常运行，但是该下游节点已经失去实际进行业务处理的能力，例如出现逻辑坏点的情形。

这样，运用心跳手段对现有节点检测的方式，其在处理过程中存在的最大不足为无法应对出现上述例如逻辑坏点的情况。在该种情况下心跳服务端口仍然存活，但是该下游节点已经无法正常处理相关业务处理请求。

此时上游节点通过心跳服务检测仍然认为该下游节点为正常节点，但由于该下游节点已经无法处理正常的业务请求。这种情况下，会不可避免的产生流量的丢失。

图5示意性地示出了心跳检测方案导致流量丢失的情形。

1.下游节点1心跳服务正常，但是业务逻辑处理部分出现异常。

2.然而，上游节点的心跳检测服务能够正常的获得下游的心跳信息，因此仍然认为下游节点1正常。

3.业务处理请求到达上游节点。

4.上游节点进行处理。

5.上游节点尝试发送业务处理请求至下游节点1，下游节点1返回的处理结果表明处理失败。

6.上游节点发现业务处理失败，并且剩余处理时间不足以重新请求其它下游节点进行处理。

7.返回处理失败。

因此，现有技术的分布式网络仍然需要一种业务调度方案，在下游节点出现逻辑坏点的情况下，也能够保障业务处理请求的顺利执行。

发明内容

本公开要解决的一个技术问题是提供一种业务调度方案，其能够发现逻辑坏点，以便更好地保障业务处理请求的顺利执行。

根据本公开的第一方面，提供了一种用于分布式网络的业务调度方法，包括：基于下游节点针对上游节点下发的业务处理请求返回的业务处理结果，判断下游节点是否处理成功；分别统计上游节点的各个下游节点的业务处理失败率；将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于第一阈值的下游节点标记为正常节点；响应于上游节点存在要向下游节点下发的业务处理请求，构建候选队列，其中，将非正常节点放入候选队列的概率低于将正常节点放入候选队列；从候选队列中选择下游节点以用于执行业务处理请求；向所选择的下游节点发送业务处理请求；以及从所选择的下游节点接收业务处理结果。

由此，能够识别逻辑坏点，逻辑坏点恢复正常后也能及时发现，保障了业务处理请求的顺利执行。

可选地，该业务调度方法还可以包括：响应于判定下游节点处理失败，判断任务请求的剩余处理时间是否足够重新请求其它下游节点处理该项任务请求，并在剩余处理时间足够的情况下，选择另一个下游节点以执行业务处理请求。

这样，特别是以探针概率将非正常节点放入候选队列以试探其是否已恢复正常的情况下，如果该节点依然不能正常工作，则可以重选请求其它下游节点处理该任务请求，尽量避免因探针概率试探而导致业务处理请求失败。

可选地，分别统计上游节点的各个下游节点的业务处理失败率的步骤可以包括：针对各个下游节点分别维护第一计数器和第二计数器，第一计数器用于累计对应下游节点处理成功的次数，第二计数器用于累计对应下游节点处理失败的次数；基于各个下游节点分别对应的第一计数器的第一计数值和第二计数器的第二计数值，分别统计该下游节点的失败率。

由此，保证了下游节点在整个计数统计过程中的读写无锁化，降低了整个检测过程中对系统带来的性能损耗。

可选地，分别统计上游节点的各个下游节点的业务处理失败率的步骤还可以包括：响应于预定时间期间期满，对于各个下游节点分别判断其所对应的第一计数值和第二计数值之和是否低于第二阈值；响应于和低于第二阈值，由该下游节点对应的第一计数器和第二计数器继续进行计数，直到下一个预定时间期间期满；以及响应于和不低于第二阈值，基于第一计数值和第二计数值统计该下游节点的失败率，清空第一计数器和第二计数器，以便重新开始进行下一个预定时间期间的计数。

这样，可以避免因统计数量不足而导致的判断误伤以及进而引发的流量抖动。

可选地，该业务调度方法可以由上游节点执行，上游节点可以维护节点状态监控服务，可以在节点状态监控服务的启动初始阶段为各个下游节点分别创建第一计数器和第二计数器。

这样，可以进一步保证上游节点在计算各下游节点失败率的过程中的统计无锁化。

可选地，构建候选队列的步骤还可以包括：基于预定策略，选择要放入候选队列的正常节点。

根据本公开的第二方面，提供了一种用于分布式网络的业务调度装置，包括：结果判断装置，用于基于下游节点针对上游节点下发的业务处理请求返回的业务处理结果，判断下游节点是否处理成功；失败率统计装置，用于分别统计上游节点的各个下游节点的业务处理失败率；状态标记装置，用于将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于第一阈值的下游节点标记为正常节点；队列构建装置，用于响应于上游节点存在要向下游节点下发的业务处理请求，构建候选队列，其中，将非正常节点放入候选队列的概率低于将正常节点放入候选队列；节点选择装置，用于从候选队列中选择下游节点以用于执行业务处理请求；请求下发装置，用于向所选择的下游节点发送业务处理请求；以及结果接收装置，用于从所选择的下游节点接收业务处理结果。

可选地，该业务调度装置还可以包括：节点重选装置，用于响应于判定下游节点处理失败，判断任务请求的剩余处理时间是否足以完成该项任务请求，并在剩余处理时间足够的情况下，选择另一个下游节点以执行业务处理请求。

根据本公开的第三方面，提供了一种计算设备，包括：处理器；以及存储器，其上存储有可执行代码，当可执行代码被处理器执行时，使处理器执行上述第一方面的业务调度方法。

根据本公开的第四方面，提供了一种非暂时性机器可读存储介质，其上存储有可执行代码，当可执行代码被电子设备的处理器执行时，使处理器执行上述第一方面的业务调度方法。

通过使用根据本公开的技术方案，在下游节点出现逻辑坏点的情况下，也能够识别逻辑坏点，并保障业务处理请求的顺利执行。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示意性地示出了分布式网络中上下游节点的链接关系。

图2示意性地示出了请求出错重试方案的简易流程。

图3示意性地示出了请求出错重试方案导致流量丢失的情形。

图4示意性地示出了心跳检测方案的简易流程。

图5示意性地示出了心跳检测方案导致流量丢失的情形。

图6示意性地示出了本公开的技术方案构思。

图7是可以用来实施根据本公开的业务调度方法的业务调度装置的示意性框图。

图8是根据本公开的业务调度方法的示意性流程图。

图9是根据一个实施例统计节点的失败率的步骤的示意性流程图。

图10示出了根据本发明一实施例可用于实现本公开的业务调度方法的计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

【术语解释】

网络拓扑：指用传输介质将各种设备互连的物理布局。

上游节点：点对点网络通信中，当前请求的发起方。

下游节点：点对点网络通信中，当前请求的接收方。

物理坏点：完全宕机(或类似故障)的工作节点。

逻辑坏点：虽未出现宕机，但是不能提供正常业务支撑的工作节点。

坏点检测：针对分布式系统网络拓扑中，上游节点发现下游节点工作异常的方法。

流量反馈：通过对请求的处理结果进行统计，预估下游节点出现损坏的概率。

【方案概述】

本公开在现有的请求出错重试方案和心跳检测方案之外，添加一层基于流量反馈的逻辑坏点检测策略，以期达到对当前逻辑坏点也能进行正常发现的作用。

本公开利用流量反馈的策略自动检测逻辑坏点，其主要应对场景为某些特定情况下下游节点的心跳服务正常但却不能正常处理业务逻辑的场景。

在该场景下，现有的心跳服务无法对当前下游坏点进行标记，而请求重试机制可能会由于请求下游节点耗时较长而导致请求失败。而本公开会完成对该类坏点的自动检测。

另外，在进一步的优选实施例中，概率探针的设计使该节点能够在恢复功能后被自动发现。基于双计数器的设计方式保证了该节点在整个计数统计过程中的读写无锁化，降低了整个检测过程中对系统带来的性能损耗。

图6示意性地示出了本公开的技术方案构思。

1.上游节点分别对下游节点1和2发送请求，下游节点返回处理结果，上报该下游节点是否正常处理了该请求，对每次请求的处理成功与否进行记录和统计。

2.上游节点额外开启服务，每隔一段时间对当前下游节点的请求失败率进行统计，以定期评估下游节点的坏点情况。

3.当发现某个下游节点失败率超过一定阈值时将该下游节点标记为下游坏点，自动从备选发送列表中降低其发送概率，仅保留少量流量作为探针用于测试下游节点是否存活。

该方案的坏点恢复逻辑如下：当下游节点恢复工作后，由于其存在探针流量，该部分流量将会测试到下游节点已经恢复，此时将其从备选发送列表中的概率恢复至正常，此时整个系统恢复至正常状态。

通过本公开的技术方案，能够发现逻辑坏点，从而能够更好地保障业务处理请求的顺利执行。

下面结合图7至图9来详细描述根据本公开的业务调度方法和装置。

图7是可以用来实施根据本公开的业务调度方法的业务调度装置的示意性框图。

图8是根据本公开的业务调度方法的示意性流程图。

如图7所示，该业务调度装置10可以包括结果判断装置100、失败率统计装置200、状态标记装置300、队列构建装置400、节点选择装置500、请求下发装置600、结果接收装置700。另外，业务调度装置10还可以包括节点重选装置(图中未示出)。

一般地，该业务调度方法可以由上游节点执行。换言之，上述业务调度装置10可以部署在上游节点。

上游节点可以额外启动一个独立服务，例如可以称为“节点状态监控服务”，以执行结果判断、失败率统计、状态标记等处理。

响应于上游节点下发的业务处理请求，下游节点对其进行处理后，不论处理成功还是处理失败，会向上游节点发送业务处理结果。业务处理结果中可以包含本次业务处理是否成功的信息。

如图8所示，在步骤S100，例如可以通过上述结果判断装置100，基于下游节点针对上游节点下发的业务处理请求返回的业务处理结果，判断下游节点是否处理成功。

在步骤S200，例如可以通过上述失败率统计装置200，分别统计上游节点的各个下游节点的业务处理失败率。由此，可以分别得到各个下游节点的业务处理失败率。

可以针对各个下游节点分别维护第一计数器和第二计数器。第一计数器用于累计对应下游节点处理成功的次数，也可以称为“成功计数器”。第二计数器用于累计对应下游节点处理失败的次数，也可以称为“失败计数器”。

这样，对于每个下游节点分别采用两个计数器，分别对各个下游节点各自的成功次数和失败次数进行统计。通过采用了双节点计数器的方式，可以实现在多线程并发的情况下的无锁化计数统计。

例如，可以由上述节点状态监控服务来维护第一计数器和第二计数器。可以在上述节点状态监控服务的启动初始阶段，为各个下游节点分别创建第一计数器和第二计数器。

计数器可以设置为仅在节点状态监控服务启动初始阶段进行创建。这样，可以进一步保证当前上游节点在计算各下游节点失败率的过程中的统计无锁化。

如果在上述步骤S100中判定本次下游节点处理成功，则该下游节点对应的第一计数器(成功计数器)加1。相应地，如果在上述步骤S100中判定本次下游节点处理失败，则该下游节点对应的第二计数器(失败计数器)加1。由此，通过分别为各下游节点创建的两个计数器，对业务处理成功次数和失败次数分别予以累计。

这样，就可以基于各个下游节点分别对应的第一计数器的第一计数值和第二计数器的第二计数值，分别统计该下游节点的失败率。

图9是根据本公开一个实施例统计节点的失败率的步骤的示意性流程图。

如上所述，失败率统计过程可以由节点状态监控服务来执行。

节点状态监控服务可以以预定时间期间为周期，周期性执行失败率统计过程。在每个周期中，第一计数器和第二计数器持续计数，而节点状态监控服务可以先休眠预定时间期间。

响应于在步骤S210判定预定时间期间期满，休眠结束，开始执行各个下游节点的失败率统计工作。

在步骤S220，依次读取一个下游节点对应的第二计数器(失败计数器)的第二计数值和第一计数器(成功计数器)的第一计数值。

优选地，两个计数器的读取顺序设为先读取失败计数器，再读取成功计数器。这样，可以防止统计失败率时产生节点误伤情况。

具体说来，如果在读取成功计数器之后，读取失败计数器之前，发生业务处理失败的情形，将额外增加失败计数器的第二计数值，而没有对这段时间内业务处理成功的情形进行计数。这样，有可能不适当地增大失败率的统计值，产生节点误伤。

计算第一计数值和第二计数值的和，得到当前正在考虑的下游节点在该预定时间期间中反馈的业务处理请求的总和，即反馈的总请求数。在步骤S230，判断总请求数是否达到第二阈值。第二阈值可以是根据经验人为设定的阈值。

这里，加入阈值判断的目的是为了防止在出现业务处理失败的情况下，由于该下游节点处理的业务处理请求统计数量不足而导致的判断误伤，进而引发的流量抖动。特别地，本公开中采用的这种前置阈值判断逻辑，可以保证当前失败节点在恢复过程中可能产生的流量抖动情况。

例如，在上述预定时间期间内，针对某个下游节点，只发出了少量几次业务处理请求，其中部分业务处理请求因偶然因素而处理失败。由于这段时间内的业务处理总量较小，这种偶然产生的处理失败情形将导致较大的失败率，从而有可能将该下游节点误认为坏点。

这样，对于总请求数达到第二阈值的下游节点则进入步骤S240，以进行后续操作。

而对于总请求数低于第二阈值的下游节点则跳过，不进行后续操作，直接进入步骤S260。该下游节点对应的第一计数器和第二计数器可以继续进行计数，直到下一个预定时间期间期满。

在步骤S240，基于第一计数值和第二计数值计算当前下游节点的失败率。具体说来，例如可以按下述公式计算失败率，

返回图8，在步骤S300，在计算得到失败率之后，例如可以通过上述状态标记装置300，将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于第一阈值的下游节点标记为正常节点。

换言之，如果在步骤S240计算得到当前下游节点的失败率不低于第一阈值，则将其标记为非正常节点。如果在步骤S240计算得到当前下游节点的失败率低于第一阈值，则将其标记为正常节点。

更进一步地，还可以将根据上述方案识别的非正常节点标记为逻辑坏点(逻辑非正常节点)，或者将其状态标记为“逻辑失败”，以便与通过心跳检测而发现的物理坏点或物理失败相区别。

可以例如通过状态标记位或状态码来对各个下游节点的当前状态进行标记。当原本正常的节点被当前判定为非正常节点时，或者原本不正常的节点被当前判定为正常节点时，状态标记位或状态码翻转。如果状态没有发生变化，则状态标记位或状态码维持不变。

返回图9，在步骤S250，清空该下游节点的第一计数器和第二计数器，以便重新开始进行下一个预定时间期间的计数。

优选地，先清空第二计数器(失败计数器)，再清空第一计数器(成功计数器)。

到此，对当前下游节点的失败率统计过程结束。

在步骤S260，判断是否还存在尚未统计失败率的下游节点。

如果判定还存在尚未统计的下游节点，则返回上述步骤S220，读取下一个下游节点的计数器以对下一个下游节点的失败率进行统计。

如果判定没有尚未统计的下游节点，则本次失败率统计循环结束，进入步骤S270，进入下一个预定时间期间，例如对计时器清零，重新开始计时。节点状态监控服务可以开始再次休眠，直到在步骤S210判定预定时间期间再次期满。

上面参考图8的步骤S100、S200、S300和图9，详细描述了本公开的非正常节点(坏点)识别方案。下面继续参考图8，描述在上述节点状态识别的基础上，对业务处理请求的调度方案。

返回图8，在步骤S400，例如可以通过上述队列构建装置400，响应于上游节点存在要向下游节点下发的业务处理请求，构建候选队列，其中，将非正常节点放入候选队列的概率低于将正常节点放入候选队列。

这里，可以将所有正常节点都放入候选队列，也可以基于预定策略来选择要放入候选队列的正常节点。选择要放入候选队列的正常节点的方案可以是现有的节点选择方案，在此不再赘述。

作为示例，可以按如下流程构建候选队列。

首先，对当前所有下游节点进行遍历，以判断节点状态。

如果下游节点为正常节点，则直接将该节点加入到候选队列。

如果下游节点为逻辑坏点(按上文描述的基于统计失败率识别的非正常节点)，则以一定概率值将该节点加入到候选队列，该步骤即为概率探针逻辑。

如果下游节点为物理坏点(即心跳请求无法正常响应)，则直接跳过该节点。这里，上游节点可以通过维护心跳检测服务，定期检查下游节点的心跳信号，以便发现物理坏点。

在步骤S500，例如可以通过上述节点选择装置500，从候选队列中选择下游节点以用于执行业务处理请求。

例如，可以随机地从候选队列中选择下游节点。例如可以将候选队列的节点进行随机排序，然后选取队列中第一个节点为发送请求目的节点。

在步骤S600，例如可以通过上述请求下发装置600，向所选择的下游节点发送业务处理请求。

在步骤S700，例如可以通过上述结果接收装置700，从所选择的下游节点接收业务处理结果。

所接收到的业务处理结果，一方面是业务处理请求的响应，反馈处理的结果，另一方面，还可以进一步返回步骤S100来判断该下游节点本次业务处理是否成功，并相应地进行计数，以在下一次预定时间期间期满时统计该节点的失败率。

如果判定下游节点本次处理成功，则可以直接使用该业务处理结果。

另一方面，例如可以通过上述图中未示出的节点重选装置，响应于判定下游节点本次处理失败，判断任务请求的剩余处理时间是否足够重新请求其它下游节点处理该项任务请求，并在剩余处理时间足够的情况下，选择另一个下游节点以执行业务处理请求。另外，在业务处理没有时间要求的情况下，也可以直接选择下一个下游节点以执行该业务处理请求。

采用以上逻辑实现后，下游节点出现逻辑损坏后，仍然有一定概率被添加至候选队列并成功向其发送请求，该请求的处理结果会被记录到统计计数器中用于评估该节点是否为逻辑坏点。基于该实现方式，当逻辑坏点被修复后，其发送至该节点的请求将会被正常处理，此时该节点的成功计数器会一直累加，进而导致其失败率低于阈值；后台服务发现该节点失败率低于阈值后，会自动将其标记为正常节点，该节点此时恢复正常。

至此已参考图6至图9详细描述了根据本公开的业务调度方案。

通过本公开的技术方案，基于流量反馈机制，能够及时发现逻辑坏点，从而能够更好地保障业务处理请求的顺利执行。

基于概率探针的方式，能够实现坏点恢复功能。

在优选实施例中，通过采用对每个下游节点维护两个计数器来分别对成功次数和失败次数进行计数的双计数器逻辑，实现无锁化统计策略，即，使得上游节点在并发情况下也能实现无锁化。

在另一个优选实施例中，通过判断预定时间期间内总计数值是否足够多，实现了坏点发现及恢复过程中的防抖动设计。

图10示出了根据本发明一实施例可用于实现上述业务调度方法的计算设备的结构示意图。

参见图10，计算设备1000包括存储器1010和处理器1020。

处理器1020可以是一个多核的处理器，也可以包含多个处理器。在一些实施例中，处理器1020可以包含一个通用的主处理器以及一个或多个特殊的协处理器，例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中，处理器1020可以使用定制的电路实现，例如特定用途集成电路(ASIC，Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA，Field Programmable Gate Arrays)。

存储器1010可以包括各种类型的存储单元，例如系统内存、只读存储器(ROM)，和永久存储装置。其中，ROM可以存储处理器1020或者计算机的其它模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中，永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中，永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备，例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外，存储器1010可以包括任意计算机可读存储媒介的组合，包括各种类型的半导体存储芯片(DRAM，SRAM，SDRAM，闪存，可编程只读存储器)，磁盘和/或光盘也可以采用。在一些实施方式中，存储器1010可以包括可读和/或写的可移除的存储设备，例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM，双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。

存储器1010上存储有可执行代码，当可执行代码被处理器1020处理时，可以使处理器1020执行上文述及的业务调度方法。

上文中已经参考附图详细描述了根据本发明的业务调度方法、装置和计算设备。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (10)

1.一种用于分布式网络的业务调度方法，包括：

基于下游节点针对上游节点下发的业务处理请求返回的业务处理结果，判断下游节点是否处理成功；

分别统计所述上游节点的各个下游节点的业务处理失败率；

将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于所述第一阈值的下游节点标记为正常节点；

响应于所述上游节点存在要向所述下游节点下发的业务处理请求，构建候选队列，其中，将所述非正常节点放入所述候选队列的概率低于将所述正常节点放入所述候选队列；

从所述候选队列中选择下游节点以用于执行所述业务处理请求；

向所选择的下游节点发送所述业务处理请求；以及

从所选择的下游节点接收业务处理结果。

2.根据权利要求1所述的业务调度方法，还包括：

响应于判定下游节点处理失败，判断所述任务请求的剩余处理时间是否足够重新请求其它下游节点处理该项任务请求，并在所述剩余处理时间足够的情况下，选择另一个下游节点以执行所述业务处理请求。

3.根据权利要求1所述的业务调度方法，其中，所述分别统计所述上游节点的各个下游节点的业务处理失败率的步骤包括：

针对各个下游节点分别维护第一计数器和第二计数器，所述第一计数器用于累计对应下游节点处理成功的次数，所述第二计数器用于累计对应下游节点处理失败的次数；

基于各个下游节点分别对应的所述第一计数器的第一计数值和所述第二计数器的第二计数值，分别统计该下游节点的失败率。

4.根据权利要求3所述的业务调度方法，其中，所述分别统计所述上游节点的各个下游节点的业务处理失败率的步骤还包括：

响应于预定时间期间期满，对于各个下游节点分别判断其所对应的所述第一计数值和所述第二计数值之和是否低于第二阈值；

响应于所述和低于所述第二阈值，由该下游节点对应的所述第一计数器和所述第二计数器继续进行计数，直到下一个预定时间期间期满；以及

响应于所述和不低于所述第二阈值，基于所述第一计数值和所述第二计数值统计该下游节点的失败率，清空所述第一计数器和所述第二计数器，以便重新开始进行下一个预定时间期间的计数。

5.根据权利要求3所述的业务调度方法，其中，该业务调度方法由所述上游节点执行，所述上游节点维护节点状态监控服务，

在所述节点状态监控服务的启动初始阶段为各个下游节点分别创建所述第一计数器和所述第二计数器。

6.根据权利要求1所述的业务调度方法，其中，所述构建候选队列的步骤还包括：

基于预定策略，选择要放入所述候选队列的正常节点。

7.一种用于分布式网络的业务调度装置，包括：

结果判断装置，用于基于下游节点针对上游节点下发的业务处理请求返回的业务处理结果，判断下游节点是否处理成功；

失败率统计装置，用于分别统计所述上游节点的各个下游节点的业务处理失败率；

状态标记装置，用于将失败率不低于第一阈值的下游节点标记为非正常节点，将失败率低于所述第一阈值的下游节点标记为正常节点；

队列构建装置，用于响应于所述上游节点存在要向所述下游节点下发的业务处理请求，构建候选队列，其中，将所述非正常节点放入所述候选队列的概率低于将所述正常节点放入所述候选队列；

节点选择装置，用于从所述候选队列中选择下游节点以用于执行所述业务处理请求；

请求下发装置，用于向所选择的下游节点发送所述业务处理请求；以及

结果接收装置，用于从所选择的下游节点接收业务处理结果。

8.根据权利要求7所述的业务调度装置，还包括：

节点重选装置，用于响应于判定下游节点处理失败，判断所述任务请求的剩余处理时间是否足以完成该项任务请求，并在所述剩余处理时间足够的情况下，选择另一个下游节点以执行所述业务处理请求。

9.一种计算设备，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被所述处理器执行时，使所述处理器执行如权利要求1-6中任何一项所述的方法。

10.一种非暂时性机器可读存储介质，其上存储有可执行代码，当所述可执行代码被电子设备的处理器执行时，使所述处理器执行如权利要求1至6中任一项所述的方法。