CN112527511A - 一种负载处理方法及服务系统 - Google Patents

Abstract

本发明公开了一种负载处理方法及服务系统，服务系统中的每个所述节点均可接收服务请求，每个所述节点均可将服务请求分配给其他节点进行处理。本发明每个节点均可对接收到的服务请求判断是否进行分配，若需要进行分配，则可将服务请求分配给其他节点，减少了主节点选举，也避免了服务请求在单一节点堆积的问题。

Description

一种负载处理方法及服务系统

技术领域

本发明属于负载分配技术领域，尤其涉及一种负载处理方法及服务系统。

背景技术

分布式系统中的无状态负载指的是对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到(比如说数据库)，节点本身不存储任何信息。服务不保存状态，需要的时候从同一的节点中获取，保证了服务在任何时刻的状态一致。在分布式系统的负载均衡中，不会涉及到数据丢失，所以目前被广泛的应用。

目前分布式系统的无状态负载过程中，主要以主节点进行负载分配实现负载均衡，当主节点失效后，重新进行选举，选出新的主节点进行负载分配。这种方式不可避免的导致服务请求容易在主节点处堆积，且负载分配速度慢。

发明内容

本发明所要解决的技术问题在于针对上述现有技术中的不足，提供一种负载处理方法及服务系统，每个节点均可对接收到的服务请求判断是否进行分配，若需要进行分配，则可将服务请求分配给其他节点，减少了主节点选举，也避免了服务请求在单一节点堆积的问题。

本发明第一方面公开了一种负载处理方法，包括以下步骤：

节点接收服务请求，并将所述服务请求分配给其他节点进行处理；

其中，每个所述节点均可接收服务请求，每个所述节点均可将服务请求分配给其他节点进行处理。

进一步地，所述节点在接收到服务请求后，判断自身是否对所述服务请求有处理能力，若是，则对所述服务请求进行处理；若否，则将所述服务请求分配给其他节点进行处理。

进一步地，所述判断自身是否对所述服务请求有处理能力之前，还包括：

步骤1、所述当前节点判断服务请求是否在其他节点的负载信息列表中，所述负载信息列表记录节点需处理的服务请求的信息；若是，进入下一步；若否，判断自身是否对所述服务请求有处理能力；

步骤2、所述当前节点判断接收到的服务请求在其他节点的负载信息列表中记录的时间是否早于在当前节点的负载信息列表中记录的时间；若是，则对所述服务请求不做处理；若否，判断自身是否对所述服务请求有处理能力。

进一步地，所述判断自身是否对该服务请求有处理能力，包括：

查询当前节点的负载信息列表中待处理的服务请求全部处理完成所需的时间T1；

预估当前服务请求处理完成所需时间T2；

判断T1+T2＜T3是否成立，当前服务请求需在T3时间段内处理完成；若是，则当前节点该服务请求有处理能力，若否，则当前节点该服务请求无处理能力。

进一步地，所述将所述服务请求分配给其他节点进行处理，包括：

根据其他节点的负载信息列表，指定至少一个对所述服务请求有处理能力的其他节点对所述服务请求进行处理。

进一步地，所述指定至少一个对所述服务请求有处理能力的其他节点对所述服务请求进行处理，包括:

建立所述服务请求和指定的处理节点之间的链接信息；

将链接信息发送至其他节点。

进一步地，每个所述节点在接收到服务请求时，将所述服务请求的标识与收到服务请求的时间更新至负载信息列表中。

进一步地，当所述服务请求由当前节点处理时，在当前节点的负载信息列表中针对所述服务请求的标识标记自身节点标识。

进一步地，当所述服务请求由其他节点处理时，在当前节点的负载信息列表中删除所述服务请求的标识与收到所述服务请求的时间。

本发明第二方面公开了一种服务系统，包括多个节点，每个节点上均设置有请求接收模块、负载分配模块、判断模块和负载信息获取模块；

所述请求接收模块，用于接收服务请求；

所述负载分配模块，用于将接收到服务请求分配给其他节点进行处理。

所述判断模块用于在接收到服务请求后，判断节点是否对该服务请求有处理能力，若是，则对该服务请求进行处理；若否，则将该服务请求分配给其他节点进行处理。

