CN102480512B - 用于扩展服务器端处理能力的方法和装置 - Google Patents

Abstract

本发明的实施方式涉及扩展服务器端处理能力的方法和装置。在一实施方式中，提供了一种用于扩展服务器端处理能力的方法，包括：确定需要从服务器端卸下的作业；将作业划分为一个或多个任务；响应于一个或多个客户端发出的http请求，向一个或多个客户端分配一个或多个任务；以及从一个或多个客户端发送的http请求中，接收一个或多个客户端对一个或多个任务的响应。在一实施方式中，提供了一种用于扩展服务器端处理能力的装置。

Description

用于扩展服务器端处理能力的方法和装置

技术领域

本发明的各实施方式涉及数据处理，并且更具体地涉及用于扩展服务器端处理能力的方法、装置和相关计算机程序产品。

背景技术

计算机技术的发展为需要大规模数据处理能力的应用程序提供了硬件保障，在网络技术以及分布式计算技术的支持下，可以建立服务器构成的数据中心，并通过多个服务器以协作方式执行需要超大规模数据处理能力的应用程序。然而，对于某些运算而言，单纯依靠服务器端的处理能力也不能完成运算操作，此时需要开发新的解决方案以实现对服务器端的处理能力进行扩展或分配。

在具有数百万甚至上千万用户的大型网站中，当众多用户同时进行查询或者针对网站中的某些数据编制索引时，通常需要极大规模的数据处理能力。现在仅以购物网站为示例，概述可以扩展服务器端的处理能力的方案。就购物网站的服务器端而言，可以划分为两种类型的服务器：一类是web应用服务器，而另一类是分析服务器，两种类型的服务器共享相同的物理主机资源。Web应用服务器通常用于运行支持前端web服务所需的应用程序，而分析服务器通常用于提供其他相关的分析数据的功能。

图1A示意性示出了根据一个解决方案的服务器端113配置的架构图。在方案一110中，当用户114的数量较小时，可以分配较少数量的服务器用作web服务器111，此时可以使用较多的服务器用作分析服务器112。然而，随着用户的增加，web服务器端113承受的工作负载很可能成倍甚至呈指数地增加，此时必须购买更多的硬件服务器用作web服务器111，以提供更多数据处理能力以适应于越来越高的需求。

在不增加硬件投资的情况下，图1B示意性示出了一种用于改善服务器端的处理能力的方案的架构图。方案二120可以在服务器端123的各服务器之间重新划分工作职能，例如，可以指派更多的服务器担任web服务器121，并指派较少的服务器用作分析服务器122。

发明内容

尽管上述方案可以在一定程度上解决web服务器121资源紧缺的问题，然而压缩分析服务器122的数量将会导致分析能力下降、反馈时间过长等诸多问题。此时，在不增加分析服务器的硬件投入的前提下，如何调动其他可用资源来提高服务器端的处理能力成为一项亟待解决的问题。

因而迫切需要提供一种方法，以便在不增加硬件投资的前提下，方便、可靠地提高服务器端的处理能力；并且还希望能够尽可能少地改变现有硬件和软件配置，并且以易于部署的方式实现对服务器端的处理能力进行扩展或重新分配。

根据本发明的一个实施方式，提供了一种用于扩展服务器端处理能力的方法。该方法包括：确定需要从服务器端卸下的作业；将作业划分为一个或多个任务；响应于一个或多个客户端发出的http请求，向一个或多个客户端分配一个或多个任务；以及从一个或多个客户端发送的http请求中，接收一个或多个客户端对一个或多个任务的响应。

根据本发明的另一实施方式，还包括：选择一个或多个客户端用于执行一个或者多个任务。

根据本发明的另一实施方式，其中确定需要从服务器端卸下的作业包括：判断服务器端的当前负载水平；以及响应于确定当前负载水平即将或者已经超过阈值负载水平，指定从服务器端卸下的作业。

根据本发明的另一实施方式，其中向一个或多个客户端分配一个或多个任务包括：基于一个或多个客户端的属性，将一个或多个客户端进行分组；以及以组为单位向一个或多个客户端分派与组相匹配的任务。

根据本发明的一个实施方式，提供了一种用于扩展服务器端处理能力的设备。该设备包括：确定装置，用于确定需要从服务器端卸下的作业；划分装置，用于将作业划分为一个或多个任务；分配装置，响应于一个或多个客户端发出的http请求，用于向一个或多个客户端分配一个或多个任务；以及接收装置，用于从一个或多个客户端发送的http请求中，接收一个或多个客户端对一个或多个任务的响应。

根据本发明的一个实施方式，还包括：选择装置，用于选择一个或多个客户端用于执行一个或者多个任务。

根据本发明的一个实施方式，其中所述确定装置包括：判断装置，用于判断服务器端的当前负载水平；以及指定装置，用于响应于确定当前负载水平即将或者已经超过阈值负载水平、指定从服务器端卸下的作业。

根据本发明的一个实施方式，其中所述分配装置包括：分组装置，用于基于一个或多个客户端的属性，将一个或多个客户端进行分组；以及分派装置，用于以组为单位向一个或多个客户端分派与组相匹配的任务。

采用根据本发明的各实施方式，可以在不增加硬件投资的前提下，方便、可靠地提高服务器端的处理能力，并且还可以以易于部署的方式实现对服务器端的处理能力进行扩展或重新分配。

附图说明

结合附图并参考以下详细说明，本发明各实施方式的特征、优点及其他方面将变得更加明显，在附图中：

图1A示意性示出了根据一个解决方案的服务器端配置的架构图；

图1B示意性示出了一种用于改善服务器端的处理能力的方案的架构图；

