CN107181787B - 一种请求处理方法及装置 - Google Patents

Abstract

本申请实施例公开了一种请求处理方法及装置，该方法包括：接收客户端发送的业务请求，确定所述业务请求所携带的业务数据，根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据，当查找到所述处理结果时，将查找到的所述处理结果反馈给所述客户端，当查找到所述处理状态数据时，将查找到的所述处理状态数据反馈给所述客户端，并在处理结果生成后，将生成的处理结果反馈给所述客户端。通过本方法，不仅可避免服务器针对相同请求进行重复处理的现象，同时，也可避免出现超时报错的现象。

Description

一种请求处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种请求处理方法及装置。

背景技术

客户端(如：浏览器)可基于相应的网络传输协议与服务器进行业务交互，如：客户端向服务器发出超文本传输协议(HyperText Transfer Protocol，HTTP)请求，以使得服务器对HTTP请求进行处理。

目前，服务器在处理客户端发送的请求时，往往会设置请求超时时长(如：30s)，换言之，如果服务器针对客户端所发送的某个请求(以下称为第一请求)的处理时间超过了上述的请求超时时长，则基于报错机制，服务器会向客户端返回超时报错，例如：服务器针对处理超时的HTTP请求，会向客户端返回HTTP504错误(其中，HTTP504错误表示发生了超时现象)。

对于服务器而言，向客户端反馈超时报错后，服务器仍会继续对第一请求进行处理(即，处理该第一请求所占用的处理资源并未释放)，然而，用户可能会认为业务出错，从而使用客户端再次向服务器发起相同的请求(以下称为第二请求)，服务器则会占用新的处理资源以处理第二请求，对第二请求的处理仍可能超过请求超时时长，所以，服务器会继续反馈超时报错，以此类推，服务器中会积累大量请求并占用大量的处理资源。

而在实际应用场景中，服务器通常会向不同的客户端提供业务服务，在一些情况下，不同的客户端可能会向服务器发出相同的请求，但对于服务器而言，均会将这些请求作为不同的请求进行处理，此时，已出现重复处理的现象，特别是服务器处理超时后，会分别向不同的客户端反馈超时报错，则不同用户可能会通过相应的客户端再次向服务器发出请求，从而导致服务器中对大量的相同请求进行重复处理，使得处理资源被大量占用，严重影响服务器的处理效率。

现有技术中，为了减少或避免上述问题，通常采用的方式为：将服务器默认的请求超时时长延长，如：将超时时间从30s延长至10min。并且，使用缓存存储对请求的处理结果。

但是，上述方式仍存在一定缺陷，具体而言：

虽然将超时时间延长，能够使得客户端在一段时间内不会向服务器重复发出相同请求，但对于处理耗时较长的请求而言，服务器对其处理的耗时仍可能会超过延长后的超时时间，也就是说，服务器仍会向客户端返回超时报错，造成客户端再次向服务器发出相同请求的现象。

使用缓存存储处理结果的方式，能够在一定程度上减少服务器对相同请求的处理，但是，对于处理耗时较长的请求而言，服务器可能在处理请求(还未生成处理结果)的过程中，接收到来自其他客户端的相同请求，由于还未生成处理结果，所以，服务器仍会对相同的请求进行处理，并占用相应的处理资源，从而增加服务器的工作负荷。

发明内容

本申请实施例提供一种请求处理方法及装置，用以解决服务器重复处理相同请求的问题。

本申请实施例提供的一种请求处理方法，包括：

接收客户端发送的业务请求；

确定所述业务请求所携带的业务数据；

根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据；

当查找到所述处理结果时，将查找到的所述处理结果反馈给所述客户端；

当查找到所述处理状态数据时，将查找到的所述处理状态数据反馈给所述客户端，并在处理结果生成后，将生成的处理结果反馈给所述客户端。

本申请实施例还提供的一种请求处理方法，包括：

向服务器发送携带有业务数据的业务请求，以使得所述服务器反馈对应于所述业务数据的处理结果或处理状态数据；

接收所述服务器反馈的处理结果或处理状态数据。

本申请实施例提供的一种请求处理装置，包括：

接收模块，接收客户端发送的业务请求；

数据确定模块，确定所述业务请求所携带的业务数据；

查询处理模块，根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据；