所述负载信息获取模块用于获取其他节点当前的负载信息列表；

所述判断模块判断节点是否对所述服务请求有处理能力之前，还包括：

步骤1、所述判断模块判断服务请求是否在其他节点的负载信息列表中，所述负载信息列表记录节点需处理的服务请求的信息；若是，进入下一步；若否，判断自身节点是否对所述服务请求有处理能力；

步骤2、所述判断模块判断接收到的服务请求在其他节点的负载信息列表中记录的时间是否早于在当前节点的负载信息列表中记录的时间；若是，则自身节点对所述服务请求不做处理；若否，判断自身节点是否对所述服务请求有处理能力。

进一步地，判断模块判断节点是否对该服务请求有处理能力时，包括以下步骤：

查询当前节点的负载信息列表中待处理的服务请求全部处理完成所需的时间T1；

预估当前服务请求处理完成所需时间T2；

判断T1+T2＜T3是否成立，当前服务请求需在T3时间段内处理完成；若是，则当前节点该服务请求有处理能力，若否，则当前节点该服务请求无处理能力。

进一步地，所述负载分配模块将接收到服务请求分配给其他节点进行处理时包括以下步骤：

建立当前服务请求和指定的处理节点之间的链接信息；

将链接信息发送至其他节点。

进一步地，每个所述节点在接收到服务请求时，将所述服务请求的标识与收到服务请求的时间更新至负载信息列表中。

进一步地，当所述服务请求由其他节点处理时，在当前节点的负载信息列表中删除所述服务请求的标识与收到所述服务请求的时间。

本发明与现有技术相比具有以下优点：本发明通过每个节点配置为均可接收服务请求的功能，使服务请求不会在一个节点形成堆积，另外，每个节点均可将服务请求分配给其他节点，从而不需要选举主节点进行负载分配，增强了负载分配效率，提高了对服务请求的响应速度。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为本发明实施例1的方法流程图。

图2为本发明实施例2的客服系统的示意图。

图3为本发明实施例2的方法流程图。

图4为本发明实施例3的系统架构图。

具体实施方式

实施例1

如图1所示，一种负载处理方法，应用在多节点服务中，具体地，每个节点在接收到服务请求后，执行以下步骤：

步骤1、当前节点判断服务请求是否在其他节点的负载信息列表中；若是，进入步骤2；若否，进入步骤3；

具体地，通过当前节点向其他节点发送负载信息获取请求，获取其他节点负载信息列表；所述负载信息列表记录节点需处理的服务请求的信息；

步骤2、所述当前节点判断接收到的服务请求在其他节点的负载信息列表中记录的时间是否早于在当前节点的负载信息列表中记录的时间；若是，则对所述服务请求不做处理；若否，进入步骤3；

步骤3、所述当前节点判断自身是否对所述服务请求有处理能力，若是，则对所述服务请求进行处理；若否，则将所述服务请求分配给其他节点进行处理。

需要说明的是，每个节点均能接收服务请求，避免了服务请求在一个节点处集中，增强了负载分配效率，提高了对服务请求的响应速度。

通过上述步骤1和步骤2的执行，可以及时发现重复的服务请求，避免节点对服务请求重复处理和重复分配，保证一个服务请求只会被一个节点处理或进行分配。

通过上述步骤3的执行，每个节点在接收到服务请求后，首先对自身进行判断，若可以，则不必进行服务请求分配，在一定程度上减少了执行服务请求分配给其他节点的动作次数，可以更加高效的对服务请求进行响应。

步骤3中所述当前节点判断自身是否对所述服务请求有处理能力时包括以下步骤：

步骤3-1、查询当前节点的负载信息列表中待处理的服务请求全部处理完成所需的时间T1；

步骤3-2、预估当前服务请求处理完成所需时间T2；

步骤3-3、判断T1+T2＜T3是否成立，当前服务请求需在T3时间段内处理完成；若是，则当前节点该服务请求有处理能力，若否，则当前节点该服务请求无处理能力。

通过以服务请求处理完成所需时间T3来判断节点的处理能力，能够保证服务请求的处理结果返回时间达到设计要求，实际上可使对用户的响应时间达到要求，提高用户体验。

