请求处理方法、装置、服务器及存储介质
技术领域
本公开涉及计算机技术领域，尤其涉及一种请求处理方法、装置、服务器及存储介质。
背景技术
当服务器接收到的请求的数量骤增，而服务器当前的资源不足以同时处理接收到的大量请求时，可以对请求的处理进行限制，也即限流，以避免服务器因大量请求的涌入而崩溃。随着分布式服务的发展，一项服务可以分布在服务器集群的多台服务器上运行，每台运行该项服务的服务器向外提供有至少一个接口，在分布式服务中，需要对任一项服务的任一接口进行限流。
相关技术中，对于任一项服务的任一接口，可以根据该接口在服务器集群上的总QPS(Queries-per-second，每秒请求数)，对该接口处理的请求数量进行限制。如果该接口每秒接收到的请求数不大于该接口的限流阈值，则服务器集群正常处理接收到的请求；如果该接口每秒接收到的请求数大于该接口的限流阈值，则服务器集群拒绝处理超出限流阈值的请求。
上述过程中，如果某一接口的请求处理时间存在异常的延长，且该接口每秒接收到的请求数不大于该接口的限流阈值，服务器集群不会对该接口进行限流。但是，由于请求处理时间的延长，该接口会占用过多的请求处理资源，导致其他接口难以获取到空闲的请求处理资源进行请求的处理，出现处理异常的情况，进而导致服务器集群处理请求的稳定性较差。
发明内容
本公开实施例提供了一种请求处理方法、装置、服务器及存储介质，能够提高服务器集群的稳定性。本公开的技术方案如下：
一方面，提供了一种请求处理方法，应用于服务器集群中的第一服务器，所述方法包括：
响应于对服务器集群中的第二服务器的目标接口的调用请求，确定所述目标接口对应的调用请求数量参数，所述调用请求数量参数用于表示所述服务器集群中未处理完成的所述调用请求的数量；
更新所述调用请求数量参数；
控制所述第二服务器在所述调用请求数量参数大于或等于所述目标接口的目标阈值的条件下丢弃所述调用请求，再次更新所述调用请求数量参数，其中，所述目标阈值为所述服务器集群中能够处理的所述调用请求的最大数量。
在一种可能的实现方式中，所述响应于对服务器集群中的第二服务器的目标接口的调用请求，确定所述目标接口对应的调用请求数量参数，包括：
响应于对服务器集群中的第二服务器的目标接口的调用请求，获取所述调用请求的接收时间；
根据所述接收时间，确定所述目标接口在所述接收时间关联的时间段内对应的调用请求数量参数。
在另一种可能的实现方式中，所述根据所述接收时间，确定所述目标接口在所述接收时间关联的时间段内对应的调用请求数量参数，包括：
确定所述接收时间所在的第一时间段；
从所述目标接口对应的多个调用请求数量参数中，确定所述第一时间段对应的调用请求数量参数，所述多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量。
在另一种可能的实现方式中，所述根据所述接收时间，确定所述目标接口在所述接收时间关联的时间段内对应的调用请求数量参数，包括：
确定所述接收时间所在的第一时间段；
响应于所述接收时间与所述第一时间段的起始时间之间的时间差小于时间差阈值，从所述目标接口对应的多个调用请求数量参数中，确定所述第一时间段对应的调用请求数量参数和所述第二时间段对应的调用请求数量参数，所述多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量，所述第二时间段为与所述第一时间段相邻的上一时间段；
获取所述第一时间段对应的调用请求数量参数与所述第二时间段对应的调用请求数量参数的和值，作为所述目标接口在所述接收时间关联的时间段内对应的调用请求数量参数。
在另一种可能的实现方式中，所述更新所述调用请求数量参数，包括：
在所述调用请求数量参数的基础上，增加预设数值，所述预设数值用于表示发生变化的所述调用请求的数量；
所述再次更新所述调用请求数量参数，包括：
在所述调用请求数量参数的基础上，减少所述预设数值。
在另一种可能的实现方式中，所述控制所述第二服务器在所述调用请求数量参数大于或等于所述目标接口的目标阈值的条件下丢弃所述调用请求，再次更新所述调用请求数量参数，包括：
响应于所述调用请求数量参数大于或等于所述目标接口的目标阈值，向所述第二服务器发送丢弃指令，所述丢弃指令用于指示所述第二服务器丢弃所述调用请求；
响应于所述第二服务器对所述调用请求的第一丢弃信息，再次更新所述调用请求参数，所述第一丢弃信息用于表示所述第二服务器已丢弃所述调用请求。
在另一种可能的实现方式中，所述控制所述第二服务器在所述调用请求数量参数大于或等于所述目标接口的目标阈值的条件下丢弃所述调用请求，再次更新所述调用请求数量参数，包括：
向所述第二服务器发送所述调用请求数量参数；
响应于接收到所述第二服务器对所述调用请求的第二丢弃信息，再次更新所述调用请求参数，所述第二丢弃信息用于表示所述第二服务器确定所述调用请求数量参数大于或等于所述目标接口的目标阈值，已丢弃所述调用请求。
一方面，提供了一种请求处理装置，应用于服务器集群中的第一服务器，所述装置包括：
确定单元，被配置为执行响应于对服务器集群中的第二服务器的目标接口的调用请求，确定所述目标接口对应的调用请求数量参数，所述调用请求数量参数用于表示所述服务器集群中未处理完成的所述调用请求的数量；
第一更新单元，被配置为执行更新所述调用请求数量参数；
控制单元，被配置为执行控制所述第二服务器在所述调用请求数量参数大于或等于所述目标接口的目标阈值的条件下丢弃所述调用请求；
第二更新单元，被配置为执行再次更新所述调用请求数量参数，其中，所述目标阈值为所述服务器集群中能够处理的所述调用请求的最大数量。
在一种可能的实现方式中，所述确定单元，包括：
获取子单元，被配置为执行响应于对服务器集群中的第二服务器的目标接口的调用请求，获取所述调用请求的接收时间；
确定子单元，被配置为执行根据所述接收时间，确定所述目标接口在所述接收时间关联的时间段内对应的调用请求数量参数。
在另一种可能的实现方式中，所述确定子单元，被配置为执行：
确定所述接收时间所在的第一时间段；
从所述目标接口对应的多个调用请求数量参数中，确定所述第一时间段对应的调用请求数量参数，所述多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量。
在另一种可能的实现方式中，所述确定子单元，被配置为执行：
确定所述接收时间所在的第一时间段；
响应于所述接收时间与所述第一时间段的起始时间之间的时间差小于时间差阈值，从所述目标接口对应的多个调用请求数量参数中，确定所述第一时间段对应的调用请求数量参数和所述第二时间段对应的调用请求数量参数，所述多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量，所述第二时间段为与所述第一时间段相邻的上一时间段；
获取所述第一时间段对应的调用请求数量参数与所述第二时间段对应的调用请求数量参数的和值，作为所述目标接口在所述接收时间关联的时间段内对应的调用请求数量参数。
在另一种可能的实现方式中，所述第一更新单元，被配置为执行：
在所述调用请求数量参数的基础上，增加预设数值，所述预设数值用于表示发生变化的所述调用请求的数量；
所述第二更新单元，被配置为执行：
在所述调用请求数量参数的基础上，减少所述预设数值。
在另一种可能的实现方式中，所述控制单元，被配置为执行：
响应于所述调用请求数量参数大于或等于所述目标接口的目标阈值，向所述第二服务器发送丢弃指令，所述丢弃指令用于指示所述第二服务器丢弃所述调用请求；
响应于所述第二服务器对所述调用请求的第一丢弃信息，再次更新所述调用请求参数，所述第一丢弃信息用于表示所述第二服务器已丢弃所述调用请求。
在另一种可能的实现方式中，所述控制单元，被配置为执行：
向所述第二服务器发送所述调用请求数量参数；
响应于接收到所述第二服务器对所述调用请求的第二丢弃信息，再次更新所述调用请求参数，所述第二丢弃信息用于表示所述第二服务器确定所述调用请求数量参数大于或等于所述目标接口的目标阈值，已丢弃所述调用请求。
一方面，提供了一种服务器，所述服务器包括：一个或多个处理器；用于存储所述处理器可执行指令的存储器；其中，所述处理器被配置为执行所述指令，以实现上述任一可能的实现方式所述的请求处理方法。
一方面，提供了一种存储介质，当所述存储介质中的指令由服务器的处理器执行时，使得服务器能够执行上述任一可能的实现方式所述的请求处理方法。
一方面，提供了一种计算机程序产品，当所述计算机程序产品中的指令由服务器的处理器执行时，使得服务器能够执行上述任一可能的实现方式所述的请求处理方法。
在本公开实施例中，第一服务器通过调用请求数量参数表示对服务器集群中任一接口的调用请求的数量，在第二服务器接收到对某一接口的调用请求时，更新调用请求数量参数，在第二服务器对该调用请求处理完成之后，再次更新该调用请求数量参数，使得该调用请求数量参数能够在任一时刻表示对服务器集群中该接口的调用请求的数量。如果该接口的请求处理时间存在异常的延长，则该接口的调用请求数量参数会随着接收到的调用请求的增多而增大，并且，由于请求处理时间的延长，该调用请求数量参数的减少会变得缓慢，从而该调用请求数量参数会在短时间内快速增加而达到服务器集群能够处理的调用请求的最大数量，触发第二服务器对调用请求的限流处理，减少该接口由于请求处理时间的异常延长而占用的资源，减少对其他接口的影响，提高服务器集群的稳定性。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种服务器集群的示意图；
图2是根据一示例性实施例示出的一种请求处理方法的流程图；
图3是根据一示例性实施例示出的一种请求处理方法的流程图；
图4是根据一示例性实施例示出的一种请求处理方法的流程图；
图5是根据一示例性实施例示出的一种请求处理方法的流程图；
图6是根据一示例性实施例示出的一种确定调用请求数量参数的示意图；
图7是根据一示例性实施例示出的一种请求处理方法的流程图；
图8是根据一示例性实施例示出的一种确定调用请求数量参数的示意图；
图9是根据一示例性实施例示出的一种请求处理装置的框图；
图10是根据一示例性实施例示出的一种服务器的框图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
图1是根据一示例性实施例示出的一种服务器集群的示意图。参见图1，该服务器集群100包括至少一个第一服务器101和多个第二服务器102。
其中，第一服务器101泛指至少一个第一服务器中的一个，第二服务器102泛指多个第二服务器中的一个。多个第二服务器102上同时部署有一项服务，每个第二服务器102向外提供该项服务的接口。终端或者其他服务器通过向服务器集群100中的第二服务器102发送调用请求，请求调用该项服务的接口，以得到相应的返回数据。
第一服务器101在服务器集群100中至少承担请求计数功能。第一服务器101与第二服务器102通过无线或者有线网络连接。第一服务器101通过与第二服务器102的交互，进行请求计数，确定服务器集群中未处理完成的调用请求的数量；进而在服务器集群中未处理完成的调用请求的数量大于该服务器集群能够处理的调用请求的最大数量时，对调用请求进行限流处理。
图2是根据一示例性实施例示出的一种请求处理方法的流程图。参见图2，该请求处理方法应用于服务器集群中的第一服务器，包括以下步骤：
在步骤S201中，响应于对服务器集群中的第二服务器的目标接口的调用请求，确定目标接口对应的调用请求数量参数，该调用请求数量参数用于表示服务器集群中未处理完成的调用请求的数量。
在步骤S202中，更新该调用请求数量参数。
在步骤S203中，控制第二服务器在该调用请求数量参数大于或等于目标接口的目标阈值的条件下丢弃调用请求，再次更新调用请求数量参数，其中，目标阈值为服务器集群中能够处理的调用请求的最大数量。
在本公开实施例中，第一服务器通过调用请求数量参数表示对服务器集群中任一接口的调用请求的数量，在第二服务器接收到对某一接口的调用请求时，更新调用请求数量参数，在第二服务器对该调用请求处理完成之后，再次更新该调用请求数量参数，使得该调用请求数量参数能够在任一时刻表示对服务器集群中该接口的调用请求的数量。如果该接口的请求处理时间存在异常的延长，则该接口的调用请求数量参数会随着接收到的调用请求的增多而增大，并且，由于请求处理时间的延长，该调用请求数量参数的减少会变得缓慢，从而该调用请求数量参数会在短时间内快速增加而达到服务器集群能够处理的调用请求的最大数量，触发第二服务器对调用请求的限流处理，减少该接口由于请求处理时间的异常延长而占用的资源，减少对其他接口的影响，提高服务器集群的稳定性。
图3是根据一示例性实施例示出的一种请求处理方法的流程图。在本公开实施例中，以第二服务器基于第一服务器发送的调用请求数量参数对调用请求进行限流处理为例进行说明，参见图3，该请求处理方法包括以下步骤：
在步骤S301中，第一服务器响应于对服务器集群中的第二服务器的目标接口的调用请求，确定该目标接口对应的调用请求数量参数。
其中，调用请求数量参数用于表示服务器集群中未处理完成的调用请求的数量，上述调用请求用于请求调用目标接口。服务器集群通过至少一个接口向其他终端或服务器提供至少一项服务，在本公开实施例中，以目标接口为上述至少一个接口中的任意一个为例进行说明。
在一种可能的实现方式中，第二服务器接收到对目标接口的调用请求，向第一服务器发送请求计数指令，该请求计数指令用于表示第二服务器接收到对目标接口的调用请求；第一服务器响应于请求计数指令，确定目标接口对应的调用请求数量参数。
其中，第一服务器对应存储有目标接口和调用请求数量参数的对应关系，第一服务器响应于请求计数指令，从已存储的目标接口和调用请求数量参数的对应关系中，确定目标接口对应的调用请求数量参数。可选地，第一服务器部署有redis(remote dictionaryserver，远程字典服务)，基于redis对应存储目标接口和调用请求数量参数。
在步骤S302中，第一服务器在所确定的调用请求数量参数的基础上，增加预设数值，该预设数值用于表示发生变化的调用请求的数量。
例如，第二服务器接收到对目标接口的一个调用请求，向第一服务器发送请求计数指令，第一服务器确定目标接口对应的调用请求数量参数为28；在该调用请求数量参数的基础上，增加1，得到更新后的调用请求数量参数29。
在步骤S303中，第一服务器向第二服务器发送增加预设数值后的调用请求数量参数。
增加预设数值后的调用请求数量参数用于表示当前服务器集群中未处理完成的对目标接口的调用请求的数量。其中，当前服务器集群中未处理完成的对目标接口的调用请求包括步骤S301中第二服务器接收到的调用请求。
第一服务器向第二服务器发送增加预设数值后的调用请求数量参数，以使第二服务器能够基于该增加预设数值后的调用请求数量参数，对调用请求进行相应的处理。
在步骤S304中，第二服务器接收第一服务器发送的调用请求数量参数，响应于该调用请求数量参数大于或等于目标接口的目标阈值，丢弃该调用请求。
其中，目标阈值为服务器集群中能够处理的调用请求的最大数量。目标阈值为预设的任一数值，例如，目标阈值为500、800或者1000等。可选地，第二服务器对应存储目标接口与目标阈值的对应关系，第二服务器接收目标接口对应的调用请求数量参数，从已存储的目标接口与目标阈值的对应关系中，确定目标接口对应的目标阈值。
第二服务器比较调用请求数量参数和目标阈值；若调用请求数量参数大于或等于目标阈值，则表示服务器集群中未处理完成的调用请求的数量已达到服务器集群处理调用请求的上限，第二服务器不再继续处理步骤S301中接收到的调用请求，也即丢弃该调用请求。
需要说明的是，若调用请求数量参数小于目标阈值，则第二服务器继续按照目标接口的处理逻辑，处理该调用请求。
在步骤S305中，第二服务器向第一服务器发送第二丢弃信息，第二丢弃信息用于表示第二服务器已丢弃该调用请求。
第二服务器确定丢弃调用请求之后，向第一服务器发送第二丢弃信息，以使第一服务器基于该第二丢弃信息，再次更新调用请求数量参数，使得调用请求数量参数在任一时刻都能够表示服务器集群未处理完成的调用请求的数量。
需要说明的一点是，若第二服务器按照目标接口的处理逻辑，处理该调用请求，则第二服务器在按照目标接口的处理逻辑对该调用请求处理完成后，向第一服务器发送处理完成信息。
在步骤S306中，第一服务器接收第二丢弃信息，在调用请求数量参数的基础上，减少预设数值。
需要说明的是，目标接口对应的调用请求数量参数在其所表示的未处理完成的调用请求处理完成时，会进行相应的更新。那么，第一服务器在接收到第二丢弃信息时，调用请求数量参数可能会由于其他调用请求处理完成，相较于步骤S302得到的调用请求数量参数已发生变化，则第一服务器基于第二丢弃信息，对已发生变化的调用请求数量参数进行更新。
例如，步骤S302得到的更新后的调用请求数量参数为29，在第一服务器接收到第二丢弃信息之前，第二服务器对3个调用请求处理完成，则在步骤S306中，第一服务器基于第二丢弃信息，在已变化的调用请求数量参数26的基础上，减少1，得到更新后的调用请求数量参数25。
需要说明的是，若第一服务器接收到第一服务器的处理完成信息，则在调用请求数量参数的基础上，减少预设数值。第一服务器接收处理完成信息，在调用请求数量参数的基础上，减少预设数值的步骤与第二服务器接收第二丢弃信息，在调用请求数量参数的基础上，减少预设数值的步骤同理。
在本公开实施例中，第一服务器通过调用请求数量参数表示对服务器集群中任一接口的调用请求的数量，在第二服务器接收到对某一接口的调用请求时，更新调用请求数量参数，在第二服务器对该调用请求处理完成之后，再次更新该调用请求数量参数，使得该调用请求数量参数能够在任一时刻表示对服务器集群中该接口的调用请求的数量。如果该接口的请求处理时间存在异常的延长，则该接口的调用请求数量参数会随着接收到的调用请求的增多而增大，并且，由于请求处理时间的延长，该调用请求数量参数的减少会变得缓慢，从而该调用请求数量参数会在短时间内快速增加而达到服务器集群能够处理的调用请求的最大数量，触发第二服务器对调用请求的限流处理，减少该接口由于请求处理时间的异常延长而占用的资源，减少对其他接口的影响，提高服务器集群的稳定性。
图4是根据一示例性实施例示出的一种请求处理方法的流程图。在本公开实施例中，以第一服务器向第二服务器发送丢弃指令，控制第二服务器丢弃调用请求，从而实现限流为例进行说明，参见图4，该请求处理方法包括以下步骤：
在步骤S401中，第一服务器响应于对服务器集群中的第二服务器的目标接口的调用请求，确定该目标接口对应的调用请求数量参数。
步骤S401与步骤S301同理，在此不再赘述。
在步骤S402中，第一服务器在所确定的调用请求数量参数的基础上，增加预设数值，该预设数值用于表示发生变化的调用请求的数量。
步骤S402与步骤S302同理，在此不再赘述。
在步骤S403中，第一服务器响应于增加预设数值后的调用请求数量参数大于或等于目标接口的目标阈值，向第二服务器发送丢弃指令，该丢弃指令用于指示第二服务器丢弃该调用请求。
可选地，第一服务器存储有目标接口和目标阈值的对应关系。第一服务器从目标接口和目标阈值的对应关系中，确定目标接口的目标阈值；比较目标阈值和调用请求数量参数；若调用请求数量参数大于或等于目标阈值，则表示服务器集群中未处理完成的调用请求的数量已达到服务器集群处理调用请求的上限，向第二服务器发送丢弃指令，以使第二服务器丢弃该调用请求，不再对该调用请求进行处理。
需要说明的是，若调用请求数量参数小于目标阈值，则向第二服务器发送处理指令，以使第二服务器按照目标接口的处理逻辑对该调用请求进行处理。
在步骤S404中，第二服务器接收第一服务器发送的丢弃指令，丢弃该调用请求。
第二服务器接收到第一服务器发送的丢弃指令，不再继续处理该调用请求，也即丢弃该调用请求。
需要说明的是，若第二服务器接收到第一服务器发送的处理指令，则按照目标接口的处理逻辑对该调用请求进行处理。
在步骤S405中，第二服务器向第一服务器发送第一丢弃信息，该第一丢弃信息用于表示第二服务器已丢弃该调用请求。
步骤S405与步骤S305同理，在此不再赘述。
在步骤S406中，第一服务器接收第一丢弃信息，在调用请求数量参数的基础上，减少预设数值。
步骤S406与步骤S306同理，在此不再赘述。
在本公开实施例中，第一服务器通过调用请求数量参数表示对服务器集群中任一接口的调用请求的数量，在第二服务器接收到对某一接口的调用请求时，更新调用请求数量参数，在第二服务器对该调用请求处理完成之后，再次更新该调用请求数量参数，使得该调用请求数量参数能够在任一时刻表示对服务器集群中该接口的调用请求的数量。如果该接口的请求处理时间存在异常的延长，则该接口的调用请求数量参数会随着接收到的调用请求的增多而增大，并且，由于请求处理时间的延长，该调用请求数量参数的减少会变得缓慢，从而该调用请求数量参数会在短时间内快速增加而达到服务器集群能够处理的调用请求的最大数量，触发第二服务器对调用请求的限流处理，减少该接口由于请求处理时间的异常延长而占用的资源，减少对其他接口的影响，提高服务器集群的稳定性。
图5是根据一示例性实施例示出的一种请求处理方法的流程图。在本公开实施例中，以第一服务器按照时间段的划分，更新调用请求数量参数为例进行说明，参见图5，该请求处理方法包括以下步骤：
在步骤S501中，第一服务器响应于对服务器集群中的第二服务器的目标接口的调用请求，获取该调用请求的接收时间。
在一种可能的实现方式中，第二服务器接收到对目标接口的调用请求，向第一服务器发送请求计数指令，该请求计数指令用于表示第二服务器接收到对目标接口的调用请求，且该请求计数指令携带有该调用请求的接收时间；第一服务器基于请求计数指令，获取该调用请求的接收时间。
在步骤S502中，第一服务器确定该接收时间所在的第一时间段。
需要说明的是，目标接口对应有多个时间段，每个时间段对应有一个调用请求数量参数，每个时间段对应的调用请求数量参数用于记录该时间段内未处理完成的调用请求的数量。
在一种可能的实现方式中，目标接口对应有多个时间段，第一服务器可以从该多个时间段中，确定接收时间所在的第一时间段，相应的，上述步骤S502包括：第一服务器分别比较接收时间和目标接口对应的多个时间段；将接收时间所在的时间段确定为第一时间段。
例如，接收时间为2020年4月27日1时23分05秒，目标接口对应的一个时间段为2020年4月27日0时0分0秒至2020年4月27日2时0分0秒，该接收时间在该时间段内，该时间段为第一时间段。
在另一种可能的实现方式中，目标接口对应有多个时间段，第一服务器还可以根据上一次确定的第三时间段，从多个时间段中，确定接收时间所在的第一时间段，相应的，上述步骤S502包括：第一服务器从目标接口对应的多个时间段中，获取上一次确定的第三时间段；比较接收时间和第三时间段；响应于接收时间在第三时间段内，将第三时间段确定为接收时间所在的第一时间段；响应于接收时间不在第三时间段内，获取与第三时间段相邻，且在第三时间段之后的第四时间段；比较接收时间和第四时间段；响应于接收时间在第四时间段内，将第四时间段确定为接收时间所在的第一时间段。
在本公开实施例中，第一服务器以上一次确定的第三时间段为基准，确定接收时间所在的第一时间段。由于接收到调用请求的接收时间与上一次确定的第三时间段相近，以第三时间段为基准，进行接收时间与时间段的比较，能够减少接收时间与时间段的比较时间，快速确定出接收时间所在的第一时间段，提高第一时间段的确定效率。
在另一种可能的实现方式中，第一服务器也可以随着请求计数指令的接收，不断的为目标接口生成对应的时间段，相应的，上述步骤S502包括：第一服务器比较接收时间和目标接口对应的上一次生成的时间段；响应于接收时间在上一次生成的时间段内，将该上一次生成的时间段确定为第一时间段；响应于接收时间不在上一次生成的时间段内，生成目标接口对应的第一时间段，该第一时间段包括接收时间。
第一时间段为目标时长的时间段。第一服务器生成第一时间段的步骤可以为：第一服务器将接收时间作为第一时间段的起始时间，确定目标时长的时间段为第一时间段。第一服务器生成第一时间段的步骤也可以为：第一服务器将上一次生成的时间段的结束时间作为第一时间段的起始时间，确定目标时长的时间段为第一时间段。
例如，接收时间为2020年4月27日2时0分05秒，目标接口对应的上一次生成的时间段可以为2020年4月27日0时0分0秒至2020年4月27日2时0分0秒；第一服务器响应于接收时间不在上一次生成的时间段内，生成用于指示目标时长的时间段的第一时间段。该第一时间段的起始时间可以为接收时间，该第一时间段为2020年4月27日2时0分05秒至2020年4月27日4时0分05秒。该第一时间段的起始时间也可以为上一次生成的时间段的结束时间，该第一时间段为2020年4月27日2时0分0秒至2020年4月27日4时0分0秒。
在本公开实施例中，第一服务器随着请求计数指令的接收，生成接收时间所在的第一时间段，第一服务器每次接收到请求计数指令时，直接将接收时间与上一次生成的时间段进行比较即可，若接收时间不在上一次生成的时间段内，则生成第一时间段，减少了接收时间与多个时间段的比较时间，提高了第一时间段的确定效率。
在步骤S503中，第一服务器从目标接口对应的多个调用请求数量参数中，确定第一时间段对应的调用请求数量参数。
其中，多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量。每个调用请求数量参数与目标接口对应的一个时间段相对应。
在一种可能的实现方式中，第一服务器已存储有目标接口对应的时间段与调用请求数量参数的对应关系，则第一服务器从目标接口对应的多个时间段与调用请求数量参数的对应关系中，确定第一时间段对应的调用请求数量参数。
在另一种可能的实现方式中，第一时间段为最新生成的时间段，第一服务器还未存储第一时间段和调用请求数量参数的对应关系，则第一服务器对应存储该第一时间段与新的调用请求数量参数的对应关系。其中，新的调用请求数量参数的初始值为0。
在另一种可能的实现方式中，若调用请求的接收时间在第一时间段的起始的时间段内，第二时间段对应的调用请求数量参数所代表的调用请求还未处理结束，第一时间段对应的调用请求数量参数与目标接口真实未处理完成的调用请求的数量存在误差，因此，可以根据第一时间段对应的调用请求数量参数和第二时间段对应的调用请求数量参数，确定目标接口未处理完成的调用请求的数量。相应的，上述步骤S503还可以用以下步骤代替：第一服务器确定接收时间所在的第一时间段；响应于接收时间与第一时间段的起始时间之间的时间差小于时间差阈值，从目标接口对应的多个调用请求数量参数中，确定第一时间段对应的调用请求数量参数和第二时间段对应的调用请求数量参数，多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量，第二时间段为与第一时间段相邻的上一时间段；获取第一时间段对应的调用请求数量参数与第二时间段对应的调用请求数量参数的和值，作为目标接口在接收时间关联的时间段内对应的调用请求数量参数。
时间差阈值可以为预设的任一时长，例如，时间差阈值可以为5秒、8秒或者10秒。时间差阈值也可以根据第二服务器处理请求的时长确定，例如，第二服务器处理请求的平均时长为50毫秒，时间差阈值可以确定为50毫秒。
例如，图6是根据一示例性实施例示出的一种确定调用请求数量参数的示意图，参见图6，纵轴表示任一时刻的调用请求数量参数，横轴表示调用请求处理的时间线，每一个方框表示一个调用请求的请求处理时间段，该请求处理时间段以调用请求的接收时间开始到该调用请求的处理结束时间为止。
若第一时间段为时间段二，第二时间段为时间段一，在时间t3，第一服务器已在请求九的接收时间，针对请求九，增加了第一时间段对应的调用请求数量参数，在时间t3，第一时间段对应的调用请求数量参数为1。在时间t3，第一服务器针对请求一、请求二、请求三、请求四和请求五，已增加并且已减少了第二时间段对应的调用请求数量参数，并且，已针对请求六、请求七和请求八，增加了第二时间段对应的调用请求数量参数。在时间t3，第二时间段对应的调用请求数量参数为3。将第一时间段对应的调用请求数量参数和第二时间段对应的调用请求数量参数相加，得到的和值为4，与目标接口未处理完成的调用请求的数量相符。
在本公开实施例中，若调用请求的接收时间在第一时间段的起始的时间段内，则第一服务器将相邻两个时间段对应的调用请求数量参数的和值确定为目标接口未处理完成的调用请求的数量，使其与目标接口真实未处理完成的调用请求的数量相符，提高了第一服务器确定目标接口未处理完成的调用请求的数量的准确性，进而基于目标接口未处理完成的调用请求的数量进行限流，减少了错误限流情况的发生，提高了集群限流的稳定性。
需要说明的一点是，第二服务器可以按照调用请求的接收时间，生成该接收时间所在的时间段的时间段标识，将该时间段标识发送至第一服务器，以使第一服务器按照时间段标识，确定对应的调用请求数量参数。相应的，上述步骤S501至步骤S503可以由以下步骤代替：第二服务器接收对目标接口的调用请求；根据该调用请求的接收时间，确定该接收时间所在的第一时间段对应的时间段标识；向第一服务器发送请求计数指令，该请求计数指令携带有时间段标识；第一服务器接收请求计数指令；根据该请求计数指令携带的时间段标识，确定该时间段标识对应的调用请求数量参数。
可选地，第一服务器上部署有redis，第一服务器基于redis，以key(关键字)-value(值)的形式对应存储时间段标识和调用请求数量参数，其中，key表示时间段标识，value表示调用请求数量参数。图7是根据一示例性实施例示出的一种请求处理方法的流程图，参见图7，第二服务器接收调用请求，按照时间段生成目标接口对应的时间段标识；调用redis对时间段标识对应的调用请求数量参数进行累加。
在步骤S504中，第一服务器在第一时间段对应的调用请求数量参数的基础上，增加预设数值。
例如，第二服务器接收到对目标接口的一个调用请求，该调用请求的接收时间为2020年4月27日2时20分09秒，第二服务器向第一服务器发送携带有接收时间的请求计数指令，第一服务器确定该接收时间所在的第一时间段为2020年4月27日2时0分0秒至2020年4月27日4时0分0秒，该第一时间段对应的调用请求数量参数为5；则在该调用请求数量参数的基础上，增加1，得到更新后的调用请求数量参数6。
为了使调用请求数量参数更新的过程更加清晰，下面结合图6和图8进行说明。参见图6，第一服务器分别在请求九的接收时间、请求十的接收时间、请求十一的接收时间和请求十二的接收时间，增加第一时间段对应的调用请求数量参数。在第一时间段内的时间t4，第二服务器已经分别针对请求九、请求十和请求十一，增加了第一时间段对应的调用请求数量参数。在时间t4，第一时间段对应的调用请求数量参数为3。
图8是根据一示例性实施例示出的一种确定调用请求数量参数的示意图，参见图8，第一服务器未按照时间段的划分分别对目标接口的调用请求进行计数，也即目标接口仅对应有一个无限长的时间段。在时间t1，目标接口正在处理的调用请求包括请求一、请求二、请求三和请求四，目标接口对应的调用请求数量参数为4。若在请求一处理结束时，第一服务器减少目标接口的调用请求数量参数的操作失败，则第一服务器在第二服务器接收到请求五的时间，增加目标接口对应的调用请求数量参数得到5；在时间t2，第一服务器确定的目标接口对应的调用请求数量参数为5，而目标接口真实未处理完成的调用请求的数量为4。因此，若第一服务器未通过多个时间段分别对目标接口的调用请求进行计数，且第一服务器对目标接口对应的调用请求数量参数的增加或减少的操作失败，则目标接口对应的调用请求数量参数与目标接口真实未处理完成的调用请求的数量存在误差。随着时间的推移，第一服务器对目标接口对应的调用请求数量参数的增加或减少的操作失败的情况会不断累积，导致第一服务器的调用请求数量参数与目标接口真实未处理完成的调用请求的数量的偏差越来越大，进而基于第一服务器的调用请求数量参数进行限流，容易导致错误限流情况的发生。
继续参见图6，第一服务器通过多个时间段分别对目标接口的调用请求进行计数。若第二时间段为时间段一，且第一服务器在请求一处理结束时，减少目标接口的调用请求数量参数的操作失败，在时间t2，第二时间段对应的调用请求数量参数为5，第二时间段对应的调用请求数量参数与目标接口真实未处理完成的调用请求的数量存在误差，随着时间的推移，第一服务器从第二服务器接收到请求九的时间开始，增加或减少第一时间段对应的调用请求数量参数，在时间t4，第一时间段对应的调用请求数量参数为3，并不包括第二时间段中产生的误差。而第一服务器随着请求二、请求三、请求四、请求五、请求六、请求七和请求八的处理结束，逐步减少第二时间段对应的调用请求数量参数，使第二时间段对应的调用请求数量参数为误差1，并不影响第一时间段的调用请求数量参数。
在本公开实施例中，第一服务器通过多个时间段分别对目标接口的调用请求进行计数，使每个时间段对应的调用请求数量参数互不影响，减少了目标接口对应的调用请求数量参数的误差的累计，提高了第一服务器确定调用请求数量参数的准确性，进而基于所确定的调用请求数量参数进行限流，减少了错误限流情况的发生，提高了集群限流的稳定性和可靠性。
在步骤S505中，第一服务器控制第二服务器在调用请求数量参数大于或等于目标接口的目标阈值的条件下丢弃调用请求，再次更新调用请求数量参数。
步骤S505与步骤S303至步骤S306或步骤S403至步骤S406同理，在此不再赘述。第一服务器控制第二服务器在调用请求数量参数大于或等于目标接口的目标阈值的条件下丢弃调用请求；根据该调用请求的接收时间，从目标接口对应的多个调用请求数量参数中，确定统计有该调用请求的第一时间段对应的调用请求数量参数；在该调用请求数量参数的基础上，减少预设数值。
继续参见图7，在一个示例中，第二服务器调用redis对时间段标识对应的调用请求数量参数进行累加，判断累加得到的调用请求数量参数是否达到目标阈值；若累加得到的调用请求数量参数未达到目标阈值，则对该调用请求进行处理，也即对该调用请求执行目标接口的处理逻辑。若累计得到的调用请求数量参数达到目标阈值，则第二服务器丢弃该调用请求。相应的，第二服务器丢弃该调用请求或者按照目标接口的处理逻辑对该调用请求处理完成后，调用redis，减少第一时间段对应的调用请求参数，也即第二服务器调用redis对时间段标识对应的调用请求数量参数进行扣减。第二服务器还可以向发送调用请求的终端或者其他服务器返回请求处理结果。例如，第二服务器丢弃该调用请求之后，返回的请求处理结果为系统繁忙，拒绝处理。第二服务器按照目标接口的处理逻辑对该调用请求处理完成后，返回相应的返回数据，作为请求处理结果。
在本公开实施例中，第一服务器通过调用请求数量参数表示对服务器集群中任一接口的调用请求的数量，在第二服务器接收到对某一接口的调用请求时，更新调用请求数量参数，在第二服务器对该调用请求处理完成之后，再次更新该调用请求数量参数，使得该调用请求数量参数能够在任一时刻表示对服务器集群中该接口的调用请求的数量。如果该接口的请求处理时间存在异常的延长，则该接口的调用请求数量参数会随着接收到的调用请求的增多而增大，并且，由于请求处理时间的延长，该调用请求数量参数的减少会变得缓慢，从而该调用请求数量参数会在短时间内快速增加而达到服务器集群能够处理的调用请求的最大数量，触发第二服务器对调用请求的限流处理，减少该接口由于请求处理时间的异常延长而占用的资源，减少对其他接口的影响，提高服务器集群的稳定性。
上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。
图9是根据一示例性实施例示出的一种请求处理装置的框图。参见图9，该装置应用于服务器集群中的第一服务器，包括：
确定单元901，被配置为执行响应于对服务器集群中的第二服务器的目标接口的调用请求，确定目标接口对应的调用请求数量参数，调用请求数量参数用于表示服务器集群中未处理完成的调用请求的数量；
第一更新单元902，被配置为执行更新调用请求数量参数；
控制单元903，被配置为执行控制第二服务器在调用请求数量参数大于或等于目标接口的目标阈值的条件下丢弃调用请求；
第二更新单元904，被配置为执行再次更新调用请求数量参数，其中，目标阈值为服务器集群中能够处理的调用请求的最大数量。
在一种可能的实现方式中，确定单元901，包括：
获取子单元，被配置为执行响应于对服务器集群中的第二服务器的目标接口的调用请求，获取调用请求的接收时间；
确定子单元，被配置为执行根据接收时间，确定目标接口在接收时间关联的时间段内对应的调用请求数量参数。
在另一种可能的实现方式中，确定子单元，被配置为执行：
确定接收时间所在的第一时间段；
从目标接口对应的多个调用请求数量参数中，确定第一时间段对应的调用请求数量参数，多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量。
在另一种可能的实现方式中，确定子单元，被配置为执行：
确定接收时间所在的第一时间段；
响应于接收时间与第一时间段的起始时间之间的时间差小于时间差阈值，从目标接口对应的多个调用请求数量参数中，确定第一时间段对应的调用请求数量参数和第二时间段对应的调用请求数量参数，多个调用请求数量参数分别用于记录不同时间段内未处理完成的调用请求数量，第二时间段为与第一时间段相邻的上一时间段；
获取第一时间段对应的调用请求数量参数与第二时间段对应的调用请求数量参数的和值，作为目标接口在接收时间关联的时间段内对应的调用请求数量参数。
在另一种可能的实现方式中，第一更新单元902，被配置为执行：
在调用请求数量参数的基础上，增加预设数值，预设数值用于表示发生变化的调用请求的数量；
第二更新单元904，被配置为执行：
在调用请求数量参数的基础上，减少预设数值。
在另一种可能的实现方式中，控制单元903，被配置为执行：
响应于调用请求数量参数大于或等于目标接口的目标阈值，向第二服务器发送丢弃指令，丢弃指令用于指示第二服务器丢弃调用请求；
响应于第二服务器对调用请求的第一丢弃信息，再次更新调用请求参数，第一丢弃信息用于表示第二服务器已丢弃调用请求。
在另一种可能的实现方式中，控制单元903，被配置为执行：
向第二服务器发送调用请求数量参数；
响应于接收到第二服务器对调用请求的第二丢弃信息，再次更新调用请求参数，第二丢弃信息用于表示第二服务器确定调用请求数量参数大于或等于目标接口的目标阈值，已丢弃调用请求。
关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
需要说明的是：上述实施例提供的请求处理装置在进行请求处理时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将第一服务器的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的请求处理装置与请求处理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
在本公开实施例中，第一服务器通过调用请求数量参数表示对服务器集群中任一接口的调用请求的数量，在第二服务器接收到对某一接口的调用请求时，更新调用请求数量参数，在第二服务器对该调用请求处理完成之后，再次更新该调用请求数量参数，使得该调用请求数量参数能够在任一时刻表示对服务器集群中该接口的调用请求的数量。如果该接口的请求处理时间存在异常的延长，则该接口的调用请求数量参数会随着接收到的调用请求的增多而增大，并且，由于请求处理时间的延长，该调用请求数量参数的减少会变得缓慢，从而该调用请求数量参数会在短时间内快速增加而达到服务器集群能够处理的调用请求的最大数量，触发第二服务器对调用请求的限流处理，减少该接口由于请求处理时间的异常延长而占用的资源，减少对其他接口的影响，提高服务器集群的稳定性。
图10是本公开实施例提供的一种服务器的框图，该服务器1000可以为上述实施例中的第一服务器，也可以为上述实施例中的第二服务器。该服务器1000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(Central Processing Units，CPU)1001和一个或一个以上的存储器1002，其中，存储器1002用于存储可执行指令，处理器1001被配置为执行上述可执行指令，以实现上述各个方法实施例提供的请求处理方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。
在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器1002，上述指令可由服务器1000的处理器1001执行以完成上述请求处理方法。可选地，存储介质可以是非临时性计算机可读存储介质，例如，非临时性计算机可读存储介质可以是ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、CD-ROM(Compact Disc Read-Only Memory，只读光盘)、磁带、软盘和光数据存储设备等。
在示例性实施例中，还提供了一种计算机程序产品，当计算机程序产品中的指令由服务器的处理器执行时，使得服务器能够执行上述各个方法实施例中的请求处理方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
