具体实施方式
下面结合附图,对本说明书提供的方案进行描述。
本说明书提供的业务请求的处理方法可以应用于如图1所示的场景中。图1中,业务请求方可以向服务器发送不同类型的业务请求。服务器可以根据预设的线程配置参数,创建多个线程,创建的线程用于处理业务请求,并将该多个线程存储至线程池中。此外,服务器还可以在不同的时间窗口动态配置处理不同类型的业务请求的线程的上限值。具体地,服务器在接收到业务请求之后,可以先确定该业务请求的类型。之后,判断线程池中处理该类型的业务请求的数量是否超过当前时间窗口的上限值。如果未超过,则分配线程池中的空闲线程,以处理该业务请求。如果超过,则将该业务请求加入等待队列。
需要说明的是,当基于某种规则,无法将业务请求加入等待队列时,如当加入等待队列的业务请求的个数超过预设数值时,服务器还可以创建其它线程,以执行无法加入等待队列的业务请求。可以理解的是,当服务器还创建其它线程时,线程池中维护的线程数量就会超过上述预设的线程配置参数。
图2为本说明书一个实施例提供的业务请求的处理方法流程图。所述方法的执行主体可以为具有处理能力的设备:服务器或者系统或者装置,如,图1中的服务器。如图2所示,所述方法具体可以包括:
步骤210,接收业务请求。
以业务请求为支付请求为例来说,服务器可以为支付服务器。具体地,支付服务器可以接收支付客户端发送的支付请求。
步骤220,确定业务请求所属的类型。
可选地,上述确定业务请求所属的类型的步骤可以为:统计线程池中维护的线程(包括处理业务请求的线程和空闲线程)的总数量。判断线程的总数量是否超过预设阈值(即上述线程配置参数)。如果未超过,则确定业务请求所属的类型。如果超过,则将该业务请求加入等待队列。
可以理解的是,在将业务请求加入等待队列之后,可以先不执行下述步骤230-步骤260。直至线程的总数量不超过预设阈值时,才继续执行下述步骤230-步骤260。
步骤220中的业务请求可以包含属性信息,该属性信息可以与预设的属性相对应。当业务请求中包含属性信息时,可以根据业务请求中的属性信息,确定业务请求所属的类型。
以业务请求为支付请求为例来说,假设预设的属性为:type,其对应的属性信息可以为:P1、P2和P3。那么当接收的支付请求包含属性信息:P1时,可以确定该支付请求所属的类型为:个人支付。当接收的支付请求包含属性信息:P2时,可以确定该支付请求所属的类型为:团体支付。当接收的支付请求包含属性信息:P3时,可以确定该支付请求所属的类型为:其它支付。
当然,在实际应用中,业务请求中可以包含与多个预设的属性相对应的属性信息。当包含与多个预设的属性相对应的属性信息时,业务请求的类型的确定方法类似,在此不复赘述。
步骤230,从线程池中统计出分配给该类型的业务请求的线程的数量。
本说明书的线程池中维护多个分配给不同类型的业务请求的线程。此外,还可以维护一个或多个空闲线程。
如前述例子中,假设线程池中维护50个线程,其中,20个线程分配给执行支付类型为:个人支付的支付请求,30个线程分配给执行支付类型为:团体支付的支付请求,5个线程分配给执行支付类型为:其它支付的支付请求,5个空闲线程。那么当接收的支付请求所属的类型为:个人支付时,统计的线程的数量为:20个。
步骤240,判断线程的数量是否超过在当前时间窗口内分配给该类型的业务请求的线程的上限值。
在一种实现方式中,上述上限值可以是根据在上一时间窗口内分配给不同类型的业务请求的线程的数量以及该类型的业务请求被分配到线程的概率来确定的。具体地,上述上限值的确定过程可以为:
步骤X,在当前时间窗口到达时,获取在上一时间窗口内分配给不同类型的业务请求的线程的数量、接收的业务请求所属的类型的总数量、各类型业务请求的响应时间(也称耗时)、权重值以及请求数。
可选地,本说明书中的业务请求的属性信息可以具有对应的权重值,该权重值可以是人为预先设定好的,也可以是根据相应的算法动态设定。
当业务请求中的属性信息具有对应的权重值时,在根据业务请求中的属性信息,确定业务请求所属的类型后,还可以根据属性信息对应的权重值,确定该类型的业务请求对应的权重值。如前述例子中,假设属性信息:P1、P2和P3各自对应的权重值分别为:W1、W2和W3。那么当接收的支付请求所属的类型为:个人支付时,也即当支付请求包含的属性信息为:P1时,该类型的支付请求对应的权重值可以为:W1。
还以前述例子为例来说,接收的支付请求所属的类型的总数量为:3个,即分别为:个人支付、团体支付以及其它支付。
需要说明的是,对某类型的业务请求的响应时间,当该类型的业务请求的请求数为多个时,其可以是指该类型的多个业务请求的平均响应时间。
可以理解的是,在不同的时间窗口,上述分配给不同类型的业务请求的线程的数量、类型的总数量、各类型业务请求的响应时间以及请求数可以是不同的。
步骤Y,根据类型的总数量、响应时间、权重值以及请求数,确定在上一时间窗口内该类型的业务请求被分配到线程的概率。
在一种实现方式中,可以根据如下公式来确定在上一时间窗口内第n类业务请求被分配到线程的概率。
其中,PRn为第n类业务请求被分配到线程的概率,C为接收的业务请求所属的类型的总数量,Ri为第i类业务请求的请求数,Rn为第n类业务请求的请求数,Wi为第i类业务请求的权重值,Wn为第n类业务请求的权重值,Ti为第i类业务请求的响应时间,Tn为第n类业务请求的响应时间。
步骤Z,根据分配给不同类型的业务请求的线程的数量以及概率,确定上限值。
在一个例子中,确定第n类业务请求在当前时间窗口的上限值可以为:Q×PRn,其中,Q为在上一时间窗口内线程池中分配给不同类型的业务请求的线程的数量。
可以理解的是,上述步骤X-步骤Z是周期性执行的,即每隔一个时间窗口就执行一次上述确定上限值的步骤。由此可以看出,本说明书中,各个时间窗口的上限值是动态确定的。
通过上述动态确定当前时间窗口的上限值的步骤,可以实现按照不同的业务请求的类型,对线程进行合理化分配的目的。此外,还可以有效地对不同类型的业务请求进行隔离。
步骤250,如果未超过上限值,则分配线程池中的空闲线程,以处理该业务请求。
在空闲线程处理完成该业务请求之后,服务器可以向业务请求方返回处理结果。如,支付服务器可以向支付客户端返回支付结果。此外,还可以判断空闲线程是否满足预设的回收条件。如果满足预设的回收条件,则释放空闲线程占用的资源,并回收空闲线程。此处,预设的回收条件可以包括:线程的总数量超过预设阈值(即上述线程配置参数)且等待一定时间后没有新的业务请求分配给空闲线程。可以理解的是,在回收多个空闲线程之后,线程的总数量就会不超过预设阈值。
通过上述回收线程的步骤,可以避免反复创建线程所带来的性能开销,节省了资源。
步骤260,如果超过上限值,则将业务请求加入等待队列。
可以理解的是,在将业务请求加入等待队列之后,可以按照先后顺序排队等待空闲线程。当被分配到空闲线程时,可以再次执行上述步骤240的判断步骤,如果未超过,则执行该业务请求。如果超过,则继续等待,直至上述步骤240的判断结果为未超过。
通过对本实例的各步骤进行分析,可以得出如下结论:
1)某类型的业务请求的响应时间相对于总响应时间(各类型的业务请求的响应时间之和)越短,则被分配到的线程的数量越多。
2)某类型的业务请求的请求数相对应总请求数(各类型的业务请求的请求数之和)越多,则被分配到的线程的数量越多。
3)某类型的业务请求的权重值相对于其它类型的业务请求的权重值较高,则被分配到的线程的数量越多。
由此可以看出,某类型的业务请求的请求数越多、响应时间越短且权重值越高,则会被分配到更多的线程,从而符合线程分配的整体原则,且可控性较强。
综上,本说明书实施例通过动态确定各类型的业务请求在当前时间窗口的上限值,可以实现对不同类型的业务请求动态分配线程。通过上述动态分配策略,可以使线程的分配最优化和性能最大化。此外,通过上述动态分配策略,解决了因某类型的业务请求响应时间增加且请求量大时,导致大量线程阻塞,引起其它类型的业务请求无法分配到线程而只能等待的问题。而当响应时间较短的业务请求处于等待状态时,资源的状态就得不到有效地推进。最后,通过上述动态分配策略,最大程度的提高了线程的利用率,降低了阻塞线程对其它类型的业务请求的影响。
与上述业务请求的处理方法对应地,本说明书一个实施例还提供的一种业务请求的处理装置,如图3所示,该装置包括:
接收单元301,用于接收业务请求。
确定单元302,用于确定接收单元301接收的业务请求所属的类型。
统计单元303,用于从线程池中统计出分配给确定单元302确定的类型的业务请求的线程的数量。线程池中维护多个分配给不同类型的业务请求的线程。
判断单元304,用于判断统计单元303统计的线程的数量是否超过在当前时间窗口内分配给该类型的业务请求的线程的上限值,上限值是根据在上一时间窗口内分配给不同类型的业务请求的线程的数量以及该类型的业务请求被分配到线程的概率来确定的。
分配单元305,用于如果判断单元304判断未超过上限值,则分配线程池中的空闲线程,以处理业务请求。
加入单元306,用于如果判断单元304判断超过上限值,则将业务请求加入等待队列。
可选地,确定单元302,还可以用于在当前时间窗口到达时,获取在上一时间窗口内分配给不同类型的业务请求的线程的数量、接收的业务请求所属的类型的总数量、各类型业务请求的响应时间、权重值以及请求数。
根据类型的总数量、响应时间、权重值以及请求数,确定在上一时间窗口内该类型的业务请求被分配到线程的概率。
根据分配给不同类型的业务请求的线程的数量以及概率,确定上限值。
可选地,业务请求还可以包含属性信息。
确定单元302具体可以用于:
根据业务请求中的属性信息,确定业务请求所属的类型。
可选地,属性信息具有对应的权重值。各类型业务请求的权重值可以是根据所包含的属性信息对应的权重值确定的。
可选地,确定单元302还具体可以用于:
统计线程池中维护的线程的总数量。
判断线程的总数量是否超过预设阈值。
如果超过,则将业务请求加入等待队列。
如果未超过,则确定业务请求所属的类型。
可选地,该装置还可以包括:回收单元307。
判断单元304,还可以用于在空闲线程处理完业务请求后,判断空闲线程是否满足预设的回收条件。
回收单元307,用于如果判断单元302判断满足预设的回收条件,则释放空闲线程占用的资源,并回收空闲线程。
本说明书上述实施例装置的各功能模块的功能,可以通过上述方法实施例的各步骤来实现,因此,本说明书一个实施例提供的装置的具体工作过程,在此不复赘述。
本说明书一个实施例提供的业务请求的处理装置,接收单元301接收业务请求。确定单元302确定接收的业务请求所属的类型。统计单元303从线程池中统计出分配给该类型的业务请求的线程的数量。判断单元304判断线程的数量是否超过在当前时间窗口内分配给该类型的业务请求的线程的上限值。如果判断单元304判断未超过上限值,则分配单元305分配线程池中的空闲线程,以处理业务请求。如果判断单元304判断超过上限值,则加入单元306将业务请求加入等待队列。由此,可以提高线程的利用率。
需要说明的是,本说明书实施例提供的业务请求的处理装置可以为图1中的服务器的一个模块或者单元。
本领域技术人员应该可以意识到,在上述一个或多个示例中,本说明书所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时,可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。
以上所述的具体实施方式,对本说明书的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本说明书的具体实施方式而已,并不用于限定本说明书的保护范围,凡在本说明书的技术方案的基础之上,所做的任何修改、等同替换、改进等,均应包括在本说明书的保护范围之内。