本实施例中，步骤3中将所述服务请求分配给其他节点进行处理，通过根据其他节点的负载信息列表，指定至少一个对所述服务请求有处理能力的其他节点对所述服务请求进行处理。具体地，指定节点是通过建立所述服务请求和指定的处理节点之间的链接信息；然后将链接信息发送至其他节点实现。

具体的，建立链接关系是通过将当前服务请求的标识和指定的处理节点的标识进行绑定实现，服务请求的标识为服务请求的的识别ID，节点的标识为节点的识别ID。通过将链接信息直接发送给其他节点，使其他节点能够及时获知该服务请求已被分配，避免任一节点在后续接收该服务请求时重复拉取其他节点的负载信息列表，也使被分配处理该服务请求的节点及时将该服务请求加入处理队列中。

本实施例中，每个所述节点在接收到服务请求时，将所述服务请求的标识与收到服务请求的时间更新至负载信息列表中，当该服务请求为自身处理时，在负载信息列表中针对该服务请求的标识标记自身节点标识。

通过将收到服务请求的时间更新至负载信息列表中，方便节点之间在拉取负载信息列表后，对同一服务请求判断是哪个节点进行处理或分配操作。另外，通过节点对于自身处理的服务请求标记上自身节点标识，可在负载信息列表被其他节点拉取时，快速定位到未分配节点处理的服务请求，减少节点对其他节点的负载信息列表的读取时间，提升负载信息列表的读取速度。节点标识可以是节点的识别ID。

本实施例中，当所述服务请求由其他节点处理时，在当前节点的负载信息列表中删除所述服务请求的标识与收到所述服务请求的时间。

因服务请求在最初写入节点的负载信息列表中时，并不能确定该服务请求是否是该节点自身进行处理，一些服务请求最终会分配给其他节点处理，为了不占用过多的缓存，将服务请求分配给其他节点后，及时的将服务请求删除，减少负载信息列表的文件大小，减少缓存占用，也有利于负载信息列表被其他节点调取时，及时定位到未被分配节点处理的服务请求。

实施例2

下面以将本发明所述的负载处理方法应用到客服系统中为例，对本发明的负载处理方法做进一步的说明。

如图2和图3所示，一种客服系统，包括服务端和用户端，服务端包括以分布式架构的方式布设的多个服务节点，每个节点均可接收服务端发送的服务请求，服务请求例如客服人员发起的信息查询请求、数据计算请求等等。

所述客服系统的服务端在运行时执行以下的步骤：

步骤1、接收用户端发送的服务请求；

步骤2、对多个用于服务的节点进行负载轮询，根据轮询结果，将用户服务请求分配给其中一个用于服务的节点；例如，客服在服务客户的过程中，客服打开客服系统的页面发起服务请求，客服系统对系统中可进行服务的多个节点进行负载轮询，根据轮询结果对该客服人员的服务请求分配一个节点接收该服务请求；

步骤3、节点在接收到服务请求时，向其他节点发送负载信息获取请求，获取其他节点当前的负载信息列表；

步骤4、当前节点判断接收到的服务请求是否在其他节点的负载信息列表中，所述负载信息列表为记录节点需处理的服务请求的列表；若是，进入步骤5；若否，进入步骤6；

步骤5、判断接收到的服务请求在其他节点的负载信息列表中记录的时间是否早于在当前节点的负载信息列表中记录的时间；若是，则对该服务请求不做处理；若否，则进入步骤6；

步骤6、当前节点判断自身是否对该服务请求有处理能力；若是，则当前节点对该服务请求进行处理；若否，则根据其他节点的负载信息列表，指定至少一个对该服务请求有处理能力的其他节点对该服务请求进行处理。

步骤6中节点在接收到服务请求后，首先对自身进行判断，若可以，则不必进行服务请求分配，在一定程度上减少了执行服务请求分配给其他节点的动作次数，可以更加高效的对服务请求进行响应。

通过步骤3、步骤4、步骤5的执行，可以及时发现重复的服务请求，避免节点对服务请求重复处理和重复分配，保证一个服务请求只会被一个节点处理或进行分配。

当前节点判断自身是否对该服务请求有处理能力时，包括以下步骤：

步骤6-1、查询当前负载信息列表中待处理的服务请求全部处理完成所需的时间T1；

