CN104133724B - 并发任务调度方法及装置 - Google Patents

Abstract

本发明提供了一种并发任务调度方法，包括：接收上传的业务请求，将所述业务请求封装成任务对象；获取处理线程，将所述任务对象分配给所述处理线程，由所述处理线程选取业务服务器，并将所述任务对象发送至所述选取的业务服务器进行处理；通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。此外，还提供了一种并发任务调度装置及系统。上述并发任务调度方法、装置及系统能够降低系统维护的开销。

Description

并发任务调度方法及装置

技术领域

本发明涉及计算机技术领域，特别是涉及一种并发任务调度方法及装置。

背景技术

传统技术中的应用服务器在处理并发任务时，通常采用多进程的方式对多个业务请求进行并行处理，每个进程独立执行相应的处理任务，并将处理结果生成响应返回给相应的客户端。

然而，在高并发环境下，需要根据业务需求添加业务服务器，使用多进程的处理方式则在添加删除业务服务器时需要进行根据业务需求配置进程间通信的协议，使得维护的开销较大。

发明内容

基于此，有必要提供一种能够降低维护开销的并发任务调度方法。

一种并发任务调度方法，包括：

接收上传的业务请求，将所述业务请求封装成任务对象；

获取处理线程，将所述任务对象分配给所述处理线程，由所述处理线程选取业务服务器，并将所述任务对象发送至所述选取的业务服务器进行处理；

通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

此外，还有必要提供一种能够降低维护开销的并发任务调度装置。

一种并发任务调度装置，包括：

请求接收模块，用于接收上传的业务请求，将所述业务请求封装成任务对象；

任务分配模块，用于获取处理线程，将所述任务对象分配给所述处理线程，由所述处理线程选取业务服务器，并将所述任务对象发送至所述选取的业务服务器进行处理；

响应生成模块，用于通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

此外，还有必要提供一种能够降低维护开销的并发任务调度方法。

一种并发任务调度方法，包括：

入口节点接收客户端上传的业务请求，将所述业务请求封装成任务对象；获取处理线程，将所述任务对象分配给所述处理线程，由所述处理线程选取业务节点，并将所述任务对象发送至所述选取的业务节点；

所述业务节点通过对与其对应的数据节点进行读写操作生成与所述任务对象对应的处理结果，并返回给所述入口节点；

所述入口节点通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

此外，还有必要提供一种能够降低维护开销的并发任务调度系统。

一种并发任务调度系统，包括客户端、入口节点、业务节点和数据节点，其中：

所述入口节点用于接收客户端上传的业务请求，将所述业务请求封装成任务对象；获取处理线程，将所述任务对象分配给所述处理线程，由所述处理线程选取业务节点，并将所述任务对象发送至所述选取的业务节点；

所述业务节点用于通过对与其对应的数据节点进行读写操作生成与所述任务对象对应的处理结果，并返回给所述入口节点；

所述入口节点还用于通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

上述并发任务调度方法、装置及系统中，以线程为单位并发地处理业务请求，使得在进行线程调度时，同一进程下的多线程本身共享同一内存，可在进程内通信，即可直接使用操作系统提供的线程调度方法对处理业务请求的多线程进行调度。与传统技术相比，开发人员在添加或移除业务时，不需要编写或修改大量的用于维护的进程通信代码，从而降低了维护的开销。

附图说明

图1为传统技术中基于多进程的任务调度系统的结构示意图；

图2为传统技术中使用多进程的进行任务调度的原理示意图；

图3为一个实施例中并发任务调度方法的流程图；

图4为一个实施例中使用多进程的进行任务调度的原理示意图；

图5为一个实施例中并发任务调度系统的结构示意图；

图6为一个实施例中并发任务调度装置的结构示意图；

图7为另一个实施例中并发任务调度方法的流程图；

图8为一个实施例中运行web应用中执行业务逻辑的方法的服务器运行环境示意图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