反馈模块，当查找到所述处理结果时，将查找到的所述处理结果反馈给所述客户端，当查找到所述处理状态数据时，将查找到的所述处理状态数据反馈给所述客户端，并在处理结果生成后，将生成的处理结果反馈给所述客户端。

本申请实施例另提供的一种请求处理装置，包括：

请求发送模块，向服务器发送携带有业务数据的业务请求，以使得所述服务器反馈对应于所述业务数据的处理结果或处理状态数据；

请求接收模块，接收所述服务器反馈的处理结果或处理状态数据。

本申请实施例提供一种请求处理方法及装置，通过该方法，服务器在接收到客户端所发出的业务请求后，为了避免出现对相同业务请求的重复处理，服务器会确定业务请求所携带的业务数据，以便于根据该业务数据查找与业务数据对应的处理结果或是处理状态数据，换言之，服务器有可能在接收到当前的业务请求之前，已经接收到了相同的业务请求并进行处理，那么，如果服务器已经生成了相应的处理结果，则服务器可将查找到的处理结果反馈给客户端，而如果服务器正在处理相同的业务请求并且还未生成处理结果，则服务器可将查找到的处理状态数据反馈给客户端，当服务器经过一段时间生成了处理结果后，则服务器会将新生成的处理结果主动发送给客户端。相较于现有技术而言，本申请实施例中的上述方式可避免服务器针对相同请求进行重复处理的现象，能够减少服务器内部处理资源的消耗。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的请求处理过程所基于的架构示意图；

图1b为本申请实施例提供的服务器侧的请求处理过程；

图2为本申请实施例提供的基于客户端侧的请求处理过程；

图3为本申请实施例提供的业务逻辑架构的示意图；

图4为本申请实施例提供的实际请求处理流程示意图；

图5为本申请实施例提供的基于服务器侧的请求处理装置结构示意图；

图6为本申请实施例提供的基于客户端侧的请求处理装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

正如前述，现有技术中服务器存在对相同请求进行重复处理的缺陷，导致服务器中的处理资源被过多占用，急剧加重了服务器的工作负荷。基于此，本申请实施例中提供了一种请求处理方法，实现了避免服务器对相同请求进行重复处理，以减少对服务器处理资源的占用。

需要说明的是，本申请实施例中所述的请求处理方法，基于如图1a所示的架构，在图1a中可见，该架构中包含多个客户端以及后端服务器，其中，所述的客户端，可以是浏览器、应用程序等，图1a中所示出的不同客户端可分别运行在不同的终端设备中。所述的服务器，能够提供相应的业务服务，在实际应用场景下，客户端与服务器之间基于网络传输协议进行业务交互，所述的网络传输协议，包括但不限于：HTTP、安全超文本传输协议(HyperText Transfer Protocol over Secure Socket Layer，HTTPS)、传输控制协议(Transmission Control Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)等协议。这里并不构成对本申请的限定。

下面将结合如图1a所示的架构，对本申请中的请求处理方法进行说明，具体而言，如图1b所示，请求处理过程包括如下步骤：

步骤S101：接收客户端发送的业务请求。

所述的业务请求，可认为是基于不同业务需求的请求，如：数据计算请求、页面访问请求、支付请求、下单请求等等。

基于图1a所示的架构可知，本申请实施例中所述的业务请求，可能来自于该架构中的任一客户端。在实际应用场景下，服务器在接收到当前的业务请求之前，可能已经接收到了相同的业务请求(之前接收到的相同业务请求可能由同一客户端发出，也可能由不同客户端发出)，那么，为了避免出现重复处理相同业务请求的情况，服务器将执行下述步骤。

S102：确定所述业务请求所携带的业务数据。

所述的业务数据，可认为是所需请求的与业务相关的数据，其中可包括：业务参数、业务类别标识、业务场景标识等，这里并不作具体限定。

通过业务数据，服务器可以确定出相同的业务请求，需要说明的是，本申请实施例中所提及的相同的业务请求，是指业务数据相同的请求，换言之，无论业务请求是否由不同的客户端发出，只要其中的业务数据相同，便可认为是相同的业务请求。当然，这里并不构成对本申请的限定。

S103：根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据。

在本实施例中，服务器针对接收到的业务请求均会进行处理，也就是说，服务器在接收到当前的业务请求之前，可能已经接收到了相同的业务请求并进行了处理，那么，在本步骤中，为了避免出现重复处理业务请求的现象，服务器将根据业务数据查找相应的处理结果或是处理状态数据。

