CN113268329B - 一种请求调度方法、装置及存储介质 - Google Patents

Abstract

本发明涉及一种请求调度方法、装置及存储介质，应用于调度设备。本方案通过获取在先一次的访问请求所发送的参考服务端，基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，保证目标编号与所述参考编号不一致，并由目标编号来确定目标服务端，本方案中结合轮询算法和随机算法，来确定目标编号，通过轮询步长保证目标编号与参考编号相比会有改变，通过随机数来解决以固定步长来确定目标编号的问题，规避单纯依靠轮询算法经常出现的访问请求发送到同一服务端的调度设备再次转发访问请求时，还是将访问请求都发送到另一服务端中的问题，避免出现热点服务端，造成服务端的负载过大的情况。

Description

一种请求调度方法、装置及存储介质

技术领域

本发明涉及访问管理技术领域，尤其涉及一种请求调度方法、装置及存储介质。

背景技术

负载均衡，英文名称为Load Balance，其含义就是指将负载进行平衡、分摊到多个操作单元上进行运行；负载均衡构建在原有网络结构之上，它提供了一种透明且廉价有效的方法扩展服务端和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。

在多客户端多服务端场景下，并发请求过多，调度***采用负载均衡算法，调度服务应用***，进行业务处理。现有的负载均衡算法主要包括轮询算法、加权轮询算法、随机算法、加权随机算法、源地址哈希算法以及最小连接算法等等。比如，加权随机算法，该算法首先统计各个服务应用的启动时间作为该服务应用的权重，当请求访问时，在所有权重值范围内随机出一个值，然后在排序后的权重列表中选择第一个大于或等于该权重值的服务应用作为目标应用访问。当客户端访问量过多时，上述算法会出现一些热点值，导致部分服务端***请求量过大，存在服务端资源利用率低等问题。

发明内容

为了解决现有技术存在的问题，本发明的至少一个实施例提供了一种请求调度方法、装置及存储介质。

第一方面，本发明实施例提供了一种请求调度方法，应用于调度设备，所述调度方法包括：

当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端；

基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致；

将所述访问请求发送至所述目标服务端。

第二方面，本发明实施例提供了一种请求调度装置，应用于调度设备，所述调度方法包括：

获取单元，用于当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端；

处理单元，用于基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致；

发送单元，用于将所述访问请求发送至所述目标服务端。

第三方面，本发明实施例提供了一种请求调度***，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现第一方面中任一实施例所述的请求调度方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现第一方面中任一实施例所述的请求调度方法。

本发明的上述技术方案与现有技术相比具有如下优点：本方案通过获取在先一次的访问请求所发送的参考服务端，通过轮询步长、随机数和参考服务端的参考编号，确定目标编号，保证目标编号与所述参考编号不一致，并由目标编号来确定目标服务端，本方案中结合轮询算法和随机算法，来确定目标编号，通过轮询步长保证目标编号与参考编号相比会有改变，通过随机数来解决以固定步长来确定目标编号的问题，规避单纯依靠轮询算法经常出现的访问请求发送到同一服务端的调度设备再次转发访问请求时，还是将访问请求都发送到另一服务端中的问题，避免出现热点服务端，造成服务端的负载过大的情况。

附图说明

图1是本发明实施例提供的为实现本发明各个实施例的一种服务***的结构示意图；

图2是本发明另一实施例提供的一种请求调度方法流程示意图；

图3是本发明又一实施例提供的一种请求调度方法流程示意图；

图4是本发明又一实施例提供的一种请求调度方法流程示意图其一；

图5是本发明又一实施例提供的一种请求调度方法流程示意图其二；

图6是本发明又一实施例提供的一种请求调度方法流程示意图其三；

图7是本发明又一实施例提供的调度设备将访问请求分发至服务端的示意图；

图8是本发明又一实施例提供的一种请求调度方法流程示意图其四；

图9是本发明又一实施例提供的一种请求调度装置结构示意图；

图10是本发明又一实施例提供的一种请求调度装置结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

如图1所示，本发明实施例提供的为实现本发明各个实施例的一种服务***，基于该服务***，可以提供远程服务，包括多个客户端21、多个调度设备22和多个服务端23，各电子设备通过万维网完成相互间的通信，其中，客户端21可以是诸如手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(Persona l Di gita l Ass i stant，PDA)、便捷式媒体播放器(Portab l e Med i a P l ayer，PMP)、导航装置、可穿戴设备、智能手环、计步器等移动终端，以及诸如数字TV、台式计算机等固定终端。

每个用户都会具备自己的客户端21，而不同客户在通过客户端21请求服务端23服务是相互独立的，客户端21通过接收客户的控制操作，当需要服务端23提供相应的服务时，生成相应的服务请求发送至调度设备22，调度设备22通过随机的或者轮询的现有算法为客户端21的服务请求确定服务端23，并将服务请求转发至服务端23以实现对于该客户端21的服务请求的处理。

每个调度设备22接收到客户端21反馈的服务请求时，由于客户端21发送服务请求都是独立随机的事件，所以不同调度设备22可以根据设置，专门服务于某些特定条件的客户端21，比如，为调度设备22配置所对应的客户端21，当任一客户端21发送服务请求时，由特定的调度设备22对服务请求进行处理，当然，也可以随机分发给调度器；由调度设备22确定处理服务请求的服务端23后，将服务请求转发至相应的服务端23。

服务端23接收调度设备22转发的服务请求，根据服务端请求中的数据完成相应的处理，将数据处理结果反馈至客户端21，完成用户的需求。

在调度设备22中，现有的负载均衡算法主要包括轮询算法、加权轮询算法、随机算法、加权随机算法、源地址哈希算法以及最小连接算法等等，通过算法确定处理服务请求的服务端23。

比如，采用加权随机算法，该算法首先统计各个服务端23的启动时间作为该服务端23的权重，当请求访问时，在所有权重值范围内随机出一个值，然后在排序后的权重列表中选择第一个大于或等于该权重值的服务端23作为目标应用进行访问。

比如，采用随机算法，该算法在每次确定处理服务请求的服务端23时随机生成随机数，依照随机数来确定处理服务请求的服务端23，以实现通过随机算法将请求分散开，还可以同时生成多个随机数，通过相同的方式确定接下来的服务请求发送到的服务端23。

在实际应用中，当客户端21访问量过多时，若客户端21本地能够完成的服务越少，那最终需要服务端23进行处理的服务请求就越多，而在调度设备22中使用上述负载均衡算法会导致出现一些热点值，导致部分服务端23请求量过大，存在服务端资源利用率低的问题。