除非上下文另有特定清楚的描述，本发明中的元件和组件，数量既可以单个的形式存在，也可以多个的形式存在，本发明并不对此进行限定。本发明中的步骤虽然用标号进行了排列，但并不用于限定步骤的先后次序，除非明确说明了步骤的次序或者某步骤的执行需要其他步骤作为基础，否则步骤的相对次序是可以调整的。可以理解，本文中所使用的术语“和/或”涉及且涵盖相关联的所列项目中的一者或一者以上的任何和所有可能的组合。

在传统技术中，如图1所示，PN节点（Proxy Node）为提供业务服务入口的入口服务器，例如，web应用中的web服务器，移动互联网应用的应用服务器；C1和C2为客户端，客户端可以有多个。BN节点（Business Node）即业务节点，PN节点与多个BN节点连接（即图中的BN1、BN2、BN3和BN4），每个BN节点可根据预设的业务逻辑算法处理业务请求。客户端通过向PN节点发起业务请求来获得服务，BN节点通过处理PN节点转发或重定向的业务请求执行业务，PN节点通过向客户端返回由BN节点回复的响应来提供服务。

然而，如图2所示，在传统技术中，PN节点在转发业务请求时，采用的是多进程的方法，即接收到业务请求后，为其分配一个进程以及一个端口号，然后该进程通过该端口号与某个业务服务器建立socket连接，将业务请求通过该socket连接转发给业务服务器。通常情况下，进程还包括类别信息，每一类的多个进程对应处理该种业务的业务服务器（如图2中的A类业务对应多个业务服务器进行处理，PN节点有多个进程与A类业务服务器进行通信），在多进程的机制下，则根据业务请求的业务类型对多个进程进行调度（例如A类进程等待B类进程接收到的响应数据，需要进入阻塞状态）。对多个进程进行调度则需要在多进程之间进行通信。

而传统技术中，进程间通信的机制（IPC，Inter-Process Communication）通常需要开发人员根据业务需求设计，若业务类型较多，或者在添加或移除某种业务类型时，则相应的需要添加或修改相应的IPC代码。对于较大的应用来说，需要花费在维护上的开销较大。

而在本实施例中，未解决上述系统维护开销较大的问题，提出了一种并发任务调度方法，该方法可依赖于计算机程序，能够运行于基于冯洛伊曼体系的计算机系统上。该计算机系统可以是web服务器、移动互联网应用服务器、游戏入口服务器等。

在本实施例中，如图3所示，该方法包括：

步骤S102，接收上传的业务请求，将业务请求封装成任务对象。

业务请求即为前述的客户端向PN节点发起的期望获得数据服务的业务请求。

例如，在一个基于web的视频点播系统中，用户发起的业务请求即为通过浏览器发起的基于http协议的web访问请求，该web访问请求中包含了该用户的用户标识、点播视频的视频标识以及视频地址等参数信息。

再例如，在一个手机游戏系统中，用户发起的业务请求即为通过手机游戏客户端发起的基于该手机游戏的应用协议的游戏业务相关的业务请求，例如，用户在游戏中选择进入某个场景进行游戏时，即会通过手机游戏客户端向PN节点发起场景切换请求。

在本实施例中，可将业务请求中的参数信息提取出来，然后将该参数信息封装在任务对象（在某些程序语言中也可以是集合、数组或结构体）中。进一步的，可将封装的任务对象按照接收到业务请求的先后顺序缓存在预设的任务队列中。

例如，在基于web应用服务器的应用场景中，可存在请求队列和任务队列，请求队列可基于web容器（即web应用框架）本身，队列中存储httprequest对象。即可根据按照先进先出的顺序由请求队列中提取httprequest对象，并提取httprequest对象中的某些属性值，然后按顺序根据提取的属性值封装任务对象，任务对象封装完毕后，即可将其添加到任务队列的队尾（队列只可在尾部插入，首部取出）。