步骤6-2、预估当前服务请求处理完成所需时间T2；

步骤6-3、判断T1+T2＜T3是否成立，当前服务请求需在T3时间段内处理完成；若是，则当前节点该服务请求有处理能力，若否，则当前节点该服务请求无处理能力。

通过以服务请求处理完成所需时间T3来判断节点的处理能力，能够保证服务请求的处理结果返回时间达到设计要求，实际上可使对用户的响应时间达到要求，提高用户体验。例如在对客服的客服系统中，客服打开客服系统页面发起服务请求，必须要在1s内给客服人员返回结果才能对客服提供帮助。则节点判断不能1s内返回结果时，应及时指定可在1s内返回结果的节点进行处理。本实施例中对当前服务请求进行处理，例如节点对客服和客户电话交互信息进行处理，处理得到可辅助客服人员对客户问题进行及时解答的辅助信息，以便客服人员能够对客户提供满意的服务。

当前节点指定对该服务请求有处理能力的其他节点对该服务请求进行处理时，首先建立当前服务请求和指定的处理节点之间的链接信息；再将链接信息发送至其他节点。

具体的，建立链接关系是通过将当前服务请求的标识和指定的处理节点的标识进行绑定实现，服务请求的标识为服务请求的的识别ID，节点的标识为节点的识别ID。通过将链接信息直接发送给其他节点，使其他节点能够及时获知该服务请求已被分配，避免任一节点在后续接收该服务请求时重复拉取其他节点的负载信息列表，也使被分配处理该服务请求的节点及时将该服务请求加入处理队列中。

每个所述节点在接收到服务请求时，将该服务请求的标识与收到服务请求的时间更新至负载信息列表中，当该服务请求为自身处理时，在负载信息列表中针对该服务请求的标识标记自身节点标识。

通过将收到服务请求的时间更新至负载信息列表中，方便节点之间在拉取负载信息列表后，对同一服务请求判断是哪个节点进行处理或分配操作。另外，通过节点对于自身处理的服务请求标记上自身节点标识，可在负载信息列表被其他节点拉取时，快速定位到未分配节点处理的服务请求，减少节点对其他节点的负载信息列表的读取时间，提升负载信息列表的读取速度。

每个所述节点在接收到服务请求时，将该服务请求的标识与收到服务请求的时间更新至负载信息列表中，当该服务请求为其他节点处理时，在负载信息列表中删除该服务请求的标识与收到服务请求的时间。

因服务请求在最初写入节点的负载信息列表中时，并不能确定该服务请求是否是该节点自身进行处理，一些服务请求最终会分配给其他节点处理，为了不占用过多的缓存，将服务请求分配给其他节点后，及时的将服务请求删除，减少负载信息列表的文件大小，减少缓存占用，也有利于负载信息列表被其他节点调取时，及时定位到未被分配节点处理的服务请求。

实施例3

如图4所示，一种服务系统，包括多个节点100，在每个节点100上均设置有请求接收模块101、负载分发模块102、负载信息获取模块103和判断模块104。

所述请求接收模块101，用于可接收服务请求；

所述负载分发模块102，用于将接收到服务请求分配给其他节点100进行处理。

下面举例对本发明进行说明：以对客服人员进行服务的客服系统为例，该系统由分布式架构的多个节点100构成，每个节点100可对一定数量的客服人员进行服务，服务时，对客服和客户电话交互信息进行处理，处理得到可辅助客服人员对客户问题进行及时解答的辅助信息，以便客服人员向客户提供良好的服务结果。传统分布式系统中，当客服人员发起服务请求时，由统一的主节点进行负载分发，具体地，即由主节点决定对服务请求进行处理的节点100，而本发明的分布式系统，每个节点100均可执行负载分发，从而能够避免服务请求在单一节点100堆积的问题和负载分发速度慢的问题。在以对客服人员进行服务的客服系统中，当大量客服人员同一时间上班后，容易瞬间出现大批量请求的出现，在使用传统分布式系统时，需要较长的反应时间才能为每个客服人员分配到一个节点100进行服务，而采用本发明后能够在很短的时间内就为每个客服人员分配到一个节点100进行服务。

实际使用中，每个服务请求发起后，系统会首先对多个节点100进行负载轮询，根据轮询结果先分配一个接收该服务请求的节点100。