客户端可以是接收用户输入的数据的客户端21，客户端21中一般会在本地构建部分本地可以完成的服务内容，比如数据填写框，数据本地持久化等服务，还可以进行诸如运算、渲染等需要较大存储空间才能够进行的服务，但是这类需要较大存储空间才能完整运行的服务一旦在本地进行，那就需要在客户端21中占用大量的运行资源和存储空间，这样是十分影响用户使用的，所以，现有的客户端***越来越重视云服务***，即构建远程服务端***，将一些在客户端21上运行起来十分耗费资源的服务转移到服务端***中，客户端21只需加载相应的接口，将相关数据传输至服务端***，由服务端***来进行运行后将结果返回到客户端21，客户端21直接使用返回的结果，这样就可以极大的降低客户端21的硬件要求，同时，由于服务端***是大规模集群，所以，运算效率相较于客户端21来说更加快速，虽然客户端21与服务端***之间进行数据传输会占用一定的时间，但是，相比较于由客户端21本身来进行数据处理，通过服务端***来进行数据处理最终的耗时会更短。

在负载均衡场景下，为了提高服务端的利用效率，本发明实施例提供了一种请求调度方法，应用于调度***中的调度设备。参照图2，调度方法包括如下步骤：

S21、当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端。

在本实施例中，本步骤中当任一调度设备接收到客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，即调度设备接收到客户端的服务请求时，获取该调度设备在先一次接收到的访问请求最终所发送到的服务端，并将该服务端作为参考服务端。

在本方案中，由于服务端***是由服务端构成的集群，对于任一调度设备而言，由于服务端的数量一般远大于调度设备的数量，若是调度设备一直将自身的访问请求发送到同一服务端，那就会导致大量的服务端处于空闲状态，即使调度设备将访问请求进行随机发送，当客户端访问量过多时，随机发送也有可能导致出现一些热点值，导致部分服务端处理的访问请求量过大，存在服务端资源利用率低等问题，所以，本方案中当调度设备接收到客户端的访问请求时，获取调度设备上在先一次接收到的访问请求发送到的服务端，并将其作为参考服务端，以便于后续确定当前接收到的访问请求应该发送的服务端，以避免调度设备两次接收到的访问请求重复发送到同一服务端。

在本实施例中，可以在访问请求发送至服务端时，记录下服务端的信息，以便于接收到新的访问请求时，可以快速获取到在先一次接收到的访问请求发送到的服务端，比如，记录服务端的编号信息、名称信息或者地址信息等。

S22、基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致。

在本实施例中，通过将参考服务端的参考编号与随机数、轮询步长求和，根据得到的数值确定目标服务端的编号，根据目标编号确定目标服务端。具体的，比如，当和值大于服务端数量时，通过将和值对服务端数量取余，按照余数确定目标编号，当和值小于或等于服务端数量时，可以直接将该和值确定为目标编号。

在本实施例中，本方案中通过轮询步长使得参考编号的数值增加，但是轮询步长容易导致确定目标服务端时只循环固定的几个服务端，所以，同时引入随机数，使得参考编号的数值增加后，与随机数相结合，实现目标编号的数值分散的效果，规避了轮询算法中容易出现的问题，同时通过限制使得参考编号与目标编号不一致，避免了随机算法中容易出现的调度设备多次将请求都发送到同一服务端中的问题。

S23、将所述访问请求发送至所述目标服务端。

在本实施例中，本方案通过获取在先一次的访问请求所发送的参考服务端，通过轮询步长、随机数和参考服务端的参考编号，确定目标编号，保证目标编号与所述参考编号不一致，并由目标编号来确定目标服务端，本方案中结合轮询算法和随机算法，来确定目标编号，通过轮询步长保证目标编号与参考编号相比会有改变，通过随机数来解决以固定步长来确定目标编号导致的问题，规避单纯依靠轮询算法经常出现的访问请求发送到同一服务端的调度设备再次转发访问请求时，还是将访问请求都发送到另一服务端中的问题，避免出现热点服务端，造成服务端的负载过大的情况。

在确定目标服务端时，若单独使用轮询算法来确定目标编号，则存在不断重复将若干个服务端作为目标服务端问题；若单独使用随机算法则存在因为概率问题常常随机到同一个服务端作为目标服务端的问题。

针对前述轮询算法和随机算法的缺点，本方案考虑轮询算法和随机算法的问题，最终确定目标编号时，因为轮询步长，使得参考编号增加轮询步长，因为随机数，使得目标编号是一个随机值，可以起到分散服务请求的作用，这对一个调度***来说至关重要。所以说，本方案是综合了轮询算法和随机算法的优点，保证服务请求可以分散到各个服务端上，而规避了单独使用轮询算法和随机算法的问题。

在本实施例中，将访问请求转发至目标服务端，以完成对于访问请求的处理，具体的，如图3所示，将访问请求发送至目标服务端包括如下步骤：

S31、获取所述目标服务端的网络地址，作为目标地址。

在本实施例中，目标服务端的网络地址可以通过获取目标服务端的序号，按照预存储的服务端信息列表读取序号对应的服务端，得到相应的目标服务端的网络地址。

S32、将所述访问请求中携带的虚拟地址替换为所述目标地址。

S33、向所述目标服务端发送替换后的访问请求。

在本实施例中，在确定目标服务端后，通过获取目标服务端的网络地址，通过网络地址替换访问请求中的虚拟地址，以实现访问目标服务端。

在前述任意一种实施例的基础上，本发明进一步提供了随机数的生成方式。此时，请参照图4，该调度方法可以包括如下步骤：

S41、当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端。

有关步骤S41，详细可参见步骤S21中的描述，本实施例在此不再赘述。

S42、获取第一数量与第二数量；其中，所述第一数量为当前转发访问请求至服务***的调度设备的数量；所述第二数量为所述服务***中服务端的数量。

在本实施例中，由于为客户端将访问请求转发至服务***的调度设备的情况会影响到如何平衡各个服务端所能接收到的访问请求的数量，所以，在本步骤中，在接收到客户端发送的访问请求时，获取当前将访问请求转发至服务***的调度设备的数量，用以后续均衡各个服务端所接收到的访问请求。

在本实施例中，而能够为客户端提供服务的服务端的数量也会影响到后续如何平衡各个调度设备所发送的访问请求，所以，获取此时服务***中的服务端的数量，以便于后续处理。

S43、根据所述第一数量和所述第二数量生成随机数。

在本实施例中，在常规的调度***和服务***中，调度***中调度设备的数量会远大于1个，通过第二数量和第一数量生成随机数，一方面可以参考服务***中服务端的数量，另一方面，可以通过调度设备的数量对随机数的大小进行一定的限制。