也就是说，底层的web容器在接收到业务请求后先将其封装成请求对象，并以接收到业务请求的先后顺序将其缓存在web应用框架的请求队列中。运行该方法的计算机程序可直接提取请求队列中的请求对象并将其封装成任务对象。

以队列的形式缓存任务对象，可保证先抵达的业务请求可以优先得到处理（但不能保证优先得到响应，因为对多个任务对象异步并发处理时，不能保证先处理的任务对象先处理完）。且可设置任务队列的长度上限，若任务队列中任务对象的数量达到该长度上限时，可对接收到的业务请求直接返回服务器忙的响应，也可根据请求队列中请求对象的数量提示排队信息，即当前正在等待处理的业务请求的数量。

步骤S104，获取处理线程，将任务对象分配给处理线程，由处理线程选取业务服务器，并将任务对象发送至选取的业务服务器进行处理。

在本实施例中，如图4所示，可设置多个处理线程，在处理线程启动之后即自动以先进先出的方式（即在任务队列的队首提取）从任务队列中提取任务对象。在其他实施例中，也可预设线程池，每封装一个任务对象则由线程池中获取一个处理线程，将该任务对象分配给处理线程处理。

业务服务器通常有多个，且如图5所示，运行该方法的入口节点10，与多个业务节点30连接，每个业务节点也与和业务类型相关的数据节点40连接，且可包含多个业务服务器。入口节点中可存储业务节点状态表，并通过定期与业务节点互发探测包活的业务节点的运行状态信息（例如带宽、CPU占用率和内存占用率等信息），并根据该运行状态信息维护该业务节点状态表。处理线程在选取业务服务器时，则可根据该业务节点状态表选择负载较低的业务节点，然后将任务对象发送给该业务节点。每个处理对象可与业务节点建立socket连接，具有独立的端口。

如图4所示，业务节点与数据服务器连接，数据服务器也可以有多个。例如，在一个应用场景中，某个大型应用系统需要用到多个数据库，且每个数据库的数据量较大，则可在每个数据服务器的上独立运行这些数据库。业务节点在对任务对象进行处理时，可使用数据服务器提供的数据接口对处理任务对象需要的和生成的数据进行读写操作。处理完毕后，则可通过前述的socket连接将处理结果发送至入口节点。入口节点根据端口即可将接收到处理结果的转到相应的处理线程中。

需要说明的是，图5中的入口节点可以是独立的web服务器、移动互联网应用服务器或游戏入口服务器，也可以包含在现有的web服务器、移动互联网应用服务器或游戏入口服务器等入口服务器的基础上添加的任务分发服务器，且入口服务器可对应多个任务分发服务器。若单个任务分发服务器由于内存大小的限制而使得任务队列长度较小时，则可设置多个任务分发服务器，从而增大任务队列的长度上限，并在任务分发服务器的后端增加相应的业务服务器，从而减少排队的情况。

步骤S106，通过处理线程接收业务服务器返回的处理结果，根据处理结果生成响应并返回。

例如，在一个应用场景中，若用户希望查看其在网站上填写的个人资料，则可通过点击查看按钮发起httprequest请求。入口节点接收到该业务请求后将其封装成任务对象，将业务请求中包含的查询参数添加到任务对象的属性中。处理线程可读取该属性，然后通过socket连接以预设的协议格式发送给业务服务器。业务服务器可根据参数中的该用户的用户标识在用户资料数据库中查找相应的昵称、年龄、学历、生日等个人信息，然后通过socket连接返给入口节点，入口节点则可生成包含上述昵称、年龄、学历、生日等个人信息的httpresponse对象，然后将其返回给用户。用户即可在浏览器上查看到其个人信息页面。