图2示意性示出了根据本发明一个实施方式的对服务器端的处理能力进行扩展或分配的架构图；

图3示意性示出了根据本发明一个实施方式的对服务器端的处理能力进行扩展或分配的方法的流程图；

图4示意性示出了根据本发明一个实施方式的向服务器端的客户端分配任务的方法的流程图；

图5A和图5B分别示意性示出了根据本发明一个实施方式的服务器端一侧的处理的流程图，其中图5A示出了服务器端的负载检查流程，而图5B示出了服务器端的事件处理流程；

图6A至图6D示意性示出了如图5B所示的处理流程中的详细操作，其中图6A示出了新客户端登录的处理流程，图6B示出了任务结果返回的处理流程，图6C示出了请求卸下作业的处理流程，而图6D示出了任务处理的处理流程；以及

图7示意性示出了根据本发明一个实施方式的对服务器端的处理能力进行扩展或分配的设备的框图。

具体实施方式

附图中的流程图和框图，图示了按照本发明各种实施方式的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，所述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为备选的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

在下文中，将仅以一个购物网站为示例，具体阐明根据本发明的示例性实施方式的方法的处理流程。应当注意，根据本发明的一个实施方式，各种方法、装置和计算机程序产品并不仅限于在以购物网站为代表的基于web的应用中执行，而是还可以在各种其他的应用中执行。

客户端可以以各种方式访问服务器端，本说明书中仅以访问由服务器端提供的web页面的方式连接至服务器端为示例，然而客户端一方的计算设备还可以通过其他应用来经由网络访问服务器端。例如可以通过特定的应用程序或者通过安装插件的方式访问服务器端。

还应当注意，尽管在说明书中以普通计算机终端作为客户端的具体示例，并且以普通计算机终端以web方式访问服务器端作为具体示例；应当理解，客户端还可以包括具备数据处理能力的各种计算终端，诸如，台式计算机、膝上型计算机、平板计算机、工作站等。随着计算设备逐渐小型化以及处理能力的增强，客户端还可以包括个人数字助理、智能电话以及移动终端等便携式移动计算设备。

应当注意，尽管在本发明的实施方式中采用购物网站中的分析服务器为示例，然而本发明的实施方式并不限于上述示例，而是可以包括可以将其上运行的作业划分为在多个计算终端上执行的任何服务器。还应当注意，在此所述的对作业进行划分，需要考虑到该作业的紧急程度、实时性、保密性等诸多因素；并非所有作业均适合于在连接至服务器端的客户端上执行。采用本发明的方法，可以使连接至服务器端的众多客户端分担原本需要服务器端执行的任务，并进而降低服务器端的工作负荷。

根据本发明的一个实施方式，优势在于可以以对客户端透明的方式实现扩展服务器端的处理能力。例如，用户不必安装用于接收分配任务和返回处理结果的专用应用程序，服务器端可以响应于客户端发出的http请求而向其分配任务，并且服务器只需从客户端发送的请求中接收对任务的响应即可。此外，客户端无需安装用于执行任务的专用应用程序，所分配的任务可以以任务描述的方式实现，客户端仅需基于任务描述即可完成所分配的任务。

图2示意性示出了根据本发明一个实施方式的对服务器端的处理能力进行扩展或分配的架构图200。根据本发明的一个实施方式，当服务器端(例如，分析服务器220)资源短缺时，可以协作地利用连接至分析服务器220的客户端的处理能力，以提高服务器端的整体数据处理能力。

不同于图1A和图1B所示的方案，在如图2所示的实施方式中，用户240所使用的客户端与分析服务器220之间的交互并不仅限于客户端请求数据并且从分析服务器220接收数据的常规操作，该客户端还可以接受分析服务器220分配的任务以及相关的待处理数据，并在根据任务描述处理了相关的待处理数据之后，向分析服务器220返回处理结果。此时，服务器端通过将自己的作业划分为适当大小的任务，向合格的客户端分配任务和相关待处理数据，并从客户端接收处理结果，来实现由用户240的客户端分担原先需要由分析服务器220自身执行的作业中的一部分。

在下文中，将参考图3至图7描述根据本发明的一个实施方式的方法的工作流程及***架构。图3示意性示出了根据本发明一个实施方式的对服务器端的处理能力进行扩展或分配的方法的流程图300。如图3所示，根据本发明的一个实施方式，用于对服务器端的处理能力进行扩展或分配的方法开始于步骤S302。在步骤S302中，首先确定需要从服务器端卸下的作业。应当注意，在此的“卸下”操作泛指将原本应当由服务器端的计算设备执行的作业，重新指派由其他计算设备执行的过程。被卸下的作业可以是服务器端刚刚被分配的尚未执行的新的作业，还可以是正在被执行的、但是因服务器端负载过重而需要由其他计算设备分担的作业。应当注意，在确定需要卸下的作业时，可以考虑服务器端的当前负载、服务器端的处理能力、作业的保密级别、作业的响应时间等因素。例如，可以考虑在服务器端优先执行保密级别高、需要尽可能实时响应的作业，并且可以选择首先卸下保密级别较低、对响应时间要求较低的作业，以便由客户端执行。

在步骤S304中，将步骤S302中确定的作业划分为一个或多个任务。应当注意，根据本发明的一个实施方式，服务器端可以基于预定义的规则划分该作业。例如，划分时可以确定任务的颗粒度，可以确定与任务相对应的待处理数据等。应当注意，基于客户端的计算能力、客户端与服务器端之间的网络连接状况等因素，为确保服务器端可以从至少一个客户端接收到响应，通常向客户端分配的任务具有较小的颗粒度，并且需要采取冗余机制(例如，向多个客户端分配相同的任务)等。根据一个实施方式，在对作业进行划分时，每个任务可以具有不同的颗粒度，每个任务所对应的待处理数据也可以具有不同的大小。