在具体实现时，还可以限制随机数的数值大小，以达到更好的去热点化处理。具体而言，可以使得生成的所述随机数小于第三数量；所述第三数量为所述第二数量与轮询步长的差值；所述轮询步长小于所述第二数量。控制随机数小于第三数量，使得轮询步长参考服务端的参考编号、随机数和轮询步长之和小于参考编号与第二数量之和，虽然限制了随机数的大小，但是并不会影响到目标编号的取值范围，同时，可以避免随机算法中选取到的目标编号还是参考编号的问题。

在本实施例中，随机数的生成算法可以表示为：f(x)＝y，其中，y表示随机数，x表示随机变量。该随机数生成算法的逻辑可以包括但不限于：y是在x-n到x之间取任意整值；n为大于0的整数。此时y的最大值是x，最小值是x-n。例如，最小值可以是0(n＝x)，也可以是1(n＝x-1)。

在本实施例中，基于上述随机数生成逻辑，我们只需要确定我们方案中的x，即可限制随机数的数值大小。

示例性的一种实施例中，在本实施例中，可以通过第一数量和所述第二数量确定上述随机变量x，并进一步通过随机变量x确定所述随机数，比如，可以将第二数量除以第一数量，或者，将第二数量减去第一数量，确定上述随机变量x。

示例性的另一种实施例中，可以根据第一数量生成0至第一数量中任一数值的第一随机数候选值，根据第二数量生成0至第二数量中任一数值的第二随机数候选值，根据第一随机数候选值和第二随机数候选值的和值与第三数量的大小，来通过第一随机数候选值和第二随机数候选值得到本步骤中的随机数。

具体而言，第一随机数候选值和第二随机数候选值的相加值小于第三数量，则可以将第一随机数候选值和第二随机数候选值的相加值作为随机数；若第一随机数候选值和第二随机数候选值的相加值等于第三数量，则可以将数值0作为随机数，或者，根据第三数量，通过随机数生成算法在0至第三数量之间选取任一数值作为随机数；若第一随机数候选值和第二随机数候选值的相加值大于或等于第三数量，则可以再次生成第一随机数候选值和第二随机数候选值，直至第一随机数候选值和第二随机数候选值的和值小于第三数量，也可以将第一随机数候选值和第二随机数候选值的相加值对第三数量取余，将得到的余数作为随机数。

在本实施例中，本方案中通过限制随机数的大小，使得随机数小于第三数量，更有利于规避随机算法和轮询算法中的存在的问题。

具体原因在于，一旦出现随机数过大，比如，随机数生成算法所选取的数值范围中的最大值大于或等于第三数量，通过该随机数生成算法得到的随机数就有可能大于或等于第三数量，通过该随机数在后续步骤中确定目标服务端，就可能出现选取到的目标服务端与参考服务端一致的情况，所以，本方案中通过限制随机数的大小，使得随机数小于第三数量，从而，有利于规避随机算法中目标服务端与参考服务端一致的情况。

在本实施例中，可以通过将服务端的信息预存储进服务端信息表，在本步骤中，直接从服务端信息表中获取能够为客户端提供服务的服务端的数量，当然也可以读取服务日志信息来确定服务***中的服务端的数量，本方案对此不做特别限定。

具体的，获取服务***中服务端的第二数量可以通过获取服务端信息列表；根据所述服务端信息列表得到所述服务***中服务端的第二数量；比如，可以直接获取服务端信息列表中的序号标号得到服务端的数量，还可以遍历服务端信息列表中服务端信息的条数得到服务端的数量。

S44、基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致。

有关步骤S44，详细可参见步骤S22中的描述与后文的展开说明，本实施例在此不再赘述。

S45、将访问请求发送至目标服务端。

有关步骤S45，详细可参见步骤S23中的描述，本实施例在此不再赘述。

在本实施例中，还可以限制随机数的数目大小，以达到更高的去热点化处理。具体而言，可以使得生成的所述随机数小于第三数量；所述第三数量为所述第二数量与轮询步长的差值；所述轮询步长小于所述第二数量,通过对随机数的数值进行控制，避免确定的目标服务端还是原参考服务端，本方案引入轮询步长作为步长和随机数这两种因子，相较于轮询算法以固定步长来确定下一次访问请求发送到的服务端，本方案中增加了随机数，避免将访问请求发送到同一服务端的调度设备再次转发访问请求时，还是将访问请求都发送到另一服务端中，导致出现并发冲突。

示例性的，本发明实施例提供了一种根据第一数量和第二数量生成随机数的生成方式。请参照图5，根据第一数量和第二数量生成随机数，包括如下步骤：

S51、将第二数量除以第一数量，得到参考随机数。

S52、将参考随机数与第三数量进行比较；所述第三数量为所述第二数量与轮询步长的差值。

在本实施例中，在本实施例中，第二数量是能够为客户端提供服务的服务***中服务端的数量，第一数量是协调各个客户端的访问请求的调度设备的数量，将访问请求均衡发送至服务端的调度设备的数量，将第二数量除以第一数量，得到参考随机数。

在本实施例中，调度设备每次将访问请求转发至服务端时都是依次进行的，而发出访问请求的客户端的数量是十分庞大的，由于本方案是针对调度***中的调度设备，所以，当参考随机数小于第三数量时，直接通过参考随机数确定目标服务端，不同调度设备的访问请求的分发会出现部分重复情况，所以，根据参考随机数的大小采用不同的均衡方法进行访问请求的分发。

在本实施例中，随机数生成算法的逻辑可以包括但不限于：f(x)＝y，其中，y表示随机数，x表示随机变量。该随机数生成算法的逻辑可以包括但不限于：y是在x-n到x之间取任意整值；n为大于0的整数。此时y的最大值是x，最小值是x-n。例如，最小值可以是0(n＝x)，也可以是1(n＝x-1)。

在本实施例中，通过上述表述可以得知，当参考随机数大于或等于第三数量时，基于该参考随机数，通过随机数生成算法生成的随机数可能会出现等于第三数量的情况，一旦出现生成的随机数等于第三数量的情况时，那参考编号+轮询步长+第三数量得到的数值就是参考编号+第二数量，通过该数值对第二数量进行取余得到的就是参考编号，即，目标编号为参考编号，访问请求又将被发送到参考服务端中。所以，实现生成的随机数小于第三数量，在本方案中可以对参考随机数的大小进行判定，在参考随机数小于第三数量和参考随机数大于或等于第三数量时，采用不同的逻辑生成随机数。

S53a、若参考随机数小于第三数量，且所述参考随机数大于或者等于1，则根据所述参考随机数生成所述随机数。