其中，如果服务器已经生成了相应的处理结果，则服务器可根据业务数据查找相应的处理结果。而如果服务器当前时刻还未生成处理结果(即，服务器根据业务数据并未查找到处理结果)，则服务器可查询对相同业务请求的处理状态(即，处理状态数据)。

可见，与现有技术不同的是，在本申请实施例中，服务器接收到了业务请求后，并不会直接对该业务请求进行处理，而是查找相应的处理结果或是处理状态数据。

S104：当查找到所述处理结果时，将查找到的所述处理结果反馈给所述客户端。

S105：当查找到所述处理状态数据时，将查找到的所述处理状态数据反馈给所述客户端，并在处理结果生成后，将生成的处理结果反馈给所述客户端。

如前所述，服务器可能已经处理过相同的业务请求，并生成了相应的处理结果，那么，在服务器查找到了处理结果后，可将该处理结果反馈给客户端。当然，服务器也有可能正在对相同的业务请求进行处理(还未生成处理结果)，故服务器将相应的处理状态数据反馈给客户端，以“告知”客户端当前的处理状态，服务器将等待处理结果的生成，当服务器生成了处理结果，则可将生成的处理结果主动发送给客户端。

作为本申请实施例中的一种方式，客户端与服务器之间保持长连接(如：http长连接)，那么，客户端向服务器发送业务请求且服务器向客户端反馈了处理状态数据后，二者之间仍保持长连接，所以，服务器在生成了处理结果后，可通过保持的长连接，将生成的处理结果反馈给客户端。

通过上述步骤，服务器在接收到客户端所发出的业务请求后，为了避免出现对相同业务请求的重复处理，服务器会确定业务请求所携带的业务数据，以便于根据该业务数据查找与业务数据对应的处理结果或是处理状态数据，换言之，服务器有可能在接收到当前的业务请求之前，已经接收到了相同的业务请求并进行处理，那么，如果服务器已经生成了相应的处理结果，则服务器会将查找到的处理结果反馈给客户端，而如果服务器正在处理相同的业务请求并且还未生成处理结果，则服务器会将查找到的处理状态数据反馈给客户端，当服务器经过一段时间生成了处理结果后，则服务器可将新生成的处理结果主动发送给客户端。相较于现有技术而言，本申请实施例中的上述方式可避免服务器针对相同请求进行重复处理的现象，能够减少服务器内部处理资源的消耗。

此外，需要说明的是，现有技术中的诸如http、https等网络传输协议存在超时报错机制，具体而言，当客户端向服务器发送了业务请求后，如果在设定的超时时长内，服务器并未针对该业务请做出响应，则会生成超时报错。而导致服务器不能在设定的超时时长内做出响应的原因，正是由于某些业务请求的处理耗时较长。在本申请实施例中，服务器接收到业务请求后，通过业务请求所携带的业务数据，查找相应的处理结果或处理状态数据，一旦查找到处理结果或处理状态数据，服务器会反馈给客户端(即，服务器针对客户端的业务请求做出响应)，查找已存在的处理结果或者获得业务请求的处理状态数据所消耗的时间，小于服务器对业务请求的处理耗时，这样也就能够保证在超时时间到达前，向客户端做出响应，进而减少或避免超时报错的发生。

为了清楚的阐述本申请的上述请求处理方法，现以基于http连接的实际应用场景进行详细说明：

在本场景下，客户端与服务器之间建立http长连接，并通过该http长连接实现业务请求、处理结果或处理状态数据的传输。在http自身的协议机制下，http长连接具有保活时长(keepalive-timeout)，当保活时长到达时，http长连接被释放(即，http长连接断开)。而保活时长的刷新依赖于客户端发送请求，换言之，每当客户端发送一个请求，则保活时长进行一次刷新(即，重新计时)。

由此可知，对于本申请实施例的前述内容而言，服务器在查找到了处理状态数据并反馈给客户端后，由于客户端接收到了服务器的响应，故客户端不再发出业务请求，服务器会等待生成了处理结果后，再将生成的处理结果反馈给客户端，但显然，由于保活时长的存在，客户端不再向服务器发出业务请求，则保活时长不再刷新，并且，服务器等待处理结果生成所需的时间，有可能超过http长连接的保活时长，从而致使http长连接断开。

