CN101621458A - 异步处理网络请求的方法和系统 - Google Patents

Abstract

本发明提出了一种异步处理网络请求的方法及其相应系统。该方法可以按照一定的规则对一部分网络请求进行存储，等待在适当的时候由网络服务提供者进行异步处理。本发明通过将网络请求进行异步处理的方案，缓解由于同一时刻大量在线用户发送网络请求对于服务器端所带来的压力，并且本发明无需对现有的网络服务器进行硬件或软件的实质性改动，其能够在保证用户体验不受实质性影响的同时，降低解决成本。

Description

异步处理网络请求的方法和系统

技术领域

本发明总体上涉及网络服务器对来自用户的网络请求的处理，特别的本发明涉及对网络请求的异步处理方法和系统。

背景技术

每个网络服务提供者都希望他们的网站拥有广泛的用户群并且能够在同一时间为尽量多的用户提供服务。特别是提供在线事务处理的网站，比如银行的网站，网上购物的网站等。对于这些网站而言，同时在线的用户数越多就意味着能够处理的事务量越大，进而网络服务提供者能够获得的收益也就越丰厚。但是，目前的状况是，网络服务器的处理能力和服务器的资源配置尽管可以应付平常的事务处理量，但是在高峰时段或者在线用户数突高的时刻会产生网络服务拥堵，甚至陷入瘫痪状态。终端用户和网络服务提供者之间通常使用HTTP协议进行通信。HTTP协议本身并不提供流量管理控制程序，也就是说大量的HTTP请求可能同时被发送到网络服务提供者。当这一情况发生时，网络服务器系统就可能崩溃，从而导致所有的终端用户都无法访问相关服务。

现有技术中，有若干种方法试图解决这一问题。最简单的途径是在基础网络架构设计时充分考虑高峰时段的最大用户量，从而按照最大用户量设计网络架构和负载能力。然而，这种过分理想化的解决途径难以适用到现实中的所有网络应用当中。因为充分估计未来的最大用户量并非易事，并且即便是精确的确定了可能的最大用户量，提供一个足够强壮的网络架构所耗费的成本可能也是难以接受的。更为重要的是，对于现存的大量网络服务提供者而言，更新服务器系统，包括其硬件系统是不现实的。

另外一种方法是对网络应用进行优化，包括限制同时交易的最大用户数，在高峰时段屏蔽一些事务处理应用。显然这样的限制措施将伤害大量终端用户的用户体验，从而间接造成网络服务提供者的用户流失。

有鉴于此，现有技术中缺少一种方法或系统，能够在不实质性改变现有的网络应用服务架构，又不影响终端用户的用户体验的前提下，为尽量多的用户提供网络服务。

发明内容

为了解决现有技术的上述问题，本发明提出了一种异步处理网络请求的方法及其相应系统。该方法可以按照一定的规则对一部分网络请求进行存储，等待在适当的时候由网络服务提供者进行异步处理。本发明通过将网络请求进行异步处理的方案，缓解由于同一时刻大量在线用户发送网络请求对于服务器端所带来的压力，并且本发明无需对现有的网络服务器进行硬件或软件的实质性改动，其能够在保证用户体验不受实质性影响的同时，降低解决成本。

具体而言，本发明提供一种异步处理网络请求的方法，包括：接收至少一个网络请求，判断所述网络请求是否需要进行异步处理，存储所述需要进行异步处理的网络请求，以及确定对所述存储的网络请求进行异步处理。

本发明还提供一种异步处理网络请求的系统，包括：接收单元，用于接收至少一个网络请求，判断单元，用于判断所述网络请求是否需要进行异步处理，存储单元，用于存储所述需要进行异步处理的网络请求，以及确定单元，用于确定对所述存储的网络请求进行异步处理。

通过本发明的方法和系统，可以将一部分网络请求暂时存储起来，留待系统闲时进行异步处理，从而一方面缓解了在系统忙时大量用户请求拥堵所带来的压力，并且在另一方面优化了用户在获得网络服务时的用户体验。

上述描述大致列举了本发明的优越之处，通过结合附图与本发明最佳实施例的详细说明，本发明的这些以及其它优点将更加明显。