在本实施例中，本方案中得到参考随机数的方法是将第二数量除以第一数量是为了因为在实际场景中，服务端一般会比调度设备多，也就是，第二数量一般会比第一数量多，所以这个参考随机数一般是大于1的，此时，若参考随机数小于第三数量，则根据所述参考随机数生成所述随机数。

在本实施例中，当参考随机数小于第三数量时，根据参考随机数生成随机数，直接就可以保证生成的随机数小于第三随机数，在后续通过随机数确定目标服务端时，既保证了最终得到的目标服务端不会是参考服务端，也保证了访问请求可以随机分配到各个服务端中。

S53b、若所述参考随机数小于1，则调大所述参考随机数，使得调大后的参考随机数大于或等于1，且调大后的参考随机数小于所述第三数量，并根据调大后的参考随机数生成所述随机数。

在本实施例中，考虑到也可能会存在调度设备比服务端多的情况，这种情况下，第二数量小于第一数量，则参考随机数会在0-1之间，此时，若通过参考随机数生成随机数，本方案又会变为轮询算法，所以，在本步骤中，调大参考随机数，使得参考随机数大于或等于1，且小于第三数量。

具体的，当参考随机数小于1时，若直接以参考随机数生成随机数，则只能得到0，本方案会蜕变为轮询算法，比如，第二数量为1，第一数量为5，此时得到的参考随机数是0.2，由随机数生成算法只能生成整数，通过随机数生成算法对0.2进行运算只能得到0，而一旦随机数变为0，本方案的目标编号就是由参考编号+轮询步长确定的，本方案又变为轮询算法。

为了避免无效随机数，陷入轮询的情况，我们针对参考随机数小于1的情况进行特殊处理：调大参考随机数。参考随机数调大后，通过参考随机数得到的随机数可以是0至参考随机数之间的任意一个值，比如0或参考随机数，但是随机数的取值的数量相较于上述情况会更多，所以，能起到一个均衡随机，打散轮询的效果。

所以，当参考随机数小于1时，可以将参考随机数设置为预设参考随机数，还可以将计算得到的参考随机数扩大预设倍数，或者，将参考随机数增加预设值，或者，还可以将参考随机数乘以一个大于1的权重值，不再穷举。并且，需要注意的是，经过上述调大参考随机数后，只需要保证调大后的参考随机数大于或等于1，且小于第三数量，即可将调大后的参考随机数作为随机变量，用于生成随机数。

在本实施例中，基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，由于随机数是由参考随机数通过随机算法得到，所以随机数小于或等于参考随机数，而参考随机数小于第三数量，进一步，随机数小于第三数量，而第三数量为第二数量与轮询步长的差值，所以参考编号、随机数和轮询步长之和小于参考编号与第二数量之和，最终，通过参考编号、随机数和轮询步长之和对第二数量进行取余确定目标编号，得到的目标编号的数值小于参考编号的数值。

S53c、若参考随机数大于或等于第三数量，则通过随机权重系数对，调小所述参考随机数，使得调小后的参考随机数大于或等于1，且调小后的参考随机数小于所述第三数量，并根据调小后的所述参考随机数生成所述随机数；其中，所述随机数小于所述第三数量。

在本实施例中，当参考随机数大于或等于第三数量时，调小参考随机数，使得调小后的参考随机数大于或等于1，且小于第三数量，保证通过轮询步长和随机数这两种因子确定目标服务端的方案可以规避随机算法和轮询算法中的存在的问题。

具体的，当参考随机数大于或等于第三数量时，可以将参考随机数设置为预设参考随机数，还可以将计算得到的参考随机数缩小预设倍数，或者，将参考随机数减少预设值，或者，还可以将参考随机数乘以一个大于1的权重值，不再穷举。并且，需要注意的是，经过上述调小参考随机数后，只需要保证调小后的参考随机数大于或等于1，且小于第三数量，即可将调小后的参考随机数用于生成随机数。

在本实施例中，除上述步骤S51～S53c的方案，还可以调整本方案的执行步骤。

具体的，可以先判断第一数量和第二数量的大小。

当第一数量大于第二数量时，将第二数量除以第一数量，得到参考随机数，此时，参考随机数小于1，调大所述参考随机数，使得调大后的参考随机数大于或等于1，且调大后的参考随机数小于所述第三数量，并根据调大后的参考随机数生成所述随机数。

当第一数量大于第二数量时，将第二数量除以第一数量，得到参考随机数，将参考随机数与第三数量进行比较。此时，若参考随机数小于第三数量，则根据所述参考随机数生成所述随机数；反之，若参考随机数大于或等于第三数量，则通过随机权重系数对，调小所述参考随机数，使得调小后的参考随机数大于或等于1，且调小后的参考随机数小于所述第三数量，并根据调小后的所述参考随机数生成所述随机数。

通过上述调整步骤后的方案同样可以实现本方案的执行逻辑，所以，即使与本方案的执行步骤不一致，但是最终具有相同执行逻辑的方案均应属于本方案的保护范围之内。

在本实施例中，一般情况下服务端的数量和调度设备的数量可以参考上述实施例中的表述，但是，还是存在参考随机数大于或等于第三数量的情况，当参考随机数大于或等于第三数量时，生成随机权重系数，对参考随机数的数值通过随机权重系数进行调低。

由于本方案中需要最终得到的随机数小于第三数量，而轮询步长至少为1，所以，一旦出现调度设备的数量只有一个时，就容易出现参考随机数大于或等于第三数量的情况，通过本方案中对参考随机数进行适当调低，得到新的参考随机数，通过调整后的参考随机数生成随机数可以降低生成的随机数大于或等于第三数量的概率，以上举例说明是为了方便理解，并不做特别限定。

在本实施例中，随机权重系数可以是大于0且小于等于1的数值，具体的，在参考随机数大于或等于第三数量时，将第三数量除以参考随机数得到权重系数，根据随机数生成算法，选取0至权重系数中任一数值作为随机权重系数，保证调整后的参考随机数小于第三数量，通过调整后的参考随机数生成随机数。

在本实施例中，本算法综合了轮询算法和随机算法的优点，提出了随机步长轮询算法。

在本实施例中，可以通过如下计算公式计算上述实施例中的目标服务端的编号：

index＝{sIndex+α+Rand(k×sNum/cNum)}MODsNum；

其中，index为目标编号，sIndex为参考编号，α为轮询步长，Rand()为随机数生成函数(还可以表示为f(x)，不作穷举)，cNum为第一数量，sNum为第二数量，k为随机权重系数，Rand(k×sNum/cNum)为随机生成0到k×sNum/cNum中任一整数，MOD为求余函数。