因此，作为本场景下的一种可行方式，客户端可向服务器发起周期性的业务请求。也即，接收客户端发送的业务请求，包括：接收所述客户端通过HTTP连接(或HTTPS连接)按照设定周期发送的业务请求。此外，考虑到http具有超时报错机制，一旦服务器对请求的处理耗时超过了设定的请求超时时长，则会产生超时报错。那么，便可将周期设定为小于超时报错的时长，以避免超时报错现象的出现，故，所述设定周期短于处理所述业务请求所对应的超时时长。这里的超时时长，可由服务器设置，在此不作具体限定。

上述方式不仅能够避免出现超时报错的现象，而且客户端周期式的重复发送业务请求，也能够不断刷新http长连接的保活时长。

在实际应用中，假设客户端已向服务器发出了业务请求，如果客户端接收到了相应的处理结果，则表明服务器已完成对业务请求的处理，从而，客户端将停止按照设定周期向服务器重复发送所述的业务请求。而如果客户端接收到了处理状态数据，由于处理状态数据仅表征了服务器对所述业务请求的处理状态，并非最终的处理结果，故客户端将继续按照设定周期重复向服务器发送所述业务请求。

具体地，客户端可以在t₁时刻向服务器发送业务请求，若服务器反馈了处理状态数据，则经过设定周期T后，客户端在t₂时刻再次向服务器发送业务请求，以此类推，直到服务器反馈了处理结果为止。

在一种方式下，当服务器在向客户端反馈了处理结果后，可能在客户端发送下一次业务请求之前生成了处理结果，则服务器可以主动向客户端发送生成的处理结果。需要说明的是，实际应用中，服务器可能会与大量的客户端保持连接，如果服务器主动向大量客户端主动反馈生成的处理结果，会增加服务器的工作负荷，所以，作为一种更加贴合实际应用的方式，服务器针对一个业务请求，仅反馈一个响应，而不会主动针对某一请求连续反馈多个响应。换言之，即使服务器生成了处理结果，也会等待客户端在下一个周期发出业务请求后，才将该处理结果反馈给客户端。

需要说明的是，基于前述如图1a所示的架构，在一种可能的实际应用场景下，本申请实施例中的客户端为企业内部浏览器(相应的，服务器也可认为是企业内部服务器)，在该浏览器中，通过相应的编译语言(如：JAVA语言)实现异步调用的业务请求，也即，浏览器在业务请求发出后，可以无需等待服务器对业务请求的响应，而执行后续的业务流程。另外，通过相应的编译语言，也能够实现在浏览器中设定业务请求的发送周期短于服务器中设置的超时时长，也就是说，客户端每次向服务器发送了异步业务请求后，可以在超时时长到达前，向服务器发送下一个异步业务请求，这样的方式能够避免超时报错。当然，上述内容仅是一种可能的实际应用场景，并不应构成对本申请的限定。

当服务器接收到了业务请求，便可确定其业务数据，并查找相应的处理结果或处理状态数据，其过程可为：查找与所述业务数据对应的处理结果，并在未查找到所述处理结果时，查找对应于所述业务数据的处理状态数据。

具体而言，本场景下，业务请求中会携带有不同的业务参数(Param)，具体而言，不同的业务参数以不同的参数名和参数值体现，例如：如下表1所示。

参数名	参数值
		Param1	Val1
Param2	Val2
		……	……
ParamN	ValN

表1

从表1中可见，某业务请求包含N个业务参数(即，Param1～ParamN)及其对应的参数值。这里需要说明的是，所述参数值并非仅包含具体的数值，可以是诸如文字、符号等字符或字符串等，也可以是与参数名所对应的一组数据、函数等，这里并不具体限定。

应理解地，在实际应用中，对于相同的业务请求而言，其中所携带的业务参数应是一致的，也即，业务请求中所携带的参数名及相应的参数值应一致。那么，服务器便可以通过业务请求中所携带的业务参数来判定其接收到的业务请求是否是相同的业务请求，换言之，由于服务器会处理其接收到的任一业务请求，那么，服务器便可根据业务参数来判定是否已经针对相同的业务请求进行了处理，以避免出现针对相同业务请求重复处理，占用处理资源的现象。那么，查找处理结果时，也就可以基于业务请求中所携带的业务数据进行查找，即，查找与所述业务数据对应的处理结果，包括：根据所述业务数据，生成结果查询键，在缓存中查找对应于所述结果查询键的处理结果。