每个所述节点100在接收到服务请求后，执行以下步骤：

步骤1、负载信息获取模块103向其他节点100发送负载信息获取请求，获取其他节点100当前的负载信息列表；

步骤2、判断模块104判断接收到的服务请求是否在其他节点100的负载信息列表中，所述负载信息列表为记录节点100需处理的服务请求的列表；若是，进入步骤3；若否，进入步骤4；

步骤3、判断模块104判断接收到的服务请求在其他节点100的负载信息列表中记录的时间是否早于在当前节点100的负载信息列表中记录的时间；若是，则节点100对该服务请求不做处理；若否，则进入步骤4；

步骤4、判断模块104判断节点100是否对该服务请求有处理能力；若是，则当前节点100对该服务请求进行处理；若否，则根据其他节点100的负载信息列表，指定至少一个对该服务请求有处理能力的其他节点100对该服务请求进行处理。

步骤4中节点100在接收到服务请求后，首先对自身进行判断，若可以，则不必进行服务请求分配，在一定程度上减少了执行服务请求分配给其他节点100的动作次数，可以更加高效的对服务请求进行响应。

通过步骤1、步骤2、步骤3的执行，可以及时发现重复的服务请求，避免节点100对服务请求重复处理和重复分配，保证一个服务请求只会被一个节点100处理或进行分配。

当前节点100判断自身是否对该服务请求有处理能力时，包括以下步骤：

步骤4-1、查询当前负载信息列表中待处理的服务请求全部处理完成所需的时间T1；

步骤4-2、预估当前服务请求处理完成所需时间T2；

步骤6-3、判断T1+T2＜T3是否成立，当前服务请求需在T3时间段内处理完成；若是，则当前节点100该服务请求有处理能力，若否，则当前节点100该服务请求无处理能力。

通过以服务请求处理完成所需时间T3来判断节点100的处理能力，能够保证服务请求的处理结果返回时间达到设计要求，实际上可使对用户的响应时间达到要求，提高用户体验。例如在对客服的客服系统中，客服打开客服系统页面发起服务请求，必须要在1s内给客服人员返回结果才能对客服提供帮助。则节点100判断不能1s内返回结果时，应及时指定可在1s内返回结果的节点100进行处理。本实施例中对当前服务请求进行处理，例如节点100对客服和客户电话交互信息进行处理，处理得到可辅助客服人员对客户问题进行及时解答的辅助信息，以便客服人员能够对客户提供满意的服务。

当前节点100指定对该服务请求有处理能力的其他节点100对该服务请求进行处理时，首先建立当前服务请求和指定的处理节点100之间的链接信息；再将链接信息发送至其他节点100。

具体的，建立链接关系是通过将当前服务请求的标识和指定的处理节点100的标识进行绑定实现，服务请求的标识为服务请求的的识别ID，节点100的标识为节点100的识别ID。通过将链接信息直接发送给其他节点100，使其他节点100能够及时获知该服务请求已被分配，避免任一节点100在后续接收该服务请求时重复拉取其他节点100的负载信息列表，也使被分配处理该服务请求的节点100及时将该服务请求加入处理队列中。

每个所述节点100在接收到服务请求时，将该服务请求的标识与收到服务请求的时间更新至负载信息列表中，当该服务请求为自身处理时，在负载信息列表中针对该服务请求的标识标记自身节点100标识。

通过将收到服务请求的时间更新至负载信息列表中，方便节点100之间在拉取负载信息列表后，对同一服务请求判断是哪个节点100进行处理或分配操作。另外，通过节点100对于自身处理的服务请求标记上自身节点100标识，可在负载信息列表被其他节点100拉取时，快速定位到未分配节点100处理的服务请求，减少节点100对其他节点100的负载信息列表的读取时间，提升负载信息列表的读取速度。

每个所述节点100在接收到服务请求时，将该服务请求的标识与收到服务请求的时间更新至负载信息列表中，当该服务请求为其他节点100处理时，在负载信息列表中删除该服务请求的标识与收到服务请求的时间。