在本实施例中，随机权重系数(k)控制下次随机轮询服务的跨度，当服务端数量与调度设备数量之比小于第三数量时，此时算法蜕化成轮询随机算法(k＝1)，当服务端数量与调度设备数量之比大于或等于第三数量时，生成随机权重系数，对参考随机数的数值通过随机权重系数进行调低，得到新的参考随机数，通过调整后的参考随机数生成随机数。

在本实施例中，参考随机数大于或等于第三数量，我们需要将参考随机数调小。示例性的一种实施例中，可以通过随机权重系数来进行调小处理。随机权重系数的取值可以为提前预设的经验值，或者，也可以基于实际数据情况来进行自定义设计并自动确定。

在本实施例中，可以确定服务端中具有高处理性能的服务端，并据此来确定随机权重系数，从而，利用随机权重系数来调整参考随机数，使得通过上述公式最终得到的目标编号可以是任一具有高处理性能的服务端，这样，可以使得本方案的访问请求有机会发送到具有高处理性能的服务端，提高对于访问请求的处理效率。

在本实施例中，如图6所示，若参考随机数大于或等于第三数量，通过随机权重系数，调小所述参考随机数，根据调小后的参考随机数生成所述随机数，包括如下步骤：

S61、获取各个服务端对访问请求的处理能力，根据所述处理能力确定服务端中的优选服务端；其中，所述优选服务端的处理能力高于各个服务端的处理能力的平均值。

在本实施例中，服务端对访问请求的处理能力可以但不限于如下至少一种：服务端的请求处理效率对应的处理能力、服务端的请求处理时长对应的处理能力，或者，服务端处理访问请求时的最长处理时长对应的处理能力，或者，服务端单位时间的数据处理量对应的处理能力，或者，也可以是服务端单位时间的数据运算量对应的处理能力。此处不作穷举。

在本实施例中，获取各个服务端对访问请求的处理能力，由于处理能力越高，则说明该服务端能够更快的处理服务请求，同时，让处理能力更高的服务端处理更多的服务请求可以让***整体能够完成更多的任务，所以，为了提高***的整体工作效率，在通过上述方案确定目标服务端时，应当让得到的目标编号是处理能力更高的服务端的编号。

在本实施例中，通过各个服务端的处理能力的平均值来筛选优选服务端，保证确定的优选服务端是处理能力在平均水平之上的服务端。

进一步，在以平均值对服务端进行筛选后，还可以对参考服务端的处理能力进行排序，将排序靠后的优选服务端剔除，比如剔除百分之50或者更高比例的优选服务端，以减少优选服务端的数量。更进一步的，示例性的一种实施例中，也可以只保留处理能力最高的优选服务端。

在本实施例中，参考上述实施例中的目标服务端的编号确定公式index＝{sIndex+α+Rand(k×sNum/cNum)}MODsNum，以及参考随机数的范围，可以确定index无法为sIndex至sIndex+α-1中的值，所以，本实施例中确定服务端中的优选服务端时，优选服务端的编号需要位于sIndex至sIndex+α-1之外。

S62、根据所述优选服务端的编号、所述参考编号和所述参考随机数，确定所述随机权重系数。

具体而言，目标编号、第一编号、第二编号、轮询步长、参考编号之间的关系满足公式index＝{sIndex+α+Rand(k×sNum/cNum)}MODsNum，所以，可以利用优选服务端的编号进行反推，以确定随机权重系数的大致范围，并在该范围中具体确定该随机权重系数的取值。后文详述。

在本实施例中，S61中能够确定的优选服务端的数目可以为一个或多个。当确定了多个优选服务端时，一种可能的实施例中，可以分别根据每个优选服务端的编号、参考编号和参考随机数等，分别确定各优选服务端所对应的随机权重系数的范围，从而，基于多个范围，在其中确定一个随机权重系数。另一种可能的实施例中，也可以从各个优选服务端中选取任一优选服务端，根据该优选服务端确定相应的随机权重系数的范围，进而确定具体取值。另一种可能的实施例中，还可以直接在多个优选服务端中，选取处理能力最高的优选服务端，并据此确定相应的随机权重系数的范围及其取值。

在本实施例中，下述方案中为了实现让目标编号的区间范围包括至少一个优选服务端的编号，参考上述实施例中的目标服务端的编号确定公式index＝{sIndex+α+Rand(k×sNum/cNum)}MODsNum，以及参考随机数的范围，可以确定index无法为sIndex至sIndex+α-1中的值，若优选服务端的编号均位于sIndex至sIndex+α-1之间，则(k×sNum/cNum)只需大于或等于1，且小于第三数量即可，所以，在本实施例中，需要选取编号位于sIndex至sIndex+α-1之外的优选服务端，确定相应的随机权重系数。

S63、通过随机权重系数，调小所述参考随机数，根据调小后的参考随机数生成所述随机数，使得基于所述参考随机数生成的随机数得到的目标编号的区间范围包括至少一个优选服务端的编号。

在本实施例中，通过随机权重系数对参考随机数进行调整，使得基于参考随机数生成的随机数得到的目标编号的区间范围包括至少一个优选服务端的编号，由于随机数是基于参考随机数随机生成的，随机数的取值范围是{0，1,.......，(k×sNum/cNum)}，所以通过该随机数得到的目标编号也是一个区间范围，而为了让目标服务端有几率是优选服务端，目标编号的区间范围中就需要包括至少一个优选服务端的编号，为了实现这个方案，在对参考随机数进行调小时，需要控制参考随机数调小的量，实现将访问请求发送至优选服务端中进行处理，进而提高***对于访问请求的整体处理效率。

综合上述实施例，若参考随机数大于或等于第三数量，参考目标编号确定公式index＝{sIndex+α+Rand(k×sNum/cNum)}MODsNum，公式中的sIndex、α和sNum是定值，唯一会发生变化的是随机数Rand(k×sNum/cNum)，由于我们的目的是为了使得目标服务端有机会随机到本实施例中优选服务端，所以index的值应当大于或等于优选服务端的编号。

为了使得index的值大于或等于优选服务端的编号，根据每个优选服务端的编号，通过如下方式分别确定相应的随机权重系数k：

已知，目标编号、第一编号、第二编号、轮询步长、参考编号之间的关系满足公式：(1)index＝{sIndex+α+Rand(k×sNum/cNum)}MODsNum；为便于说明，假设优选服务端的编号为m；

由于参考随机数sNum/cNum的数值越大，能够得到的随机数数量就越多，目标编号index的取值范围就越大，所以，参考随机数sNum/cNum越大越好，但是不能超过第三数量；

为了使得目标编号index的取值范围包括m，即index≥m；