在步骤S306中，响应于客户端发出的http请求，向一个或多个客户端分配一个或多个任务。应当注意，可以设置不同的分配策略，例如可以限定一个客户端只能同时执行一个任务，直到已经完成任务并向服务器端提交任务执行的结果后才可以获得下一个任务；也可以定义一个客户端可以同时执行来自相同作业的多个任务，或者一个客户端可以执行来自不同作业的多个任务，等等。应当注意，任务分配是响应于客户端发出的http请求而执行的，例如，当服务器端检测到有客户端登录，即可执行任务分配操作。根据一个实施方式，只要客户端在一次登陆后保持连接到服务器端，则可以向该客户端分配任务。在客户端已经完成一个任务后，服务器端还可以根据自身策略向该客户端分配其他一个或者多个任务，或者不再向该客户端分配任务。当客户端断开了与服务器端的连接后(例如，关闭了web页面)，则服务器端不再向该客户端分配任务。另外，客户端还可以接收来自不同数据中心中的服务器的多个任务。

继而，在步骤S308中，从一个或多个客户端发送的http请求中，接收一个或多个客户端对一个或多个任务的响应。根据本发明的一个实施方式，还可以包括针对客户端未响应的异常情况进行处理。在步骤S306和S308中，任务分配和接收客户端对任务的响应均以http请求的方式实现，无需改变客户端的现有配置。

根据本发明的一个实施方式，还可以包括：选择服务器端(例如，位于数据中心处)的一个或多个客户端用于执行一个或者多个任务。应当理解，可能存在数百万的客户端同时连接至服务器端的情况，该选择步骤的目的在于从可用客户端中选择适合于执行任务的客户端，以便可以更加及时、准确地完成任务。可以将客户端的属性作为筛选标准来选择适用于执行任务的客户端。在一个实施方式中，可以选择硬件配置较高、工作负载较轻、网络连接状况较好的客户端，或者还可以进行随机选择或者选择正在访问服务器的全部客户端，等等。

根据本发明的一个实施方式，确定需要从服务器端卸下的作业包括：判断服务器端的当前负载水平；以及响应于确定当前负载水平即将或者已经超过阈值负载水平，指定从服务器端卸下的作业。

根据本发明的一个实施方式，在确定需要卸下的作业时，服务器端可以首先检查自己当前的工作负载。如果当前服务器端的负载较小，则可以将新的作业完全在服务器端完成；如果服务器端此时已经接近满负荷，则可以将作业中的一部分分配给服务器端的主机执行，而将其余部分分配给客户端执行，或者还可以将该作业全部分配给客户端完成；另外，如果服务器端在执行作业过程中，发现当前负载水平即将或者已经超过阈值负载水平，还可以将正在由服务器端执行的作业从服务器上移除并将其进一步进行划分，继而指派由客户端执行该作业中服务器端尚未完成的被移除部分。根据本发明的一个实施方式，该被卸下的作业在后续将被划分为一个或者多个任务，以用于在一个或者多个客户端上执行。在下文中，将参见图5A详述在服务器端进行负载检查的流程。

现在参考图4，该图示意性示出了根据本发明一个实施方式的向服务器的客户端分配任务的方法的流程图400。在步骤S402中，基于一个或多个客户端的属性，将一个或多个客户端进行分组。在分组时，可以考虑连接至服务器端的客户端的共性，将具有相同属性的客户端划分为相应分组，可以在分配任务时选择更适合于分组中的客户端执行的任务。

客户端的属性可以包括以下中的一项或者多项：客户端的处理能力、客户端的当前负载、客户端的响应时间、客户端的受信程度、客户端到服务器端的路由状况、客户端的任务完成历史、客户端与服务器端之间的协议等。

本发明的实施方式的思想在于，以协作方式利用客户端的处理能力。这种协作方式对用户而言可以是透明的，即无需用户过多人工参与，也无需对客户端的应用程序进行修改。例如，可以在服务器端与客户端之间预先签署处理能力共享的协议，即预先约定服务器端可以向客户端分配任务，并且客户端承诺执行该任务并向服务器端返回处理结果。客户端在同意该协议之后，即可以接受服务器端分配的任务并且执行后续操作。根据不同的商业运营模式，还可以以其他方式实现协作共享客户端的处理能力，在此并不过多讨论运营过程中所涉及的商业模式和法律问题。

可以以组为单位向一个或多个客户端分派与组相匹配的任务。例如，可以将处理能力较强的客户端设置为一个分组，由此可以向该分组中的客户端分配需要较高处理能力的任务。例如，可以向其分配计算复杂性高、计算量大的任务，或者可以向其分配较大的待处理数据块。又例如，如果基于以往的经验得知某些客户端的响应时间非常短，则可以将这些客户端分类为一个分组，并向该分组分配对于响应时间要求较高的任务。再例如，如果某些客户端的任务完成历史显示其以往执行任务的完成率很高，则可以将这些客户端分类为一个分组，并优先向该分组分配任务。还可以根据服务器端与客户端之间的不同服务协议，将客户端划分至不同的分组。例如，如果客户端同意在夜间(例如，00:00至06:00)贡献自己的计算能力并确保在该时段中连接至服务器端，则服务器端可以将类似情况的客户端划分至相同的分组，并且在夜间持续向该分组中的客户端分配任务。