因服务请求在最初写入节点100的负载信息列表中时，并不能确定该服务请求是否是该节点100自身进行处理，一些服务请求最终会分配给其他节点100处理，为了不占用过多的缓存，将服务请求分配给其他节点100后，及时的将服务请求删除，减少负载信息列表的文件大小，减少缓存占用，也有利于负载信息列表被其他节点100调取时，及时定位到未被分配节点100处理的服务请求。

以上所述，仅是本发明的较佳实施例，并非对本发明作任何限制，凡是根据本发明技术实质对以上实施例所作的任何简单修改、变更以及等效结构变化，均仍属于本发明技术方案的保护范围内。

Claims (10)

1.一种负载处理方法，其特征在于，

节点接收服务请求，并将所述服务请求分配给其他节点进行处理；

其中，每个所述节点均可接收服务请求，每个所述节点均可将服务请求分配给其他节点进行处理。

2.如权利要求1所述负载处理方法，其特征在于，

所述节点在接收到服务请求后，判断自身是否对所述服务请求有处理能力，若是，则对所述服务请求进行处理；若否，则将所述服务请求分配给其他节点进行处理。

3.如权利要求2所述负载处理方法，其特征在于，所述判断自身是否对所述服务请求有处理能力之前，还包括：

步骤1、所述当前节点判断服务请求是否在其他节点的负载信息列表中，所述负载信息列表记录节点需处理的服务请求的信息；若是，进入下一步；若否，判断自身是否对所述服务请求有处理能力；

步骤2、所述当前节点判断接收到的服务请求在其他节点的负载信息列表中记录的时间是否早于在当前节点的负载信息列表中记录的时间；若是，则对所述服务请求不做处理；若否，判断自身是否对所述服务请求有处理能力。

4.如权利要求2或3所述负载处理方法，其特征在于，所述判断自身是否对该服务请求有处理能力，包括：

查询当前节点的负载信息列表中待处理的服务请求全部处理完成所需的时间T1；

预估当前服务请求处理完成所需时间T2；

判断T1+T2＜T3是否成立，当前服务请求需在T3时间段内处理完成；若是，则当前节点该服务请求有处理能力，若否，则当前节点该服务请求无处理能力。

5.如权利要求2所述负载处理方法，其特征在于，所述将所述服务请求分配给其他节点进行处理，包括：

根据其他节点的负载信息列表，指定至少一个对所述服务请求有处理能力的其他节点对所述服务请求进行处理。

6.如权利要求5所述负载处理方法，其特征在于，所述指定至少一个对所述服务请求有处理能力的其他节点对所述服务请求进行处理，包括:

建立所述服务请求和指定的处理节点之间的链接信息；

将链接信息发送至其他节点。

7.如权利要求2或3所述负载处理方法，其特征在于，

每个所述节点在接收到服务请求时，将所述服务请求的标识与收到服务请求的时间更新至负载信息列表中。

8.如权利要求7所述负载处理方法，其特征在于，

当所述服务请求由当前节点处理时，在当前节点的负载信息列表中针对所述服务请求的标识标记自身节点标识。

9.如权利要求7所述负载处理方法，其特征在于，

当所述服务请求由其他节点处理时，在当前节点的负载信息列表中删除所述服务请求的标识与收到所述服务请求的时间。

10.一种服务系统，其特征在于，包括多个节点，每个节点上均设置有请求接收模块、负载分配模块、判断模块和负载信息获取模块；

所述请求接收模块，用于接收服务请求；

所述负载分配模块，用于将接收到服务请求分配给其他节点进行处理。

所述判断模块用于在接收到服务请求后，判断节点是否对该服务请求有处理能力，若是，则对该服务请求进行处理；若否，则将该服务请求分配给其他节点进行处理。

所述负载信息获取模块用于获取其他节点当前的负载信息列表；

所述判断模块判断节点是否对所述服务请求有处理能力之前，还包括：

步骤1、所述判断模块判断服务请求是否在其他节点的负载信息列表中，所述负载信息列表记录节点需处理的服务请求的信息；若是，进入下一步；若否，判断自身节点是否对所述服务请求有处理能力；

步骤2、所述判断模块判断接收到的服务请求在其他节点的负载信息列表中记录的时间是否早于在当前节点的负载信息列表中记录的时间；若是，则自身节点对所述服务请求不做处理；若否，判断自身节点是否对所述服务请求有处理能力。

Images