我们设Rand(k×sNum/cNum)＝x，上述公式(1)变化为：(2)index＝{sIndex+α+x}MODsNum；目标编号index最多能取值的范围是{sIndex+α，sIndex+α+1，......sNum}和{1，2,......sIndex-1}；

由于优选服务端的编号m与参考编号sIndex的大小会影响到公式(1)和(2)中的{sIndex+α+x}的值的大小，比如，m属于{sIndex+α，sIndex+α+1，......sNum}时，{sIndex+α+x}小于或等于sNum，m属于{1，2,......sIndex-1}时，{sIndex+α+x}大于sNum；所以，针对m的大小，会有三种不同的情况；

第一种，当m＝sIndex+α时，代入(2)中，x为0即可，由于Rand(k×sNum/cNum)＝x，所以，(k×sNum/cNum)只需大于或等于1，且小于第三数量即可；

第二种，当m属于{sIndex+α，sIndex+α+1，......sNum}时，求余算法得到的余数是原数据本身，即(2)会变化为：(3)index＝sIndex+α+x；将index≥m代入(3)中，可以得到sIndex+α+x≥m，进一步，可以得到(4)x≥m-sIndex-α，将k×sNum/cNum＝x代入(4)中，即可得到k≥(m-sIndex-α)×cNum/sNum；同时，由于调小后的参考随机数需要小于第三数量，所以，k＜(sNum-α)×cNum/sNum；

第三种，m属于{1，2,......sIndex-1}时，求余算法得到的余数小于sIndex，即(2)会变化为：(5)index＝sIndex+α+x-sNum，将k×sNum/cNum＝x代入(5)中，即可得到k≥(m+sNum-sIndex-α)×cNum/sNum；同时，由于调小后的参考随机数需要小于第三数量，所以，k＜(sNum-α)×cNum/sNum。

综上，确定调小参考随机数的随机权重系数的方法包括：基于优选编号与参考编号、轮询步长等之间的关系不同，随机权重系数k的取值不同。具体而言，当优选服务端的编号大于参考编号与轮询步长之和时，k≥(m-sIndex-α)×cNum/sNum，且k＜(sNum-α)×cNum/sNum；或者，当优选服务端的编号等于参考编号与轮询步长之和时，k≥cNum/sNum，且k＜(sNum-α)×cNum/sNum；或者，当优选服务端的编号小于参考编号与轮询步长之和时，k≥(m+sNum-sIndex-α)×cNum/sNum，且k＜(sNum-α)×cNum/sNum。

基于上述方案，在确定优选服务端的编号后，通过优选服务端的编号、第一数量、第二数量、轮询步长和参考编号，即可计算得到随机权重系数k的取值范围。

在本实施例中，由于只需要目标编号的区间范围包括至少一个优选服务端的编号，所以，可以针对每个优选服务端的编号分别确定相应的随机权重系数的取值范围，选取任一取值范围内的任一随机权重系数对参考随机数进行调小即可。一种优选的实施例中，可以选取所有取值范围内中数值最小的随机权重系数对参考随机数进行调小。

本算法结合随机和轮询两种负载均衡算法，相较于轮询算法以固定步长来确定下一次访问请求发送到的服务端，本方案中增加了随机数，避免将访问请求发送到同一服务端的调度设备再次转发访问请求时，还是将访问请求都发送到另一服务端中，导致出现并发冲突；相较于加权随机算法，单纯的加权随机算法是不限制随机数的数值，随机数与参考编号相加或者其他运算方式后得到目标编号，目标编号可以是任意值，即最终确定的目标服务端可以是任一服务端，本方案中增加固定步长的轮询步长，使得生成的随机数小于第三数量，使得确定的目标服务端不是在先一次调度设备的访问请求发送到的服务端，引入服务端数、调度设备数、在先接收到的访问请求发送到的服务端的序号，按照随机间隔方式轮询服务实例,得到目标服务端的序号，以实现避免热点的产生，均衡发送到各个服务端的访问请求的数量。

具体的，如图7所示，圆球为服务端，两个请求1为两个不同调度设备在先一次接收到的访问请求，两个调度设备都将访问请求发送给了第一个服务端，若是两个调度设备都采用轮询算法，那这两个调度设备当前接收到的访问请求2，按照轮询算法也会发送到同一服务端中，但是，由于本方案中还参考了随机数，这能够打散流量，避免轮询算法导致的并发冲突问题，示例性的，最终两个调度设备接收到的请求2，分别发送给了第五个服务端和第六个服务端，上述举例是为了说明本方案的效果，并不做特别限定；相较于加权随机算法，本方案中增加固定步长的轮询步长，使得生成的随机数小于第三数量，使得确定的目标服务端不是在先一次调度设备的访问请求发送到的服务端，本方案综合轮询算法和随机算法，规避了轮询算法和随机算法中的问题，使得访问请求可以平均的分配到各个服务端中，避免了热点服务应用的产生，减少了请求处理冲突，提升了应用服务的资源利用率。

如图8所示，本发明实施例提供了一种请求调度方法。与上述实施例相比，区别在于，参照图8，调度方法包括如下步骤：

S81、获取目标服务端响应于访问请求的反馈信息；其中，反馈信息中包括：用于表示任务状态的返回码。

在本实施例中，在将访问请求发送至目标服务端后，接收目标服务端反馈的响应于访问请求的反馈信息，反馈信息包括返回码和结果信息，其中，结果信息是服务端根据访问请求运行得到的结果，和对应该结果的运行状态返回码，比如，正常运行结束得到的返回码为任务结束，服务端繁忙无法处理访问请求时得到的返回码为繁忙，还有其他情况得到的返回码，返回码可以根据各个运行结果进行预先设置，并设置返回码和运行结果的对应表。

S82、当返回码用于指示任务状态为服务异常时，重新确定新的目标服务端，并向新的目标服务端发送所述访问请求。

在本实施例中，当确定返回码用于指示任务状态为服务异常时，则说明访问请求发送至服务端后，服务端并未完成处理，所以在本步骤中，重新确定新的目标服务端，将访问请求发送至新的目标服务端，具体的，由于返回码是反馈至客户端，所以可以由客户端再次将访问请求发送至调度设备，由调度设备进行重新调度。

在本实施例中,S82中当返回码用于指示任务状态为服务异常时，重新确定目标服务端，将访问请求发送至新的目标服务端，包括如下步骤：

在服务异常为服务端繁忙之外的其他服务异常时，将目标服务端的对象信息从服务端信息列表中剔除；在剔除后的服务端信息列表中，重新确定新的目标服务端，将所述访问请求发送至所述新的目标服务端。