需要说明的是，在本实施例中，入口节点的处理线程将任务对象发送给业务服务器的过程中，并不需要将任务对象本身发送给业务服务器，而可仅提取任务对象中的部分属性值，然后基于自定义的通信协议将其发送给业务服务器。通信协议中可包括任务标识及业务服务器根据任务标识进行相应业务处理的协议内容。也就是说，处理线程按照预先定义的通信协议向业务服务器发送相应的任务标识后，业务服务器即可根据通信协议执行与任务标识对应的具体的业务操作。

例如，在一个应用场景中，采用文本格式的通信协议(字符串)，请求协议包采用cgi的参数格式，每个字段用“&”分割，以“\n”作为结束符，字段的前后顺序不固定，字段名和值用“=”分割。

例如，处理线程发送给业务服务器的消息可以是如下格式：

cmd=001001&uin=88883960&area=0\n

其中，cmd为任务标识属性，001001即为响应的任务标识。uin为用户标识属性，即88883960；area为=区域标识，即0。任务标识可根据任务对象对应的业务请求的链接地址得到。例如，开发人员在开发时，每添加一个业务则相应需要为该业务提供一个作为入口的链接地址，则可在预设的链接地址与任务标识映射表中添加相应的映射，入口节点即可根据业务请求中的链接地址查询该映射表得到相应的任务标识。

由于&号作为各个字段的分隔符，不能作为内容使用，字符串内容中不允许有多余的“&”和“\n”符号出现。业务服务器将处理结果返回给入口节点时也可遵照上述通信协议，例如：

“cmd=001001&result=0&info=…\n”

需要说明的是：

3.如参数值中可能含有特殊字符(协议的分割符，比如“&=%”等)，则用%XX（XX为该字符的16进制值）表示字符串，和浏览器下调用cgi输入的参数类似。例如：sQQPasswd=&%改为用sQQPasswd=%26%25表示。

字符转换规则如下：

1.可将协议中的字符转换成%+字符的ASCII码的16进制数，且字母必须大写，例如：“\n”的正确转换值为%0D,其他的都是错误的，比如：%13,%0d。对于中文字符占大多数的系统可统一采用base64编码，对所有字符转换成16进制的两个字母的形式。以便节省编码后的空间。

2.仅将与协议有关的字符进行转换，包括：'&','=','|',空格、'\n','\r'，':'以及所有不可见字符

3.除2规定的字符外，所有字符均不需要转换。

4.通信协议中的协议关键字。

5.协议制定的时候参数是列表的形式可使用参数名称为“…list”，取值的协议格式为‘|’作为一级分隔符（一般也用于不用用户之间数据的分割），空格或者逗号作为二级分隔符的列表（如果一个字段不存在两级分割的问题建议尽量用空格做分割，这样将来批量查询的时候要一个字段传递多个用户的信息可以用|做分割），～_等可以作为三级分隔符（设计时尽量少用到三层分割以上的情况）。比如：uin1time1|uin2time2|…|。

在一个实施例中，将任务对象分配给处理线程的步骤还包括：

将任务对象拆分成子任务对象，并为子任务对象分配对应的处理线程。

例如，在一个应用场景中，用户请求访问的页面为游戏平台中用户在多个游戏中的得分记录情况，且页面中的展示栏列表中需要展示用户在5个不同的游戏中的得分纪录。则该业务请求对应的任务对象可被拆分成5个子任务对象，且每个子任务对象中均包含有该用户的用户标识。然后分配给5个处理线程，该5个处理线程可分别将子任务对象中的用户标识发送给相应的业务服务器，业务服务器则可访问5种游戏各自对应的数据服务器，在5种游戏对应的数据库中并行地查询得分纪录，然后各自返回给入口节点。入口节点则可将返回的该用户在5种游戏中各自的得分纪录整合后生成响应，然后返回给用户，用户则可在浏览器中看到。任务对象经过拆分后，使得任务对象中不相关联的多个处理过程能够并发的进行处理，如上例中，在5个数据服务器中同时执行查询任务和按顺序在5个数据服务器上依次执行查询任务相比，生成响应的速度能够快很多，且使得任务队列中的任务对象能够快速地被消化，不会造成任务拥塞。