具体来说，所述的结果查询键是服务器将业务请求中所携带的参数名和参数值进行累积所形成了长字符串，以上述表1中所示出的业务参数为例，服务器可以将其组装为Param1＝Val1，Param2＝Val2，……，ParamN＝ValN的长字符串的形式，并将该长字符串作为结果查询Key(即，结果查询键)。也即，在本示例中，结果查询键Param＝(Param1＝Val1，Param2＝Val2，……，ParamN＝ValN)。

基于该结果查询键，服务器可以在其自身的缓存中(需要说明的是，服务器通常会在缓存中存储业务请求的处理结果)，查找与该结果查询键对应的处理结果，以此来减少或避免对相同业务请求的重复处理。

在现有技术中的应用场景中，如果服务器在针对某一业务请求进行处理但还未生成处理结果时，该服务器又接收到同样的业务请求，由于还未生成处理结果，故服务器并不能在缓存中查找到处理结果，那么，服务器还会对接收到的相同业务请求进行处理。

正是考虑到现有技术的应用场景下，上述情况可能造成服务器对相同业务请求进行重复处理，所以在本申请实施例中，除了查找处理结果之外，还会针对业务请求的处理状态进行查询，具体而言，查找对应于所述业务数据的处理状态数据，包括：根据所述业务数据生成状态查询键，在所述缓存中查找对应于该状态查询键的处理状态数据。

其中，所述的状态查询键用于查找对业务请求的处理状态。沿用上例，结果查询键可采用上例中生成的Key，使用该Param便可以在缓存中查询是否已生成了业务请求的处理结果数据，如果查询到了处理结果数据，便可进一步将处理结果数据作为结果查询键Param所对应的值，即，可以表示为：

Key＝Param，Val＝处理结果数据；

而如果未查找到相应的处理结果，则表明服务器可能正在对相同的业务请求进行处理，故将进一步检查服务器对该业务请求的执行状态，服务器可基于结果查询键Param，生成状态查询键Param_status。进而服务器便可以通过该状态查询键在缓存中查找针对相应业务请求的处理状态数据。如果服务器正在进行处理，则可以确定出该状态查询键的值为true，即，可表示为：

Key＝Param_status，Val＝true；

此时，服务器可以向客户端反馈“正在处理”。

而如果状态查询键的值为false或null，则表明对业务请求处理失败或未进行处理。在此情况下，所述方法还包括：当未查找到所述处理状态数据或处理状态数据对应的处理状态为失败时，处理所述业务请求，并在所述缓存中更新所述状态查询键对应的处理状态数据，当生成处理结果后，将生成的所述处理结果存储于所述缓存中。

换言之，服务器会针对业务请求进行处理，并在缓存中写入相应的状态(即，将上述状态查询键的值改为true)。并在生成了处理结果后，存储在缓存中。

正是通过上述方式，不仅可以避免服务器向客户端反馈超时报错的现象，并且在查询键的基础上，可确定出业务请求的处理结果或是对业务请求的处理状态，从而可以避免服务器对相同业务请求的重复处理。

以上是针对服务器侧的描述，在本申请实施例中，基于客户端侧，还提供一种请求处理方法，如图2所示，具体包括以下步骤：

步骤S201：向服务器发送携带有业务数据的业务请求，以使得所述服务器反馈对应于所述业务数据的处理结果或处理状态数据。

当然，在本申请实施例中，业务请求具体可由用户向客户端发出了相应的指令(如：请求出发指令)后所生成。其中，所述的请求触发指令，用于在客户端上触发业务请求，在一种实际应用场景中，请求触发指令可源自于对客户端上业务控件的点击、按压等操作，这里并不作具体限定。

客户端接收到请求触发指令后，便可以确定出请求触发指令所对应的诸如业务参数、业务标识等业务数据。

步骤S202，接收所述服务器反馈的处理结果或处理状态数据。

具体地，向服务器发送携带有业务数据的业务请求，包括：基于建立的HTTP连接或HTTPS连接，按照设定周期，向所述服务器发送携带有业务数据的业务请求，其中，所述设定周期短于处理所述业务请求所对应的超时时长。