根据本发明的一个实施方式，向一个或多个客户端分配一个或多个任务包括：响应于一个或多个客户端登录到服务器端，向一个或多个客户端发送与一个或者多个任务相对应的任务描述以及待处理的数据。应当注意，向客户端分配任务是以客户端连接至服务器端为条件的。根据一个实施方式，例如可以在客户端访问服务器端的某页面时向其分配任务，并且在客户端保持连接至服务器端的时段中，服务器端可以利用客户端的处理能力，而当客户端离开该页面后，则不能利用该客户端的处理能力。应当注意，根据本发明的一个实施方式，客户端可以采用基于web的方式访问服务器端。应当对在此所述的web方式作出宽泛的解释，该方式包括但不限于访问服务器端提供的web页面等，而是还可以包括目前已经存在以及将在未来开发的各种基于web的访问方式。根据服务协议，可以在客户端登录至服务器端期间，向客户端分配任务。

本发明的实施方式的一个优点在于，可以在不向客户端额外安装新应用程序的情况下，利用客户端的计算能力。其原因在于分配任务时，向客户端发送待处理的数据的同时，还发送与任务相对应的任务描述。由此，客户端便可利用接收到的任务描述来处理待处理的数据。任务描述可以包括以下中的一项或者多项：输入数据描述、输出数据描述以及处理算法，或者可以包括处理算法的描述。

例如，在购物网站的日志中仅记录了每笔交易记录(例如，在某时间卖出了多少件商品，并且该商品单价为多少元/件)的情况下，假设一个作业是希望计算最大的单笔交易金额以及对应的商品名称，可以将该作业进行如下划分：

假设日志中记录了10000条交易记录，则例如可以将记录划分为1000个数据片段，并且向每个客户端分配任务(在设置了客户端分组的情况下，还可以向一个客户端的分组分配任务)，以计算一个数据片段中的最大单笔交易金额。此时，可以将任务描述以及相应的待处理数据发送至客户端(或者客户端的分组)。在不考虑客户端分组的情况下，则服务器端可以向1000个客户端发送任务，而每个待处理数据可以是包括10条交易记录的数据片段。考虑到客户端的可信度以及网络状况等原因，为保证作业的最终结果的准确性，还采用其他可以提高可信度的分配方式，将在下文详述具体示例。

根据本发明的一个实施方式，任务描述可以是：

{输入数据：包括10条交易记录的日志数据，其中每条数据记录中包括：商品名称：a；售出商品数量b、以及商品单价c；

输出数据：最大单笔交易金额，商品名称；

算法：最大单笔交易金额＝b×c，商品名称＝a}

接收到任务描述的每个客户端可以采用上述算法计算针对10条交易记录的处理结果。可以采用脚本技术(诸如，AJAX技术)描述该算法，或者采用客户端能够直接或者间接执行的其他程序来描述该算法。服务器端在接收到1000个客户端返回的处理结果，例如二元组(最大单笔交易金额，商品名称)时，仅需在1000个二元组中选择具有“最大单笔交易金额”的二元组即可，而无需针对10000条记录日志中的数据进行逐一比较。

根据本发明的一个实施方式，将作业划分为一个或多个任务是基于预定规则进行的，预定规则涉及以下至少一项：任务的颗粒度、作业的计算量、作业的优先级、作业的保密级别等。例如，当作业的计算量大时，可以将作业划分为计算量相对较小的更多数量的任务，从而客户端可以在较短时间内完成每个任务，并且尽快向服务器端返回处理结果。例如，可以考虑优先处理高优先级的作业，在划分后将相应的任务分配给处理能力高、响应时间快、并且更为受信的客户端。例如，可以基于作业的保密级别，将保密级别较高的作业划分为较少数量的任务，并且分配给更为受信的客户端执行，以降低在任务分配和回收结果的过程中遭受侵害的风险。

应当注意，在确定任务的颗粒度时，可以基于客户端先前执行任务的经验而动态设置。例如，在以往执行任务的过程时，由于任务颗粒度过大而导致大量客户端在预定响应时间内没有计算得出处理结果，则可以在后续设置较小的任务颗粒度；反之亦然。应当注意，设置任务颗粒度时还可以考虑客户端的属性。对于一个作业而言，在划分时可以设置多个任务颗粒度，也即可以将作业划分为大小不同的多个任务，以便向不同的客户端和/或客户端分组分配相应的任务。

根据本发明的一个实施方式，还可以包括：基于一个或多个客户端对一个或多个任务的响应，生成作业的至少一部分处理结果。在此，生成作业的至少一部分处理结果的过程是指，聚合来自多个客户端的响应，获得处理结果。例如在上文示例中计算购物网站的最大单笔交易金额以及对应的商品名称时，服务器端接收来自1000个客户端的处理结果，例如接收到1000个二元组(最大单笔交易金额，商品名称)后，从中选择具有“最大单笔交易金额”的二元组的过程。

另外，在仅从服务器端卸下了一部分作业(例如，由服务器端计算5000条日志记录中的“最大单笔交易金额”和对应的商品名称，而由客户端处理另外5000条日志记录)时，如果任务划分方式不变，则服务器端仅需基于来自500个客户端的响应(即，500个二元组)，生成该作业的至少一部分(即，针对5000条日志记录)的处理结果。

根据本发明的一个实施方式，生成作业的至少一部分处理结果还包括：获取来自一个或多个客户端的响应的可信度；以及根据可信度提供作业的至少一部分处理结果。上文中已经简述了如何确保最终结果可信度的原理，现在将详述具体操作流程。

由于本发明的实施方式的思想在于以协作方式利用客户端的处理能力，然而由于客户端通常经由互联网连接至服务器端，并且接受服务器端所分配任务的客户端可以不断变化。此时，确保来自各客户端的处理结果的可信度才有可能保证作业的最终处理结果的可信度。