在本实施例中，可根据任务对象的对应的业务请求的链接地址对任务对象进行拆分。如前例中，若用户查看在多个游戏中的得分记录情况时点击的链接为：http：//a.b.c/info?uid=x&gid=all，其中http：//a.b.c为入口节点的host地址，/info为资源路径，uid为用户标识，即x，gid为游戏类型标识，即all（表示所有的5种游戏），则可预先定义与/info对应的拆分逻辑：若gid为g1，则可生成查询任务标识为g1的子任务对象，例如：

cmd=0000301&gid=g1&uid=x…

并将该子任务对象发送至处理业务服务器，由业务服务器根据该参数在g1类型游戏数据库中查找相关数据；若gid为g1g2，则将该任务对象拆分成两个子任务对象，且子任务对象的查询任务标识分别为g1和g2，例如：

cmd=0000301&gid=g1&uid=x…

cmd=0000301&gid=g2&uid=x…

分别发送至业务服务器后，由业务服务器分别根据查询任务标识访问g1和g2类型游戏数据库中查找相关数据；若gid为all，则将该任务对象拆分成5个子任务对象，且子任务对象的查询任务标识分别为g1、g2、g3、g4和g5，例如：

cmd=0000301&gid=g1&uid=x…

cmd=0000301&gid=g2&uid=x…

cmd=0000301&gid=g3&uid=x…

cmd=0000301&gid=g4&uid=x…

cmd=0000301&gid=g5&uid=x…

分别发送至业务服务器后，由业务服务器分别根据查询任务标识访问g1、g2、g3、g4和g5类型游戏数据库中查找相关数据。

上述拆分逻辑预先定义完成后，则在处理上述http：//a.b.c/info?uid=x&gid=all对应的任务对象时，即可将该任务对象拆分成查询任务标识分别为g1、g2、g3、g4和g5的子任务对象。

也就是说，可预先对链接地址定义相应的拆分逻辑，然后在处理该链接地址对应的任务对象时，即可调用相应的拆分逻辑进行拆分。

进一步的，拆分后的多个子任务对象可分配给同一个处理线程。例如，若某个任务对象被拆分成A、B、C、D4个子任务对象，其中A、B和C是可以并发执行的子任务，而D的执行需要等待A的处理结果。则可将子任务对象A和D先以队列的形式存储，然后将该队列分配给一个处理线程，该处理线程按顺序同步执行队列中的子任务：先由队列中提取出子任务对象A，得到处理结果后，再根据该处理结果后执行子任务B。而与此同时，子任务B和C分别分配给了另外两个处理线程，可并行地得到处理。

也就是说，在定义拆分逻辑时，也可定义子任务同步或异步的执行方式，以及在同步执行时，子任务的执行顺序，从而方便讲复杂的任务对象分解为多个并行处理的子任务对象。

在一个实施例中，为子任务对象分配对应的处理线程的步骤还包括：获取子任务对象的业务类型，为子任务对象分配与其业务类型对应的处理线程。

在大型系统中，通常包含多种业务，每种业务则与独立的数据服务器对应。如前例中，g1至g5的游戏的数据服务器为各自独立的游戏数据库，则可预先为g1和g5分别设置一定数量的处理线程，则在分配业务类型为g1（在生成子任务对象时，可根据链接地址或链接地址中的参数信息得到该子任务对象的业务类型）的子任务对象时，即可将其分配给与g1类型对应的处理线程；在分配业务类型为g2的子任务对象时，即可将其分配给与g2类型对应的处理线程。

由于处理线程通信较进程通信较简单，因此同一类型的处理线程在处理具有相同的业务类型的子任务对象时，可方便地共享数据，例如统计数据和日志数据等，从而方便根据具体的业务对处理线程进行管理。

在另一个实施例中，由处理线程选取业务服务器的步骤包括：由处理线程获取分配的子任务对象的业务类型，选取与业务类型对应的业务服务器。