所述方法还包括：当接收到反馈的所述处理状态数据时，按照设定周期重复发送所述业务请求；

当接收到反馈的所述处理结果，停止按照设定周期重复发送所述业务请求。

基于前述内容，本申请实施例中可采用如图3所示的业务逻辑架构。在图3中，客户端内包含异步请求发送、异步结果接收两个功能单元，这两个功能单元分别用于采用异步方式发送业务请求，以及接收服务器的反馈。服务器中包含处理结果识别、处理状态识别、业务请求处理这三个功能单元以及数据缓存，其中，处理结果识别用于在数据缓存中根据结果查询键识别相同业务请求的处理结果，处理状态识别用于在数据缓存中根据状态查询键识别对相同业务请求处理状态，业务请求处理对轮询请求进行处理，而数据缓存用于存储服务器已处理的业务参数及相应的处理结果、处理状态等数据。

基于图3所示的业务逻辑架构，在实际应用中的业务请求处理过程如图4所示：

步骤S401：用户向客户端发出请求触发指令。

步骤S402：客户端确定请求触发指令对应的业务参数，并基于预设的周期向服务器发起业务请求。

其中，业务参数包含：参数名和参数值。在客户端发起了首个业务请求后，客户端会进入等待页面。

步骤S403：服务器基于业务请求的业务参数的参数名和参数值，生成结果查询键Key＝Param。

服务器将业务参数中的所有参数名及其对应的参数值，组装为字符串Param，即，结果查询键。

步骤S404：服务器通过结果查询键Key＝Param获取缓存中的值。

其中，如果Key＝Param的值不为空，则表明服务器已经针对相同的业务请求进行了处理并生成了相应的处理结果。而如果Key＝Param的值为空，则表明服务器在当前时刻，并未生成相应的处理结果。

步骤S405：若结果查询键Key＝Param的值不为空，则将处理结果发送给客户端。

步骤S406：若结果查询键Key＝Param的值为空，则生成状态查询键Key＝Param_status。

步骤S407：服务器在缓存中查询状态查询键Key＝Param_status的值。

其中，如果状态查询键Key＝Param_status的值为true，则表明服务器正在对相同的业务请求进行处理，但还未生成相应的结果数据；如果状态查询键Key＝Param_status的值为false或null，则表明服务器处理失败或还未进行处理，即，服务器可处理该业务请求。

步骤S408：若状态查询键Key＝Param_status的值为true，则服务器向客户端反馈“正在处理”。

步骤S409：若状态查询键Key＝Param_status的值为false或null，则服务器对业务请求进行处理，并将状态查询键Key＝Param_status，Val＝true写入缓存。

步骤S410：生成处理结果后，将结果查询键Key＝Param，Val＝result写入缓存，并执行步骤S405。

从上述内容及示例中可见，在实际的请求处理场景中，一旦用户向客户端发出了请求触发指令后，客户端便会按照设定周期向服务器发送业务请求，服务器可将业务请求中的业务参数生成相应的Key，以便在缓存中查询是否具有与该Key相匹配的处理结果，如果有，则反馈给客户端，而如果未查询到处理结果，则服务器进一步生成用以查询处理状态的Key’，通过Key’，服务器在缓存中查询处理状态，如果查询到Key’的值为true，则表明服务器正在进行处理，此时，将向客户端反馈“正在处理”，而客户端则继续按照设定周期发送业务请求，而如果查询到Key’的值为false或null，则服务器需要对业务请求进行处理，并告知客户端“正在处理”，直到服务器生成了处理结果，那么，客户端将停止发送业务请求。

以上为本申请提供的请求处理方法的几种实施例，基于同样的思路，本申请还提供了请求处理装置的实施例，如图5所示。图5中的请求处理装置包括：

接收模块501，接收客户端发送的业务请求；

数据确定模块502，确定所述业务请求所携带的业务数据；

查询处理模块503，根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据；

反馈模块504，当查找到所述处理结果时，将查找到的所述处理结果反馈给所述客户端，当查找到所述处理状态数据时，将查找到的所述处理状态数据反馈给所述客户端，并在处理结果生成后，将生成的处理结果反馈给所述客户端。

所述接收模块501，接收所述客户端通过http连接或https连接，按照设定周期发送的业务请求；其中，所述设定周期短于处理所述业务请求所对应的超时时长。