附图说明

本说明中所参考的附图只用于示例本发明的典型实施例，不应该认为是对本发明范围的限制。

图1A为将等待异步处理的网络请求存储到请求队列的结构示意图。

图1B为将请求队列中存储的网络请求进行异步处理的结构式意图。

图2为异步处理网络请求的流程图。

图3为判断网络请求是否需要进行异步处理的流程图。

图4为通知用户网络请求将要进行异步处理的流程图。

图5为被存储的网络请求记录示意图。

图6为通知用户网络请求将要进行异步处理的用户界面。

图7为确定对存储的网络请求进行异步处理的流程图。

图8为异步处理网络请求的工作线程的流程图。

图9为异步处理网络请求的系统框图。

具体实施方式

下列讨论中，提供大量具体的细节以帮助彻底了解本发明。然而，很显然对于本领域技术人员来说，即使没有这些具体细节，并不影响对本发明的理解。并且应该认识到，使用如下的任何具体术语仅仅是为了方便描述，因此，本发明不应当局限于只用在这样的术语所标识和/或暗示的任何特定应用中。

除非另有说明，本发明所述的功能可用硬件或软件或它们的结合来运行。然而，在一优选实施列中，除非另有说明，这些功能是由处理器，如计算机或电子数据处理器，按照编码，如计算机程序编码，的集成电路来执行的。一般来说，为了实现本发明的实施例而执行的方法可以是操作系统或特定应用程序的一部分、程序、模块、对象或指令序列。本发明的软件通常包括将由本地计算机呈现成机器可读格式的众多指令，因此是可执行指令。此外，程序包括相对于程序来说驻留在本地或在存储器中找到的变量和数据结构。另外，下文描述的各种程序可以根据在本发明的特定实施例中实现它们的应用方法来识别。当携带指向本发明的功能的计算机可读指令时，这样的信号承载媒体代表本发明的实施例。

图1A为将等待异步处理的网络请求存储到请求队列的结构示意图。当大量的网络请求在同一时间发送到网络服务器102时，异步处理控制系统101可以将部分网络请求转送到被存储的网络请求队列中。

造成网络服务拥堵的原因可能是多种多样的，在本发明的一种实施例中，通过静态的时间控制对网络请求进行分散。具体而言，在可预测的高峰时段，分散网络请求以进行异步处理。比如，按照银行网站的经验统计，上午的办公时间9:00到11:00是网上银行事务处理最繁忙的时候，因此可以把时段9:00am-11:00pm定义为高峰时段，从而在这一时段对网络请求利用异步处理控制系统101进行干预。

在本发明的又一种实施例中，通过动态的网络服务器资源状态对网络请求进行分散处理。比如当监测到当前的网络银行服务器资源紧张，CPU利用率达到一定门限值，则在接下来的一段时间内对网络请求利用异步处理控制系统101进行干预，直到服务器资源使用情况恢复正常为止。

本领域的普通技术人员理解，本发明并不限于上述两种实施方式，在其它需要的情况下，也可以决定利用异步处理控制系统101对网络请求进行干预，比如根据前一特定时间段内收到的网络请求的数量来决定是否启动异步处理模式。

挑选特定的网络请求进行异步处理的标准也是多种多样的。在本发明的一种实施例中，某类请求消耗了大量的系统资源，但是这类请求对于用户而言并非需要及时处理，于是异步处理控制系统101对这类网络请求进行存储以待异步处理。表1示出了以网络银行为例的各类网络请求的特点，通过对这些请求特点的分析可以进一步挑选出进行异步处理的请求类型。

请求类型	CPU密集度	内存密集度	数据库操作密集度	主机交易操作密集度	网络密集度	等待响应时间
							余额查询	低	低	低	高	低	数秒
转帐	低	低	低	高	低	数小时
							明细查询	低	高	低	高	高	数小时
帐户管理	低	低	高	低	低	数秒
							登陆	高	高	高	高	低	数秒

表1

本领域的普通技术人员理解，某项资源的密集度高就意味着消耗的系统或网络资源多，相反如果密集度低就意味着消耗的系统或网络资源少。通过比较可以得知，转帐需要消耗大量的主机操作，从而等待时间相对较长，但是实际上用户并不需要立刻得到转帐操作的反馈，因此有关转让的网络请求可以被挑选出来进行异步处理。