也就是说，同样可预先根据业务类型的不同将业务服务器分类，如前例中，g1至g5的游戏的数据服务器分别对应的业务服务器。但子任务对象可分配给任意处理线程，由处理线程根据业务类型来选取响应的业务服务器进行处理。在该实施例中，选取业务服务器的逻辑在处理线程中，从而降低了系统中各模块的耦合度，提高了扩展性。

在一个实施例中，如图6所示，一种并发任务调度装置，包括请求接收模块102、任务分配模块104和响应生成模块106，其中：

一种并发任务调度装置，包括：

请求接收模块102，用于接收上传的业务请求，将业务请求封装成任务对象。

任务分配模块104，用于获取处理线程，将任务对象分配给所述处理线程，由处理线程选取业务服务器，并将任务对象发送至选取的业务服务器进行处理。

响应生成模块106，用于通过处理线程接收业务服务器返回的处理结果，根据处理结果生成响应并返回。

在本实施例中，请求接收模块102还用于将封装的任务对象按照接收到业务请求的先后顺序缓存在预设的任务队列中。任务分配模块104还用于以先进先出的方式由任务队列中提取任务对象。

在本实施例中，任务分配模块104还用于将任务对象拆分成子任务对象，并为子任务对象分配对应的处理线程。

在一个实施例中，任务分配模块104还用于获取子任务对象的业务类型，为子任务对象分配与其业务类型对应的处理线程。

在一个实施例中，任务分配模块104还用于由处理线程获取分配的子任务对象的业务类型，选取与业务类型对应的业务服务器。

在一个实施例中，如图7所示，一种并发任务调度方法，包括：

步骤S202，入口节点接收客户端上传的业务请求，将业务请求封装成任务对象；获取处理线程，将任务对象分配给所述处理线程，由处理线程选取业务节点，并将任务对象发送至选取的业务节点。

步骤S204，业务节点通过对与其对应的数据节点进行读写操作生成与任务对象对应的处理结果，并返回给入口节点。

步骤S206，入口节点通过处理线程接收业务服务器返回的处理结果，根据处理结果生成响应并返回。

在一个实施例中，如图5所示，一种并发任务调度系统，包括入口节点10、客户端20、业务节点30和数据节点40，其中：

入口节点10用于接收客户端20上传的业务请求，将业务请求封装成任务对象；获取处理线程，将任务对象分配给所述处理线程，由处理线程选取业务节点，并将任务对象发送至选取的业务节点。

业务节点30用于通过对与其对应的数据节点40进行读写操作生成与任务对象对应的处理结果，并返回给入口节点。

入口节点10还用于通过处理线程接收业务服务器返回的处理结果，根据处理结果生成响应并返回。

上述并发任务调度方法、装置及系统中，以线程为单位并发地处理业务请求，使得在进行线程调度时，同一进程下的多线程本身共享同一内存，可在进程内通信，即可直接使用操作系统提供的线程调度方法对处理业务请求的多线程进行调度。与传统技术相比，开发人员在添加或移除业务时，不需要编写或修改大量的用于维护的进程通信代码，从而降低了维护的开销。

在一个实施例中，如图8所示，提供了一种可运行前述并发任务调度方法的服务器结构示意图，该服务器结构可应用于图5中的入口节点10之上。该服务器500可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器（central processing units，CPU）522（例如，一个或一个以上处理器）和存储器532，一个或一个以上存储应用程序542或数据544的存储介质530（例如一个或一个以上海量存储设备）。其中，存储器532和存储介质530可以是短暂存储或持久存储。存储在存储介质530的程序可以包括一个或一个以上模块（如前述的请求接收模块102、任务分配模块104和响应生成模块106），每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器522可以设置为与存储介质530通信，在服务器500上执行存储介质530中的一系列指令操作。服务器500还可以包括一个或一个以上电源526，一个或一个以上有线或无线网络接口550，一个或一个以上输入输出接口558，和/或，一个或一个以上操作系统541，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述图3所示实施例中所述的由服务器所执行的步骤可以基于该图8所示的服务器结构。本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体（Read-OnlyMemory，ROM）或随机存储记忆体（Random Access Memory，RAM）等。