可以采用判断一致性的方式估计来自客户端的响应的可信度。例如，可以将一个任务以及相应的处理数据发送至多个客户端，以便保证至少一个客户端可以返回处理结果；还可以综合比较来自多个客户端的、针对相同任务和相应待处理数据的处理结果，例如分析多个处理结果的一致性，选用与多数处理结果相一致的处理结果；还可以向客户端的分组分配任务；向多个客户端的分组分配相同的任务，并且比较来自该多个分组的处理结果的一致性，并且选用一致性程度较高的处理结果。根据本发明的一个实施方式，还可以采用例如多个处理结果“求平均”的方法。应当注意，这里的“求平均”并非数学上的简单求均值，而是可以基于来自多个客户端的处理结果，求解得出最可信的结果的过程。

又例如，当利用来自客户端的响应生成至少一部分作业的处理结果时，如果最终处理结果与以往的经验值不一致、与已有标准相悖、或者是有违常理，则可以丢弃来自这些客户端的响应。并且利用服务器端自身的处理能力、或者选择更可信的客户端来再次分配任务。应当注意，根据本发明的一个实施方式，上述向客户端分配任务的所有操作，还适用于向客户端分组分配任务。根据本发明的一个实施方式，还可以将一个作业以不同的任务颗粒度划分为不同任务集合，并且将所得的任务集合分配给不同的客户端分组进行处理，并比较来自各分组的处理结果判断可信度。

在上文中，已经参见图2至图4阐明了根据本发明的一个实施方式的向服务器端的客户端分配任务的方法。现在将参考图5A、图5B以及图6A至图6D详述根据本发明方法的、在服务器侧执行处理的细节。

图5A和图5B分别示意性示出了根据本发明一个实施方式的服务器侧的处理的流程图。如图5A所示，其中图5A示出了服务器侧的负载检查流程510。根据本发明的一个实施方式，需要在预定的时间间隔检查服务器侧的当前负载，以便确保服务器在负载过高时可以从中“卸下”一部分作业由客户端执行。如流程510所示，在步骤S512中，检查服务器侧的当前负载；继而在步骤S514中查询规则。应当注意，此处的规则可以是预定义的规则，例如设置了需要从服务器侧卸下作业的条件，诸如，服务器端处理能力负载的阈值、优先卸下哪些作业、不适于卸下哪些作业等。另外，该规则还可以根据服务器端完成作业的情况而动态变化，也可以由管理员基于经验进行设置。

在步骤S516中，判断是否需要从服务器端卸下作业，如果需要卸下作业，则流程前进至步骤S518，以发送卸下请求；如果不需要卸下作业，则流程前进至步骤S520。该步骤S520对下一次检查的间隔进行控制，例如可以设置间隔控制定时器，在该定时器到时时，再次重复操作S512以执行下一轮的负载检查。在执行步骤S518后，流程转向步骤S520以等待下一次检查。应当注意，步骤S512至S520是循环执行的过程，只要服务器端处于运行状态，则执行该过程，以便基于服务器端的当前负载而判断是否需要利用客户端的处理能力。

现在参见图5B，该图示出了服务器侧的事件处理流程530。应当注意，与图5A中的负载检查流程类似，事件处理流程530也是在服务器端运行期间循环执行的操作。为方便示出起见，以符号“A”作为每一轮次事件处理的开始点，以符号“B”作为每一轮次事件处理的结束点。图5B示出的5个步骤均以起点“A”开始并以终点“B”结束，并不意味着这5个步骤在每个轮次中严格地并行执行，而是可以响应于相应事件的发生、以不同的时间间隔执行，并不排除两个或者更多步骤同时执行的情况。

如图5B所示，服务器端运行过程中需要处理以下事件：S532新客户端登录、S534请求卸下作业、S536任务处理、S538任务结果返回以及S540超时。应当注意，针对一个轮次的处理而言，在从S534请求卸下作业到S538任务结果返回的过程中，步骤S534至S538可以按照顺序执行。然而，针对不同轮次而言，步骤S534至S538的执行不具有必然的先后关系，也不必完全并行执行。例如，在执行S534请求卸下作业的同时，可以执行另一作业的S536任务处理，也可以执行针对又一作业的S538任务结果返回。

应当注意，图示的S540超时步骤是针对服务器已经向客户端分配了任务，然而在规定时间段内没有收到预期返回结果情况的处理。当服务器端发现出现超时事件时，处理可以包括：1)更新任务完成状态的统计，由于出现超时情况的任务并未被完成，因而需要将该已超时的任务标记为“未完成”，也即更新各任务的完成状态。2)向任务列表中添加任务，对于“未完成”的任务，需要将其重新分配给客户端处理，此时的重新分配类似于步骤S536任务处理中的操作，将在下文详述。3)标记可用分组，在超时之后，执行任务超时的分组处于空闲状态，因而可以将该分组标记为“可用”，以便执行其他被分配的任务。

下文将参考图6A至图6D阐明对于其他事件的处理流程，其中符号“A”和“B”分别对应于图5B所示中每一轮次事件处理的开始点和结束点。

如图6A所示，该图示出了如图5B所示新客户端登录的处理流程S532的细化。在本轮次操作中，响应于出现新客户端登录的事件，在步骤S610中，首先获取客户端的信息，例如该信息可以是客户端的属性，诸如客户端的处理能力、客户端的当前负载、客户端的响应时间、客户端的受信程度、客户端到服务器端的路由状况、客户端的任务完成历史、客户端与服务器端之间的协议等，还可以是与新登录的客户端相关联的其他信息。继而在步骤S612中查询规则，此处的规则是对客户端进行分组的规则。例如，在已经存在针对特定类型客户端的分组的情况下，还可以是将具备哪些属性的客户端添加至该分组的规则。