在本实施例中，当确定返回码用于指示任务状态为服务端繁忙时，可以确定，该服务端可以正常运行，但是该服务端可能只是暂时处于忙碌状态，所以，此时不对服务端信息列表进行更新，将访问请求发送至新的目标服务端来处理访问请求，直至访问请求都被正常处理；当确定返回码用于指示任务状态为服务端繁忙之外的其他服务异常时，说明该服务端应该无法处理访问请求，此时，将该目标服务端的对象信息从服务端信息列表中剔除，剔除过后，上述实施例中根据服务端信息列表确定的第二数量就会相应减少，而且通过该服务端信息列也无法再选择到被剔除的目标服务端，可以避免访问请求发送到服务异常的服务端中，提高数据处理效率。

具体的，比如，客户端***处理返回码，分别执行不同的处理流程。返回码为任务结束时，客户端***正常处理后续流程。返回码为服务异常时，服务异常是繁忙，客户端可以再次执行上述实施例的流程，重新发起请求；服务异常是其他异常，从可用服务端信息列表中暂时排除该服务端，然后再次执行上述流程，重新发起请求。

具体的，在本方案中，调度***访问服务端***，实现服务发现和负载均衡。首先获取可用的服务实例信息列表，运行负载均衡算法，获取服务实例序号，从服务实例信息列表中读取序号对应的服务实例信息，然后根据服务实例信息中的实际网络地址(VI P)替换请求信息(request)中的虚拟目标地址，访问服务，最后根据服务实例返回结果更新服务实例信息列表。

在一个具体的实施例中，本方案包括：初始化过程和执行过程；

初始化过程：各调度设备***在初始化阶段配置运行期参数，执行算法信息等，完成负载均衡管理、服务实例发现、服务实例更新、服务实例选择和请求重试处理等功能。

本模块实现过程主要包括：

a.运行参数和待执行算法加载

各***读取统一配置管理***，获取当前调度设备上次访问服务实例序号、调度设备数量、服务端数量和服务实例信息列表、执行算法内容等信息；

b.服务实例信息列表读取

调度设备启动时从数据库读取服务实例信息列表，调度设备实例运行过程中，还会实时读取消息中间件中的实例变更信息，更新服务实例信息列表。

具体的，初始化过程可以参考如图4所示实施例中和如图8所示实施例的S82中的表述，本方案对此不再赘述。

执行过程：当调度设备有请求访问服务实例时，在访问服务实例之前执行本过程，完成实际访问服务实例信息获取。

a.负载均衡算法执行

调度设备***执行随机步长算法，利用调度设备数量、上次访问实例序号和服务实例数量(具体计算过程见公式)，计算出下次请求目的服务实例的序号，并从服务实例列表中读取对应的服务实例信息；

具体的，负载均衡算法执行的过程可以参考如图4所示实施例公开的方案或者参考如图5所示实施例公开的方案，本方案对此不再赘述；

b.服务请求信息替换

访问请求信息(request)中，只有虚拟目的地址，利用第一步获取的服务实例信息，替换为实际服务实例的网络地址(i p)和端口(port)；

具体的，服务请求信息替换的过程可以参考如图3所示实施例公开的方案，本方案对此不再赘述；

c.访问服务实例

调度设备根据最新的请求信息(request)，请求目标服务，获取返回码和结果信息；

d.更新服务实例返回结果

调度设备***处理返回码，分别执行不同的处理流程。返回码为任务结束时，调度设备***正常处理后续流程。返回码为实例异常时，实例异常是繁忙，调度设备再次执行上述流程，重新发起请求；实例异常是其他异常，从可用服务实例信息列表中暂时排除该服务实例，然后再次执行上述流程，重新发起请求；

具体的，c访问服务实例和d更新服务实例返回结果的过程可以参考如图8所示实施例公开的方案，本方案对此不再赘述。

如图9所示，本发明实施例提供了一种请求调度装置，应用于调度***中的调度设备，调度装置包括：获取单元11、处理单元12和发送单元13。

在本实施例中，获取单元11，用于当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端；

在本实施例中，处理单元12，用于基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致；

在本实施例中，发送单元13，用于将所述访问请求发送至所述目标服务端。

在本实施例中，调度装置还包括：第二获取单元，用于获取第一数量与第二数量；其中，所述第一数量为当前转发访问请求至服务***的调度设备的数量；所述第二数量为所述服务***中服务端的数量。

具体的，在本实施例中，第二获取单元，可以获取能够正常提供服务的服务端列表或服务端异常被剔除的服务端列表，基于服务端列表得到第二数量，而调度设备的数量可以由调度设备的配置信息或预先存储的调度设备数量信息确定调度设备的数量。

在本实施例中，调度装置还包括：随机数生成单元，用于，根据所述第一数量和所述第二数量，生成所述随机数。

具体的，在本实施例中，所述轮询步长小于所述第二数量；所述随机数小于第三数量；所述第三数量为所述第二数量与轮询步长的差值。

在本实施例中，随机数生成单元，具体用于将所述第二数量除以第一数量，得到参考随机数；若所述参考随机数小于所述第三数量，且所述参考随机数大于或者等于1，则根据所述参考随机数生成所述随机数；若所述参考随机数小于1，则调大所述参考随机数，使得调大后的参考随机数大于或等于1，且调大后的参考随机数小于所述第三数量，并根据调大后的参考随机数生成所述随机数；若所述参考随机数大于或等于所述第三数量，则通过随机权重系数，调小所述参考随机数，使得调小后的参考随机数大于或等于1，且调小后的参考随机数小于所述第三数量，并根据调小后的参考随机数生成所述随机数。

在本实施例中，随机数生成单元，具体用于获取各个服务端对访问请求的处理能力，根据所述处理能力确定服务端中的优选服务端；其中，所述优选服务端的处理能力高于各个服务端的处理能力的平均值；根据所述优选服务端的编号、所述参考编号和所述参考随机数，确定所述随机权重系数；通过随机权重系数，调小所述参考随机数，根据调小后的参考随机数生成所述随机数，使得基于所述参考随机数生成的随机数得到的目标编号的区间范围包括至少一个优选服务端的编号。

在本实施例中，发送单元13，具体用于获取所述目标服务端的网络地址，作为目标地址；将所述访问请求中携带的虚拟地址替换为所述目标地址；向所述目标服务端发送替换后的访问请求。

在本实施例中，调度装置还包括：反馈响应单元，用于获取所述目标服务端响应于所述访问请求的反馈信息；当所述返回码用于指示任务状态为服务异常时，重新确定新的目标服务端，并向新的目标服务端发送所述访问请求；其中，所述反馈信息中包括：用于表示任务状态的返回码。