在本发明的又一种实施例中，利用用户等级来决定是否对其网络请求进行异步处理。当用户的等级较高时，对其网络请求进行即时处理，但是当用户的等级较低时，对其网络请求进行异步处理。

当然，本领域的普通技术人员理解，本发明并不限于上述两种挑选方式，也可以按照其它的标准挑选需要进行异步处理的网络请求，比如根据用户的交易额度确定是否进行异步处理等等。

图1B为将请求队列中存储的网络请求进行异步处理的结构式意图。在网络请求的非高峰时段，异步处理控制系统101从被存储的网络请求队列中读取网络请求交给网络服务器102进行处理。

图2为异步处理网络请求的流程图。首先在步骤203接收至少一个网络请求，然后在步骤205判断所述网络请求是否需要进行异步处理，所述判断过程包括上文提到的对网络服务器系统的分析和对网络请求类型的分析。字母A表示步骤205的详细步骤将在图3中进行展开说明。在步骤207中，对所述需要进行异步处理的至少一个网络请求进行存储。并且在步骤209中，在特定的时间段，比如非高峰时段或者系统资源不紧张时，确定对所述存储的网络请求进行异步处理。字母B表示步骤209的详细步骤将在图7中进行展开说明。

图3为判断网络请求是否需要进行异步处理的流程图。所述判断步骤包括对网络服务器系统的分析和对网络请求类型的分析。如上文所述对网络服务器系统的分析可以是对系统时间的分析也可以是对系统资源状态的分析，甚至可以是除此以外的其它分析方法。然而在本实施例中，对系统时间和系统资源状态二者都进行分析。并且在本实施例中，通过网络请求所访问的URL对网络请求的类型进行分析，当然本领域的普通技术人员理解，本发明并不局限于这样的实施方式。

下面对判断网络请求是否需要进行异步处理的流程进行详细说明。在步骤301中，核实网络服务器系统时间。在步骤303中，判断网络服务器是否处于高峰时段。所述高峰时段可以是根据经验值事先定义的时间段。如果所述系统时间显示当前系统处于高峰时段，则在步骤305进一步核实网络服务器的资源状态信息，否则如果所述系统时间显示当前系统并非处于高峰时段，则在步骤315决定不对所述网络请求进行异步处理，并在步骤317返回以执行正常的网络请求处理程序。

所述资源状态信息可以包括下列各项中的一个或多个：网络服务器的CPU使用情况、内存使用情况、网络拥堵情况、数据库连接状况、网络服务器与其它交易主机的连接状况、每秒中处理的请求数量(TPS)、以及服务器响应时间等等。可以设计一系列门限值对上述资源状态信息进行判断。

在步骤307中，当核实后的资源状态信息显示系统资源紧张时，进一步在步骤309中核实网络请求所访问的URL信息，否则在步骤315决定不会所述网络请求进行异步处理，并在步骤317返回以执行正常的网络请求处理程序。

在步骤311中，当判断所述网络请求所访问的URL涉及可以异步处理的业务时，进一步在步骤313中决定对所述网络请求进行异步处理，否则在步骤315中决定不对所述网络请求进行异步处理，并在步骤317中返回以执行正常的网络请求处理程序。比如，以上文中提到的网络银行为例，在一种实施方式中，如果判断所述网络请求所访问的URL涉及转帐业务，则对该转帐请求进行异步处理，否则对该业务请求进行即时处理。由于网络请求所访问的URL信息是附带在用户发送的网络请求包中的，因此可以容易的从网络请求包中提取相应的URL信息进行分析。在另一种实施方式中，如果利用用户等级来决定是否对其网络请求进行异步处理，则需要读取网络服务器中的数据库从而调用相关的用户信息进行判断。

本领域的普通技术人员理解，图3中的三个判断步骤并非一定要按照图示的顺序进行，而是可以任意组合顺序，因为这三个判断步骤都是单独发挥作用的。