在步骤S614中，判断是否将该客户端添加到客户端分组，如果不需要将其添加至客户端分组，则流程前进至步骤S624并忽略该客户端，继而本轮次的处理新客户端登录的事件结束，操作流程继续等待其他事件。如果在步骤S614中的判断为“是”，则流程前进至步骤S616以检查分组列表。接着，在操作S618中，判断是否将客户端添加到新的分组，如果判断为“是”，则前进至步骤S626以创建新的分组；否则，流程前进至步骤S620，并将客户端添加至现有的客户端分组。继而，在步骤S622中，更新客户端分组列表，并且本轮次的事件处理结束。应当注意，根据本发明的一个实施方式，上述创建新分组以及向现有的分组添加客户端是基于步骤S610以及S612中获取的客户端信息和规则进行的。

如图6B所示，该图示出了如图5B所示请求卸下作业的处理流程S534的细化。在本轮次操作中，响应于出现请求卸下作业的事件，在步骤S630中，查询规则，该规则规定了可以卸下哪种类型的作业、不能卸下哪种类型的作业、以及在同时存在多个可卸下的作业时的优先顺序等。继而，在步骤S632中检查作业的完成状况，并在步骤S634中判断是否需要调整任务的颗粒度，如果不需要调整，则操作前进至步骤S640以将任务添加至任务表；如果需要调整，则操作前进至步骤S636以重新设置任务的颗粒度。根据本发明的一个实施方式，可以基于客户端先前执行任务的经验而动态设置任务的颗粒度。继而，在步骤S640中，将任务添加至任务表，以便由如图5B所示的任务处理过程S 536进行调度。此时，针对请求卸下作业事件的处理结束，进入等待其他事件的状态。

如图6C所示，该图示出了如图5B所示任务处理的处理流程S536的细化。应当注意，针对任务处理事件的操作是本发明的实施方式的一个重要操作流程，流程控制服务器端以协作方式利用客户端的处理能力的主要过程。

在本轮次操作中，响应于出现任务处理的事件，在步骤S650中，检查客户端分组的表，并且在步骤S652中判断是否使用新的客户端分组，如果判断为“是”，则操作流程前进至步骤S654以便向分组中的客户端分配任务；如果步骤S652中的判断为“否”，则流程前进至步骤S662以判断是否具有可用分组。如果步骤S662中判断得出没有可用分组，则流程前进至步骤S664以记录日志，并且向服务器端的事件调度器报告当前没有可用分组。在步骤S654之后，在步骤S656中更新记录，在步骤S658中标记客户端分组被占用，并且在步骤S660中，启动针对正在被处理的任务的定时器。此时，针对任务处理事件的处理结束。应当注意，步骤S660中的定时器，即在图6D的步骤S680中所述的定时器。图6C任务处理流程的步骤S660作为定时器启动的起点，而图6D任务结果返回流程的步骤S680作为定时器停止的终点。尽管一始一终两个步骤在不同的事件处理流程中执行，然而对于同一个任务而言，这两个操作是针对相同定时器的设置，以便指示客户端分组在指定时间内是否完成了对任务的处理并向服务器端返回结果，并且在未能在指定时间内完成任务时，经由如图5B中的事件S540所示，调取相应的超时操作。

如图6D所示，该图示出了如图5B所示任务结果返回的处理流程S538的细化。在本轮次操作中，响应于出现新客户端登录的事件，在步骤S670中，检查任务表，在该任务表中可以保持从作业划分而来的任务的信息，例如，任务与作业的对应关系、任务的当前状态(诸如，尚未分配、已分配、已完成)、任务客户端分组以及该客户端分组中的客户端的对应关系等。在步骤S672中，查询返回任务结果相关的规则，并在步骤S674中判断结果是否足够可信，例如可以采用上文所述的一致性标准的方法判断结果的可信度，或者还可以采用其他方法。

当步骤S674的判断结果为“否”(也即不可信)时，则流程前进至步骤S684并保存结果，接着在步骤S686中更新结果的数量，继而针对该事件的处理结束；如果步骤S674的判断结果为“是”，也即可信时，则流程前进至步骤S676以标记任务完成，在步骤S678中标记客户端分组可用，继而在步骤S680中停止相关定时器。应当注意，这里的定时器用于确定任务执行是否超时，当定时器超时并且还没有计算得出处理结果时，产生如图5B中S540所示的超时事件。步骤S680之后，在步骤S682中更新任务完成状态，此时针对任务结果返回事件的处理结束，进入等待其他事件的状态。

现在参见图7，该图示意性示出了根据本发明一个实施方式的对服务器端的处理能力进行扩展或分配的设备的框图700。如图7左侧虚线框中所示，用于扩展服务器端处理能力的设备包括：确定装置710，用于确定需要从服务器端卸下的作业；划分装置720，将作业划分为一个或多个任务；分配装置740，用于响应于客户端发出的http请求，向一个或多个客户端分配一个或多个任务；以及接收装置750，用于从一个或多个客户端发送的http请求中，接收一个或多个客户端对一个或多个任务的响应。

根据本发明的一个实施方式的设备，还可以包括选择装置730，用于选择服务器端的一个或多个客户端用于执行一个或者多个任务。