所述查询处理模块503，查找与所述业务数据对应的处理结果，并在未查找到所述处理结果时，查找对应于所述业务数据的处理状态数据。

所述查询处理模块503，根据所述业务数据，生成结果查询键，在缓存中查找对应于所述结果查询键的处理结果。

所述查询处理模块503，根据所述业务数据生成状态查询键，在所述缓存中查找对应于该状态查询键的处理状态数据。

所述装置还包括：请求处理模块505，当所述查询处理模块503未查询到所述处理状态数据或处理状态数据对应的处理状态为失败时，处理所述业务请求，并在所述缓存中更新所述状态查询键对应的处理状态数据，当生成处理结果后，将生成的所述处理结果存储于所述缓存中。

所述反馈模块504，将查找到的所述处理状态数据反馈给所述客户端，通过所述处理状态数据控制所述客户端继续按照设定周期重复发送所述业务请求。

此时，所述反馈模块504，将查找到的所述处理结果反馈给所述客户端，通过所述处理结果控制所述客户端停止按照设定周期重复发送所述业务请求。

本申请还提供一种请求处理装置，如图6所示，该装置包括：

请求发送模块601，向服务器发送携带有业务数据的业务请求，以使得所述服务器反馈对应于所述业务数据的处理结果或处理状态数据；

请求接收模块602，接收所述服务器反馈的处理结果或处理状态数据。

所述请求发送模块601，通过http连接或https连接，按照设定周期，向所述服务器发送携带有业务数据的业务请求，其中，所述设定周期短于所述服务器设置的请求超时时长。

所述装置还包括：请求控制模块603，当所述请求接收模块602接收到反馈的所述处理状态数据时，继续按照设定周期重复发送所述业务请求；

当所述请求接收模块602接收到反馈的所述处理结果，停止按照设定周期重复发送所述业务请求。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (22)

1.一种请求处理方法，其特征在于，包括：

接收客户端周期性发送的业务请求，以在向所述客户端反馈所述业务请求对应的处理结果前，保持与所述客户端的连接，其中，所述周期性的周期短于处理所述业务请求所对应的超时时长；

确定所述业务请求所携带的业务数据；

根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据；

当查找到所述处理结果时，将查找到的所述处理结果通过所述连接反馈给所述客户端；

当查找到所述处理状态数据时，将查找到的所述处理状态数据通过所述连接反馈给所述客户端，并在处理结果生成后，将生成的处理结果通过所述连接反馈给所述客户端。

2.如权利要求1所述的方法，其特征在于，接收客户端周期性发送的业务请求，具体包括：

接收所述客户端通过超文本传输协议http连接或安全超文本传输协议https连接，按照设定周期发送的业务请求；

其中，所述设定周期短于处理所述业务请求所对应的超时时长。

3.如权利要求2所述的方法，其特征在于，查找与所述业务数据对应的处理结果或处理状态数据，具体包括：

查找与所述业务数据对应的处理结果，并在未查找到所述处理结果时，查找对应于所述业务数据的处理状态数据。

4.如权利要求1所述的方法，其特征在于，查找与所述业务数据对应的处理结果，具体包括：

根据所述业务数据，生成结果查询键；

在缓存中查找对应于所述结果查询键的处理结果。

5.如权利要求1所述的方法，其特征在于，查找对应于所述业务数据的处理状态数据，具体包括：

根据所述业务数据生成状态查询键；

在缓存中查找对应于该状态查询键的处理状态数据。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

当未查找到所述处理状态数据或处理状态数据对应的处理状态为失败时，处理所述业务请求，并在所述缓存中更新所述状态查询键对应的处理状态数据；

当生成处理结果后，将生成的所述处理结果存储于所述缓存中。

7.如权利要求2所述的方法，其特征在于，将查找到的所述处理状态反馈给所述客户端，具体包括：

将查找到的所述处理状态数据反馈给所述客户端，通过所述处理状态数据控制所述客户端继续按照设定周期发送所述业务请求。

8.如权利要求2所述的方法，其特征在于，将查找到的所述处理结果反馈给所述客户端，具体包括：

将查找到的所述处理结果反馈给所述客户端，通过所述处理结果控制所述客户端停止按照设定周期发送所述业务请求。

9.一种请求处理方法，其特征在于，包括：