图4为通知用户网络请求将要进行异步处理的流程图。一旦判断某一网络请求需要进行异步处理，本发明可选的可以通知用户相关异步处理信息。结合图6，可以对所述通知过程进行更详细的描述。在步骤403中，本发明通知发送所述网络请求的用户所述网络请求将会进行异步处理，比如图6中的“Sorry，current system is under heavyworkload，your request will be processed later”。在步骤405中，通知用户访问所述异步处理结果的URL，比如图6中的“You can get visitthis website again to view the result after 1 hour.The access URL ishttps://www.ABCbank.com/user/assignment/result？id＝fdjkweDSfEfdsafdsawefFDSAFDSA”，这样用户可以到指定的URL地址中查看其网络请求处理结果。

在步骤407，通知发送所述网络请求的用户所述异步处理结果的预测完成时间(图6中未示出)，这样用户可以知道在多长时间以后，可以访问相关网页以获取或者检查其网络请求结果。所述预测完成时间的计算可以通过统计当前的等待处理的异步请求数量与系统资源消耗情况，再结合未来网络服务器处理能力的经验值来计算得到。

在步骤409，从发送所述网络请求的用户获得一个电子邮件地址，比如图6中的“You can also leave an email address，we will sendthe result to you”，以便将来将所述异步处理结果已经完成的消息通知用户。在步骤411中，将网络请求ID、是否等待异步处理、网络请求提出时间，网络请求通知信息等信息与网络请求所访问的URL、网络请求会话信息和网络请求内容一起封装成网络请求记录(如图5所示)。在另外一种实施方式中，也可以获取用户的手机信息，从而以短信的方式通知用户所述异步处理结果已经完成的消息(图6中未示出)。

图5为被存储的网络请求记录示意图501。每条记录包括与所述网络请求相关的下列信息：网络请求ID、是否等待异步处理、网络请求提出时间、网络请求所访问的URL、网络请求会话信息(requestcontext)、网络请求通知信息，如用户提交的电子邮件地址、手机号码等、以及网络请求的内容。其中所述是否等待异步处理的选项可以用以区分异步处理的网络请求和即时处理的网络请求。所述网络请求会话信息是与网络请求的内容相关的上下文会话信息。所述网络请求的内容是用户向网络服务器提交事务处理请求时所涉及的HTML页面中的信息。比如在网络银行的例子中，在用户登陆页面中用户输入的用户名、密码等信息就属于网络请求会话信息，而在最后访问的转帐页面中用户输入的转帐号码、转帐金额等信息就属于网络请求的内容。保存网络请求会话信息的原因在于一些网络请求的异步处理依赖于用户输入的上下文信息。

图7为确定对存储的网络请求进行异步处理的流程图。在步骤701中判断是否开始进行异步处理，比如可以在系统进入空闲时段后，或者在系统资源不再紧张时，开始进行异步处理。在步骤703中，读取异步批处理策略。虽然本发明并不限于在异步处理时使用批处理的方法，但是考虑到批处理能够在一个线程中执行所有请求，从而可以更有效的利用资源，因此在本实施例中，使用批处理的方法对存储的用户请求进行处理。

所述异步批处理策略可以决定将访问相同URL的用户请求进行批处理，或者将同一用户的网络请求进行批处理，或者将同一时间段的用户请求进行批处理等。并且，所述批处理策略还应当确定成批处理的请求数量。

在步骤705，读取网络请求的记录从而提取网络请求的相关信息。在步骤707，按照所述异步批处理策略建立批处理作业(batchjobs)，每个批处理作业都是一系列网络请求的集合。在步骤709，开始工作线程(worker threads)以处理网络请求，所述工作线程将一个接一个的处理网络请求。字母B1表示步骤709的详细步骤将在图8中进行展开说明。

图8为异步处理网络请求的工作线程的流程图。在步骤801中，判断工作队列中是否有网络请求。如果工作队列中有网络请求，则在步骤803中提取一个网络请求。并且在步骤805中将所述网络请求发送给网络服务器进行处理。在网络服务器处理完毕后，在步骤807获得处理结果，并在步骤809中存储处理结果，然后在步骤811中通知用户，并在步骤813中从工作队列中移除所述请求。