在本实施例中，反馈响应单元，具体用于在所述服务异常为服务端繁忙之外的其他服务异常时，将所述目标服务端的对象信息从服务端信息列表中剔除；在剔除后的服务端信息列表中，重新确定新的目标服务端，将所述访问请求发送至所述新的目标服务端。

本发明实施例的装置的功能已经在上述的方法实施例中进行了描述，故本实施例的描述中未详尽之处，可以参见前述实施例中的相关说明，在此不做赘述。

如图10所示，本发明实施例提供了一种请求调度装置，包括处理器1110、通信接口1120、存储器1130和通信总线1140，其中，处理器1110，通信接口1120，存储器1130通过通信总线1140完成相互间的通信；

存储器1130，用于存放计算机程序；

处理器1110，用于执行存储器1130上所存放的程序时，实现上述任一实施例的请求调度方法。

上述实施例中提到的“第一”、“第二”的前缀仅为了表示不同***中的电子元器件，其其本身没有特定的意义，而使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特定的意义。因此，“模块”、“部件”或“单元”可以混合地使用。

本发明实施例提供的电子设备，处理器1110通过执行存储器1130上所存放的程序实现了通过获取在先一次的访问请求所发送的参考服务端，通过轮询步长、随机数和参考服务端的参考编号，确定目标编号，保证目标编号与所述参考编号不一致，并由目标编号来确定目标服务端，本方案中结合轮询算法和随机算法，来确定目标编号，通过轮询步长保证目标编号与参考编号相比会有改变，通过随机数来解决以固定步长来确定目标编号的问题，规避单纯依靠轮询算法经常出现的访问请求发送到同一服务端的调度设备再次转发访问请求时，还是将访问请求都发送到另一服务端中的问题，避免出现热点服务端，造成服务端的负载过大的情况。

上述电子设备提到的通信总线1140可以是外设部件互连标准(Per iphera lComponent I nterconnect，简称PCI)总线或扩展工业标准结构(Extended IndustryStandardArchitecture，简称EI SA)总线等。该通信总线1140可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口1120用于上述电子设备与其他设备之间的通信。

存储器1130可以包括随机存取存储器(RandomAccessMemory，简称RAM)，也可以包括非易失性存储器(non-vo l at i l ememory)，例如至少一个磁盘存储器。可选的，存储器1130还可以是至少一个位于远离前述处理器1110的存储装置。

上述的处理器1110可以是通用处理器，包括中央处理器(Centra l Process ingUn it，简称CPU)、网络处理器(NetworkProcessor，简称NP)等；还可以是数字信号处理器(Digita l Signa l Process i ng，简称DSP)、专用集成电路(App l icat i onSpecificI ntegratedCi rcuit，简称ASI C)、现场可编程门阵列(Fie l d-Programmab leGateArray，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本发明实施例提供了一种计算机可读存储介质，其特征在于，计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现上述任一实施例的方法。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本发明实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务端或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务端或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务端、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘So l i dStateDi sk(SSD))等。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (9)

1.一种请求调度方法，其特征在于，应用于调度设备，所述调度方法包括：

当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端；

获取第一数量与第二数量，其中，所述第一数量为当前转发访问请求至服务***的调度设备的数量；所述第二数量为所述服务***中服务端的数量；

根据所述第一数量和所述第二数量，生成随机数；

基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致；

将所述访问请求发送至所述目标服务端。

2.根据权利要求1所述的调度方法，其特征在于，

所述轮询步长小于所述第二数量；

所述随机数小于第三数量；所述第三数量为所述第二数量与轮询步长的差值。

3.根据权利要求2所述的调度方法，其特征在于，所述根据所述第一数量和所述第二数量，生成所述随机数，包括：

将所述第二数量除以第一数量，得到参考随机数；

若所述参考随机数小于所述第三数量，且所述参考随机数大于或者等于1，则根据所述参考随机数生成所述随机数；

若所述参考随机数小于1，则调大所述参考随机数，使得调大后的参考随机数大于或等于1，且调大后的参考随机数小于所述第三数量，并根据调大后的参考随机数生成所述随机数；

若所述参考随机数大于或等于所述第三数量，则通过随机权重系数，调小所述参考随机数，使得调小后的参考随机数大于或等于1，且调小后的参考随机数小于所述第三数量，并根据调小后的参考随机数生成所述随机数。

4.根据权利要求3所述的调度方法，其特征在于，所述通过随机权重系数，调小所述参考随机数，根据调小后的参考随机数生成所述随机数，包括：

获取各个服务端对访问请求的处理能力，根据所述处理能力确定服务端中的优选服务端；其中，所述优选服务端的处理能力高于各个服务端的处理能力的平均值；

根据所述优选服务端的编号、所述参考编号和所述参考随机数，确定所述随机权重系数；

通过随机权重系数，调小所述参考随机数，根据调小后的参考随机数生成所述随机数，使得基于所述参考随机数生成的随机数得到的目标编号的区间范围包括至少一个优选服务端的编号。

5.根据权利要求1～4中任一所述调度方法，其特征在于，所述调度方法还包括：

获取所述目标服务端响应于所述访问请求的反馈信息；其中，所述反馈信息中包括：用于表示任务状态的返回码；

当所述返回码用于指示任务状态为服务异常时，重新确定新的目标服务端，并向新的目标服务端发送所述访问请求。

6.根据权利要求5所述的调度方法，其特征在于，所述当所述返回码用于指示任务状态为服务异常时，重新确定目标服务端，将所述访问请求发送至新的所述目标服务端，包括：

在所述服务异常为服务端繁忙之外的其他服务异常时，将所述目标服务端的对象信息从服务端信息列表中剔除；

在剔除后的服务端信息列表中，重新确定新的目标服务端，将所述访问请求发送至所述新的目标服务端。

7.一种请求调度装置，其特征在于，应用于调度设备，所述调度装置包括：

获取单元，用于当接收到任一客户端的访问请求时，获取在先一次接收到的访问请求所发送到的服务端，作为参考服务端；

第二获取单元，用于获取第一数量与第二数量；其中，所述第一数量为当前转发访问请求至服务***的调度设备的数量；所述第二数量为所述服务***中服务端的数量；

随机数生成单元，用于根据所述第一数量和所述第二数量，生成随机数；

处理单元，基于所述参考服务端的参考编号、随机数和轮询步长之和，确定目标编号，并根据所述目标编号确定目标服务端；所述参考编号与所述目标编号不一致；

发送单元，用于将所述访问请求发送至所述目标服务端。

8.一种请求调度装置，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现权利要求1～6中任一所述的请求调度方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有一个或者多个程序，所述一个或者多个程序可被一个或者多个处理器执行，以实现权利要求1～6中任一所述的请求调度方法。