根据本发明的一个实施方式的设备，还可以包括规则库760用于保存各种规则，这些规则涉及确定是否需要从服务器端卸下作业、将作业划分成任务、向客户端分配任务、基于来自客户端的响应生成作业的至少一部分处理结果、以及将客户端划分为分组。应当注意，尽管图7中示出为规则库760位于服务器侧，在实践中该规则库760可以位于服务器侧以外的任何数据存储装置中，只要根据本发明的设备可以访问该规则库760并获取规则即可。

如图7中虚线右侧所示，示出了服务器端可以用以分担自身负载所使用的客户端分组及相应的客户端。例如，客户端分组1可以包括M个客户端，而客户端分组K可以包括N个客户端。

当图7所示的设备运行时，针对确定装置710所确定的需要卸下的作业，划分装置720将其划分为一个或者多个任务。此后分配装置740可以将划分装置720划分得出的任务分别分配给虚线右侧所示的相应客户端分组，由接收装置750接收各个客户端分组生成的响应，并且还可以生成针对作业的至少一部分处理结果。在操作过程中，各个装置还从可以规则库760中读取规则，以用于控制自身操作。

根据本发明的一个实施方式，其中确定装置710包括：判断装置，用于判断服务器端的当前负载水平；以及指定装置，用于响应于确定当前负载水平即将或者已经超过阈值负载水，指定从服务器端卸下的作业。

根据本发明的一个实施方式，其中分配装置740包括：分组装置，用于基于一个或多个客户端的属性，将一个或多个客户端进行分组；以及分派装置，用于以组为单位向一个或多个客户端分派与组相匹配的任务。

根据本发明的一个实施方式，其中客户端的属性包括以下中的一项或者多项：客户端的处理能力、客户端的当前负载、客户端的响应时间、客户端的受信程度、客户端到服务器端的路由状况、客户端的任务完成历史、客户端与服务器端之间的协议。

根据本发明的一个实施方式，其中分配装置740包括：发送装置，用于响应于一个或多个客户端登录到服务器端，向一个或多个客户端发送与一个或者多个任务相对应的任务描述以及待处理的数据。

根据本发明的一个实施方式，其中任务描述包括以下中的一项或者多项：输入数据描述、输出数据描述以及处理算法或其描述。

根据本发明的一个实施方式，其中划分装置720是基于预定规则操作的，预定规则涉及以下至少一项：作业的计算量、作业的优先级、作业的保密级别、任务的颗粒度。

根据本发明的一个实施方式，其中任务的颗粒度是基于客户端先前执行任务的经验而动态设置的。

根据本发明的一个实施方式，用于扩展服务器端处理能力的设备还包括：生成装置，用于基于一个或多个客户端对一个或多个任务的响应，生成作业的至少一部分处理结果。

根据本发明的一个实施方式，其中生成装置还包括：获取装置，用于获取来自一个或多个客户端的响应的可信度；以及提供装置，用于根据可信度提供作业的至少一部分处理结果。

应当注意，尽管在附图中并未逐一详细示出用于扩展服务器端处理能力的设备中的各装置，本领域人员可以基于说明书的公开而实现上述各装置。此外，图7中所示的各装置以及在图7中并未逐一绘出的各装置可以位于服务器侧的一个或者多个服务器中，或者还可以位于一个或者多个其他的专用设备中。根据本发明的实施方式，并不限制用于扩展服务器端处理能力的设备的物理位置，而是该设备包括的各个装置可以以集中式或者分布式方式位于任何适当的物理设备中，只要这些装置在整体上能够实现本说明书中所述功能即可。

在上文中，参考附图1至图7阐述了根据本发明实施方式的对服务器端的处理能力进行扩展或分配的方法和装置。然而应当注意，本说明书中以购物网站为示例而列举的例子，仅仅是示意性示例，并且在示例中所列出的网站记录日志的方式也仅仅是示意性目的，其目的仅在于通过示意性示例说明本发明的实施方式的工作原理。根据服务器端和客户端设置的不同，在不脱离本发明原理的情况下，可以采用任何其他方式实现。根据本发明的一个实施方式，在对服务器端的处理能力进行扩展或分配的方法中可以采用MapReduce架构。

本发明可以采取硬件实施方式、软件实施方式或既包含硬件组件又包含软件组件的实施方式的形式。在优选实施方式中，本发明实现为软件，其包括但不限于固件、驻留软件、微代码等。

而且，本发明还可以采取可从计算机可用或计算机可读介质访问的计算机程序产品的形式，这些介质提供程序代码以供计算机或任何指令执行***使用或与其结合使用。出于描述目的，计算机可用或计算机可读机制可以是任何有形的装置，其可以包含、存储、通信、传播或传输程序以由指令执行***、装置或设备使用或与其结合使用。

介质可以是电的、磁的、光的、电磁的、红外线的、或半导体的***(或装置或器件)或传播介质。计算机可读介质的例子包括半导体或固态存储器、磁带、可移动计算机磁盘、随机访问存储器(RAM)、只读存储器(ROM)、硬磁盘和光盘。目前光盘的例子包括紧凑盘-只读存储器(CD-ROM)、压缩盘-读/写(CD-R/W)和DVD。

适合与存储/或执行程序代码的数据处理***将包括至少一个处理器，其直接地或通过***总线间接地耦合到存储器元件。存储器元件可以包括在程序代码的实际执行期间所利用的本地存储器、大容量存储器、以及提供至少一部分程序代码的临时存储以便减少执行期间从大容量存储器必须取回代码的次数的高速缓冲存储器。

输入/输出或I/O设备(包括但不限于键盘、显示器、指点设备等等)可以直接地或通过中间I/O控制器耦合到***。