在一种实施方式中，所述通知用户的步骤可以是发送电子邮件给用户，告知其处理结果已经完成，可以到指定的URL处提取或查阅处理结果。在另一种实施方式中，所述通知用户的步骤也可以是发送手机短信给用户，告知其处理结果已经完成，可以到指定的网络URL或手机URL处提取或查阅处理结果。在又一种实施方式中，所述通知用户的步骤还可以是将所述处理结果直接发送到用户的电子邮件地址或以手机短信的形式发送给用户，比如告知用户转帐交易已经成功等等。当然，所述通知用户的步骤实际上并非是必需的，在一些情况下，可以无需通知用户而是由用户主动查询处理结果。

图9为异步处理网络请求的系统框图。其中接收单元921从网络服务器910中获得网络请求，并发送给判断单元922。判断单元922通过查询策略信息判断是否将所述网络请求进行异步处理。所述策略信息(图中未示出)可以包括系统方面的信息：高峰时段的时间信息、资源状态信息、每单位时间内所接收的网络请求门限值；以及用户方面的信息：网络请求的类型，比如所访问的URL地址，或者用户的等级等。如果确定对网络请求进行异步处理，判断单元922就为该网络请求封装上网络请求ID、是否等待异步处理、网络请求提出时间等信息，以形成网络请求记录501。并且如果确定对网络请求进行异步处理，异步处理控制系统920中的通知单元一(图中未示出)用于通知发送所述网络请求的用户所述网络请求将会进行异步处理。异步处理控制系统920中的通知单元二(图中未示出)用于通知发送所述网络请求的用户访问所述异步处理结果的URL。异步处理控制系统920中的通知单元三(图中未示出)用于通知发送所述网络请求的用户所述异步处理结果的预测完成时间。异步处理控制系统920中的获取单元(图中未示出)用于从发送所述网络请求的用户获取电子邮件地址。

如果确定对网络请求进行异步处理，判断单元922可以将所述网络请求发送给存储单元923。存储单元923可以将经封装的网络请求记录501存储到网络请求存储器(图中未示出)中。并且所述存储单元923还可以在确定单元924决定对所存储的网络请求进行异步批处理时，从网络请求存储器中调取所述网络请求。其中所述网络请求存储器可以是数据库或者磁盘设备等存储单元。

确定单元924通过查询策略信息判断是否需要恢复对网络请求的处理，并且建立批处理作业。在批处理完成后，确定单元924将处理结果存储到处理结果存储器(图中未示出)。其中所述处理结果存储器可以是数据库或者磁盘设备等存储单元。

本发明还可以包含一个结果服务器(图中未示出)用以向终端用户显示处理结果。所述结果服务器可以是FTP服务器、HTTP服务器、邮件服务器等。以HTTP服务器为例，当用户发送请求以查询处理结果时，结果服务器将会向用户返回指定的HTML网页。所述结果服务器可以和原始的网络服务器910合并工作，也可以作为单独的服务器进行工作。

本发明还可以包含通知单元四(图中未示出)用于向所述电子邮件地址发送通知以告知所述网络请求被处理完成。并且本发明还可以包含发送单元(图中未示出)发送单元用于将异步处理结果通过电子邮件发送给所述用户。本领域的普通技术人员理解，本发明也可以不向终端用户通知处理结果已经完成，并且也不将处理结果发送给用户，而是由用户主动查询处理结果。

以上系统中各单元的具体工作流程在方法相关的描述中已经充分描述，这里不在赘述。

本领域的普通技术人员理解，上述各个操作过程可以由存储在计算机程序产品中的可执行程序实现。该程序产品定义各实施例的功能，并承载各种信号，包括(但不局限于)：1)永久存储在不可擦写存储媒体上的信息；2)存储在可擦写存储媒体上的信息；或3)通过包括无线通信在内的通信媒体(如，通过计算机网络或电话网络)传送到计算机上的信息，特别是包括从因特网和其它网络下载的信息。