以上实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种并发任务调度方法，包括：

接收上传的业务请求，将所述业务请求封装成任务对象；

将所述封装的任务对象按照接收到业务请求的先后顺序缓存在预设的任务队列中；

获取处理线程，以先进先出的方式由所述任务队列中提取任务对象，将所述任务对象分配给所述处理线程，由所述处理线程选取业务服务器，并将所述任务对象发送至所述选取的业务服务器进行处理；

通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

2.根据权利要求1所述的并发任务调度方法，其特征在于，所述将所述任务对象分配给所述处理线程的步骤还包括：

将所述任务对象拆分成子任务对象，并为所述子任务对象分配对应的处理线程。

3.根据权利要求2所述的并发任务调度方法，其特征在于，所述为所述子任务对象分配对应的处理线程的步骤包括：

获取所述子任务对象的业务类型，为所述子任务对象分配与其业务类型对应的处理线程。

4.根据权利要求2所述的并发任务调度方法，其特征在于，所述由处理线程选取业务服务器的步骤包括：

由处理线程获取分配的子任务对象的业务类型，选取与所述业务类型对应的业务服务器。

5.一种并发任务调度装置，其特征在于，包括：

请求接收模块，用于接收上传的业务请求，将所述业务请求封装成任务对象；

所述请求接收模块还用于将所述封装的任务对象按照接收到业务请求的先后顺序缓存在预设的任务队列中；

任务分配模块，用于获取处理线程，以先进先出的方式由所述任务队列中提取任务对象，将所述任务对象分配给所述处理线程，由所述处理线程选取业务服务器，并将所述任务对象发送至所述选取的业务服务器进行处理；

响应生成模块，用于通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

6.根据权利要求5所述的并发任务调度装置，其特征在于，所述任务分配模块还用于将所述任务对象拆分成子任务对象，并为所述子任务对象分配对应的处理线程。

7.根据权利要求6所述的并发任务调度装置，其特征在于，所述任务分配模块还用于获取所述子任务对象的业务类型，为所述子任务对象分配与其业务类型对应的处理线程。

8.根据权利要求6所述的并发任务调度装置，其特征在于，所述任务分配模块还用于由处理线程获取分配的子任务对象的业务类型，选取与所述业务类型对应的业务服务器。

9.一种并发任务调度方法，包括：

入口节点接收客户端上传的业务请求，将所述业务请求封装成任务对象；将所述封装的任务对象按照接收到业务请求的先后顺序缓存在预设的任务队列中；获取处理线程，以先进先出的方式由所述任务队列中提取任务对象，将所述任务对象分配给所述处理线程，由所述处理线程选取业务节点，并将所述任务对象发送至所述选取的业务节点；

所述业务节点通过对与其对应的数据节点进行读写操作生成与所述任务对象对应的处理结果，并返回给所述入口节点；

所述入口节点通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。

10.一种并发任务调度系统，其特征在于，包括客户端、入口节点、业务节点和数据节点，其中：

所述入口节点用于接收客户端上传的业务请求，将所述业务请求封装成任务对象；将所述封装的任务对象按照接收到业务请求的先后顺序缓存在预设的任务队列中；获取处理线程，以先进先出的方式由所述任务队列中提取任务对象，将所述任务对象分配给所述处理线程，由所述处理线程选取业务节点，并将所述任务对象发送至所述选取的业务节点；

所述业务节点用于通过对与其对应的数据节点进行读写操作生成与所述任务对象对应的处理结果，并返回给所述入口节点；

所述入口节点还用于通过所述处理线程接收业务服务器返回的处理结果，根据所述处理结果生成响应并返回。