周期性向服务器发送携带有业务数据的业务请求，以使得所述服务器在反馈所述业务数据对应的处理结果前，保持与所述业务请求的发送方的连接，以及所述服务器根据所述业务请求通过所述连接反馈对应于所述业务数据的处理结果或处理状态数据，其中，所述周期性的周期短于处理所述业务请求所对应的超时时长；

接收所述服务器反馈的处理结果或处理状态数据。

10.如权利要求9所述的方法，其特征在于，向服务器发送携带有业务数据的业务请求，具体包括：

基于建立的HTTP连接或HTTPS连接，按照设定周期，向所述服务器发送携带有业务数据的业务请求；

其中，所述设定周期短于处理所述业务请求所对应的超时时长。

11.如权利要求10所述的方法，其特征在于，所述方法还包括：

当接收到反馈的所述处理状态数据时，继续按照设定周期发送所述业务请求；

当接收到反馈的所述处理结果，停止按照设定周期发送所述业务请求。

12.一种请求处理装置，其特征在于，包括：

接收模块，接收客户端周期性发送的业务请求，以在向所述客户端反馈所述业务数据对应的处理结果前，保持与所述客户端的连接，其中，所述周期性的周期短于处理所述业务请求所对应的超时时长；

数据确定模块，确定所述业务请求所携带的业务数据；

查询处理模块，根据所述业务数据，查找与所述业务数据对应的处理结果或处理状态数据；

反馈模块，当查找到所述处理结果时，将查找到的所述处理结果通过所述连接反馈给所述客户端，当查找到所述处理状态数据时，将查找到的所述处理状态数据通过所述连接反馈给所述客户端，并在处理结果生成后，将生成的处理结果通过所述连接反馈给所述客户端。

13.如权利要求12所述的装置，其特征在于，所述接收模块，接收所述客户端通过http连接或https连接，按照设定周期发送的业务请求；

其中，所述设定周期短于处理所述业务请求所对应的超时时长。

14.如权利要求13所述的装置，其特征在于，所述查询处理模块，查找与所述业务数据对应的处理结果，并在未查找到所述处理结果时，查找对应于所述业务数据的处理状态数据。

15.如权利要求12所述的装置，其特征在于，所述查询处理模块，根据所述业务数据，生成结果查询键，在缓存中查找对应于所述结果查询键的处理结果。

16.如权利要求12所述的装置，其特征在于，所述查询处理模块，根据所述业务数据生成状态查询键，在缓存中查找对应于该状态查询键的处理状态数据。

17.如权利要求16所述的装置，其特征在于，所述装置还包括：请求处理模块，当所述查询处理模块未查询到所述处理状态数据或处理状态数据对应的处理状态为失败时，处理所述业务请求，并在所述缓存中更新所述状态查询键对应的处理状态数据，当生成处理结果后，将生成的所述处理结果存储于所述缓存中。

18.如权利要求13所述的装置，其特征在于，所述反馈模块，将查找到的所述处理状态数据反馈给所述客户端，通过所述处理状态数据控制所述客户端继续按照设定周期发送所述业务请求。

19.如权利要求13所述的装置，其特征在于，所述反馈模块，将查找到的所述处理结果反馈给所述客户端，通过所述处理结果控制所述客户端停止按照设定周期发送所述业务请求。

20.一种请求处理装置，其特征在于，包括：

请求发送模块，周期性向服务器发送携带有业务数据的业务请求，以使得所述服务器在反馈所述业务数据对应的处理结果前，保持与所述业务请求的发送方的连接，以及所述服务器通过所述连接反馈对应于所述业务数据的处理结果或处理状态数据，其中，所述周期性的周期短于处理所述业务请求所对应的超时时长；

请求接收模块，接收所述服务器反馈的处理结果或处理状态数据。

21.如权利要求20所述的装置，其特征在于，所述请求发送模块，通过http连接或https连接，按照设定周期，向所述服务器发送携带有业务数据的业务请求；

其中，所述设定周期短于处理所述业务请求所对应的超时时长。

22.如权利要求21所述的装置，其特征在于，所述装置还包括：请求控制模块，当所述请求接收模块接收到反馈的所述处理状态数据时，继续按照设定周期发送所述业务请求；

当所述请求接收模块接收到反馈的所述处理结果，停止按照设定周期发送所述业务请求。

Images