本发明的各种实施例可以提供许多优点，包括已经在发明内容中列举的，和能够从技术方案本身推导出来的。但是无论一个实施例是否取得全部优点，并且也无论这样的优点是否被认为是取得实质性提高，都不应构成对本发明的限制。同时，上文中提到的各种实施方式，仅仅是出于说明的目的，本领域的普通技术人员可以对上述实施方式做出各种修改和变更，而不偏离本发明的实质。本发明的范围完全由所附权利要求书限定。

Claims (20)

1.一种异步处理网络请求的方法，包括：

接收至少一个网络请求，

判断所述网络请求是否需要进行异步处理，

存储所述需要进行异步处理的网络请求，以及

确定对所述存储的网络请求进行异步处理。

2.如权利要求1所述的方法，进一步包括：

通知发送所述网络请求的用户所述网络请求将会进行异步处理。

3.如权利要求1所述的方法，进一步包括：

通知发送所述网络请求的用户访问所述异步处理结果的URL。

4.如权利要求1所述的方法，进一步包括：

通知发送所述网络请求的用户所述异步处理结果的预测完成时间。

5.如权利要求1所述的方法，进一步包括：

从发送所述网络请求的用户获取电子邮件地址，并向所述电子邮件地址发送通知以告知所述网络请求被处理完成。

6.如权利要求1所述的方法，进一步包括：

从发送所述网络请求的用户获取电子邮件地址，并将异步处理结果通过电子邮件发送给所述用户。

7.如权利要求1所述的方法，其中所述判断步骤根据所述网络请求的相关信息决定是否需要对所述网络请求进行异步处理，所述网络请求的相关信息包括网络请求所访问的URL或者发送网络请求的用户属性中的至少一个。

8.如权利要求1所述的方法，其中所述判断步骤根据时间信息决定是否需要对所述网络请求进行异步处理：

当网络服务器处于高峰时间段时，对所述网络请求进行异步处理。

9.如权利要求1所述的方法，其中所述判断步骤根据网络服务器的资源状态信息决定是否需要对所述网络请求进行异步处理：

当资源状态信息显示系统资源紧张时，对所述网络请求进行异步处理。

10.如权利要求1所述的方法，其中所述确定步骤根据时间信息或网络服务器的资源状态信息中的至少一个决定是否开始异步处理所述存储的网络请求。

11.一种异步处理网络请求的系统，包括：

接收单元，用于接收至少一个网络请求，

判断单元，用于判断所述网络请求是否需要进行异步处理，

存储单元，用于存储所述需要进行异步处理的网络请求，以及

确定单元，用于确定对所述存储的网络请求进行异步处理。

12.如权利要求11所述的系统，进一步包括：

通知单元一，用于通知发送所述网络请求的用户所述网络请求将会进行异步处理。

13.如权利要求11所述的系统，进一步包括：

通知单元二，用于通知发送所述网络请求的用户访问所述异步处理结果的URL。

14.如权利要求11所述的系统，进一步包括：

通知单元三，用于通知发送所述网络请求的用户所述异步处理结果的预测完成时间。

15.如权利要求11所述的系统，进一步包括：

获取单元，用于从发送所述网络请求的用户获取电子邮件地址，以及

通知单元四，用于向所述电子邮件地址发送通知以告知所述网络请求被处理完成。

16.如权利要求11所述的系统，进一步包括：

获取单元，用于从发送所述网络请求的用户获取电子邮件地址，以及

发送单元，用于将异步处理结果通过电子邮件发送给所述用户。

17.如权利要求11所述的系统，其中所述判断单元根据所述网络请求的相关信息决定是否需要对所述网络请求进行异步处理，所述网络请求的相关信息包括网络请求所访问的URL或者发送网络请求的用户属性中的至少一个。

18.如权利要求11所述的系统，其中所述判断单元根据时间信息决定是否需要对所述网络请求进行异步处理：

当网络服务器处于高峰时间段时，对所述网络请求进行异步处理。

19.如权利要求11所述的系统，其中所述判断单元根据网络服务器的资源状态信息决定是否需要对所述网络请求进行异步处理：

当资源状态信息显示系统资源紧张时，对所述网络请求进行异步处理。

20.如权利要求11所述的系统，其中所述确定单元根据时间信息或网络服务器的资源状态信息中的至少一个决定是否开始异步处理所述存储的网络请求。

Images