网络适配器也可以耦合到***，以使得数据处理***能够通过中间的私有或公共网络而耦合到其他数据处理***或远程打印机或存储设备。调制解调器、线缆调制解调器以及以太网卡仅仅是当前可用的网络适配器类型的几个例子。

从上述描述应当理解，在不脱离本发明真实精神的情况下，可以对本发明各实施方式进行修改和变更。本说明书中的描述仅仅是用于说明性的，而不应被认为是限制性的。本发明的范围仅受所附权利要求书的限制。

Claims (18)

1.一种用于扩展服务器端处理能力的方法，包括：

确定需要从所述服务器端卸下的作业，其中所述卸下的作业是原本应当由所述服务器端执行的作业；

将所述作业划分为一个或多个任务；

响应于所述服务器端的一个或多个客户端发出的http请求，向所述一个或多个客户端分配所述一个或多个任务；以及

从所述一个或多个客户端发送的http请求中，接收所述一个或多个客户端对所述一个或多个任务的响应，

所述方法还包括：

基于所述一个或多个客户端对所述一个或多个任务的响应，生成所述作业的至少一部分处理结果，包括：获取来自所述一个或多个客户端的响应的可信度；以及根据所述可信度提供所述作业的至少一部分处理结果。

2.根据权利要求1所述的方法，还包括：选择所述一个或多个客户端用于执行所述一个或者多个任务。

3.根据权利要求1所述的方法，其中所述确定需要从所述服务器端卸下的作业包括：

判断所述服务器端的当前负载水平；以及

响应于确定所述当前负载水平即将或者已经超过阈值负载水平，指定从所述服务器端卸下的作业。

4.根据权利要求1至3中任一项所述的方法，其中向所述一个或多个客户端分配所述一个或多个任务包括：

基于所述一个或多个客户端的属性，将所述一个或多个客户端进行分组；以及

以组为单位向所述一个或多个客户端分派与所述组相匹配的任务。

5.根据权利要求4所述的方法，其中所述客户端的属性包括以下中的一项或者多项：

所述客户端的处理能力、所述客户端的当前负载、所述客户端的响应时间、所述客户端的受信程度、所述客户端到所述服务器端的路由状况、所述客户端的任务完成历史、客户端与服务器端之间的协议。

6.根据权利要求1至3中任一项所述的方法，其中向所述一个或多个客户端分配所述一个或多个任务包括：

响应于所述一个或多个客户端登录到所述服务器端，向所述一个或多个客户端发送与所述一个或者多个任务相对应的任务描述以及待处理的数据。

7.根据权利要求6所述的方法，其中所述任务描述至少包括以下中的一项或者多项：输入数据描述、输出数据描述以及处理算法或其描述。

8.根据权利要求1至3中任一项所述的方法，其中将所述作业划分为一个或多个任务是基于预定规则进行的，所述预定规则涉及以下至少一项：所述作业的计算量、所述作业的优先级、所述作业的保密级别、任务的颗粒度。

9.根据权利要求8所述的方法，其中所述任务的颗粒度是基于客户端先前执行任务的经验而动态设置的。

10.一种用于扩展服务器端处理能力的设备，包括：

确定装置，用于确定需要从所述服务器端卸下的作业，其中所述卸下的作业是原本应当由所述服务器端执行的作业；

划分装置，用于将所述作业划分为一个或多个任务；

分配装置，用于响应于所述服务器端的一个或多个客户端发出的http请求，向所述一个或多个客户端分配所述一个或多个任务；以及

接收装置，用于从所述一个或多个客户端发送的http请求中，接收所述一个或多个客户端对所述一个或多个任务的响应，

所述设备还包括：生成装置，用于基于所述一个或多个客户端对所述一个或多个任务的响应，生成所述作业的至少一部分处理结果，所述生成装置包括：获取装置，用于获取来自所述一个或多个客户端的响应的可信度；以及提供装置，用于根据所述可信度提供所述作业的至少一部分处理结果。

11.根据权利要求10所述的设备，还包括：选择装置，用于选择所述一个或多个客户端用于执行所述一个或者多个任务。

12.根据权利要求10所述的设备，其中所述确定装置包括：

判断装置，用于判断所述服务器端的当前负载水平；以及

指定装置，用于响应于确定所述当前负载水平即将或者已经超过阈值负载水平，指定从所述服务器端卸下的作业。

13.根据权利要求10至12中任一项所述的设备，其中所述分配装置包括：

分组装置，用于基于所述一个或多个客户端的属性，将所述一个或多个客户端进行分组；以及

分派装置，用于以组为单位向所述一个或多个客户端分派与所述组相匹配的任务。

14.根据权利要求13所述的设备，其中所述客户端的属性包括以下中的一项或者多项：

所述客户端的处理能力、所述客户端的当前负载、所述客户端的响应时间、所述客户端的受信程度、所述客户端到所述服务器端的路由状况、所述客户端的任务完成历史、客户端与服务器端之间的协议。

15.根据权利要求10至12中任一项所述的设备，其中所述分配装置包括：

发送装置，用于响应于所述一个或多个客户端登录到所述服务器端，向所述一个或多个客户端发送与所述一个或者多个任务相对应的任务描述以及待处理的数据。

16.根据权利要求15所述的设备，其中所述任务描述包括以下中的一项或者多项：输入数据描述、输出数据描述以及处理算法或其描述。

17.根据权利要求10至12中任一项所述的设备，其中所述划分装置是基于预定规则操作的，所述预定规则涉及以下至少一项：所述作业的计算量、所述作业的优先级、所述作业的保密级别、任务的颗粒度。

18.根据权利要求17所述的设备，其中所述任务的颗粒度是基于客户端先前执行任务的经验而动态设置的。