CN107688500A - 一种分布式任务处理方法、装置、***及设备 - Google Patents

Abstract

说明书实施例公开了一种分布式的任务处理方法、装置、设备及***，分布式的任务处理架构中无需部署中央管理服务器，而是通过相应的任务分发设备，向分布式的各任务处理设备分发任务消息，使得接收到任务消息的任务处理设备“抢”任务锁。只有获取到任务锁的任务处理设备才可以对任务消息进行处理。其处理的方式通过将大任务划分为一定数量的子任务，并针对子任务并行处理。

Description

一种分布式任务处理方法、装置、***及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种分布式任务处理方法、装置、***及设备。

背景技术

随着互联网技术的不断发展，传统单机处理的方式已无法满足巨量的任务处理需求，因此分布式的业务***营运而生。

现有技术中，对于分布式的业务***而言，通常会采用集中分配式的处理模式，也即，通过一台主控设备(如：服务器)为分布式的处理服务器分配相应的待处理任务，以进行任务处理。

基于现有技术，我们需要一种更加有效的分布式的任务处理方式。

发明内容

本说明书实施例提供一种分布式任务处理方法、装置、***及设备，用以提供一种更加有效的分布式的任务处理方式。

本说明书实施例提供的一种分布式的任务处理方法，任务分发设备向分布式的任务处理设备分发任务消息，所述方法包括：

所述任务处理设备接收所述任务分发设备分发的任务消息；

获取匹配于所述任务消息的任务锁；

当获取到所述任务锁时，对所述任务消息进行处理。

本说明书实施例还提供的一种分布式的任务处理方法，包括：

任务分发设备接收消息发送规则；

根据所述消息发送规则，生成任务消息分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

本说明书实施例还提供的一种分布式的任务处理装置，任务分发设备向分布式的任务处理设备分发任务消息，所述装置包括：

接收模块，接收所述任务分发设备分发的任务消息；

任务锁获取模块，获取对应于所述任务消息的任务锁；

处理模块，当获取到所述任务锁时，对所述任务消息进行处理。

本说明书实施例还提供的一种分布式的任务处理装置，包括：

接收模块，接收消息发送规则；

消息分发模块，根据所述消息发送规则，生成任务消息分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

本说明书实施例还提供的一种分布式的任务处理***，至少包括：分布式的任务处理服务器、任务分发设备以及任务数据库，其中，

所述分布式的任务处理服务器，接收任务分发设备分发的任务消息，获取对应于所述任务消息的任务锁，当获取到所述任务锁时，对所述任务消息进行处理；

所述任务分发设备，按照设定的消息发送规则，将任务消息分发给各分布式的任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理；

所述任务数据库，存储任务数据、任务锁表以及由所述任务处理服务器写入的待处理任务。

本说明书实施例还提供的一种分布式的任务处理设备，包括：

存储器，存储任务处理程序；

通讯接口，接收任务消息；

处理器，在通讯接口接收到任务消息后，调用存储器中存储的任务处理程序，并执行：

获取匹配于所述任务消息的任务锁；

当获取到所述任务锁时，对所述任务消息进行处理。

本说明书实施例还提供的一种分布式的任务处理设备，包括：

存储器，存储任务处理程序；

通讯接口；

处理器，调用存储器中存储的任务处理程序，并执行：

根据所述消息发送规则，生成任务消息通过所述通讯接口分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：

在本说明书实施例中，分布式的任务处理架构中无需依赖中央管理服务器，即，并不需要进行任务管理、分配，而是通过相应的任务分发设备，向分布式的各任务处理设备分发任务消息，使得接收到任务消息的任务处理设备“抢”任务锁。只有获取到任务锁的任务处理设备才可以对任务消息进行处理，从而实现了对任务消息的同步互斥处理。特别是在大量任务的情况下，任务分发设备并不需要服务的任务分配逻辑，而仅是将任务消息分发给各任务处理设备，由任务处理设备通过“抢”锁的方式处理任务消息。这样的分布式任务处理方法简单且高效。

而且，通过将一个大任务分解为若干子任务的方式，使得各个子任务可以分布式的并行处理，互不依赖。同时，将将任务处理分解为若干个有序阶段，每个阶段的执行相互独立。这样的处理方式更加有效、快捷。

此外，从上述的处理架构可见，架构中并不需要部署中心服务器，在分布式架构中，每个任务处理设备都是独立的处理单元，扩展较为简单。

附图说明

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

图1为本说明书实施例提供的分布式任务处理方法所基于的架构示意图；

图2a～2b为本说明书实施例提供的任务状态示意图；

图3为本说明书实施例提供的基于任务分发设备侧的分布式任务处理过程；

图4为本说明书实施例提供的基于任务处理设备侧的分布式任务处理过程；

图5为本说明书实施例提供的获取任务锁的过程示意图；

图6为本说明书实施例提供的解除任务锁的过程示意图；

图7为本说明书实施例提供的在一种实际应用场景中的分布式任务处理架构图；

图8为本说明书实施例提供的任务处理器内部的示意图；

图9为本说明书实施例提供的基于任务处理设备侧的分布式任务处理装置结构示意图；

图10为本说明书实施例提供的基于任务分发设备侧的分布式任务处理装置结构示意图。

具体实施方式

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

在本说明书的一个或多个实施例中，所述的分布式任务处理方法可以采用如图1所示的架构。图1中的架构至少可包括：分布式的任务处理***、任务分发设备以及任务数据库。

在图1中，分布式的任务处理***，用于处理各类任务。在实际的应用场景中，该任务处理***通常包含分布式的多个处理设备，如：服务器、计算机等设备，这里不作具体限定。当然，在某些应用场景中，该任务处理***中也可包含区块链网络，区块链网络中的每一区块链节点可看作是一个处理设备。这里需要说明的是，任务处理***中的每一处理设备将同时接收到来自于调度***所发送的任务消息，优先接收到任务消息的处理设备将获得相应的任务处理权限。换言之，任务处理***中的各处理设备关系平等，并不存在主、从处理设备之分。

所述的任务分发设备，可以是一台具有调度功能的服务器、计算机等设备，也可以是相应的设备集群，用于实现任务的调度。应理解，本说明书实施例中的调度***并不需要过于复杂的调度逻辑，而是将与任务相关的消息发送给上述分布式的任务处理***中的各任务处理设备，使得接收到消息的任务处理设备进行相应的处理。换言之，本说明书实施例中的任务分发设备，将上述消息发送给任务处理***中的各任务处理设备，而并非有指向性地发送给某一/某些任务处理设备。发送上述消息的方式可以采用诸如广播、分发等。

所述的任务数据库，用于存储任务记录以及与任务相关的各类任务数据。任务处理设备在接收到上述消息后，可根据任务数据库中存储的各类任务数据生成相应的待处理任务，或者，根据已有的任务记录对需要处理的任务进行处理等等。

结合上述内容可知，本说明书实施例中所述的分布式任务处理方法并不依赖主控服务器进行集中式的分布管理，且避免了复杂的协调机制。

当然，图1所示的架构仅是一种简单的示例性架构，在实际的业务场景中，架构的复杂度可能会增加，具体将根据实际应用的需要进行设置和部署。此外，图1中所示的架构通常可以是同一业务提供方(如：企业、网站、银行、电信运行商等)后台的架构。但可以理解地，上述架构也同样适用于不同业务提供方的情况，例如：上述分布式的任务处理***可以作为独立的第三方，接入其他需求方(如：企业用户)的后台***，为其他需求方提供任务处理服务。这里并不应作为对本申请的限定。

这里需要说明的是，在本说明书的一个或多个实施例中，所述的任务(Task)并不需要用户主动触发，而是相应的业务提供方后台需要在特定时间或特定时间间隔进行处理的大规模批量任务(即，定时任务)，例如：文件批处理任务或者是数据批处理任务。当然，应理解，本说明书实施例中所述的分布式任务处理方法，并不仅适用于上述的定时任务，同样也适用于实际业务场景中通过用户的业务请求所触发的各类任务。

此外，所述的任务通常可拆分为若干个子任务，例如：所述的任务可以是文件批处理任务，一个任务需要处理大量的文件，那么，可将这个任务拆分为若干个子任务，每一个子任务用于处理一定数据量的文件。

为了便于区别，在本说明书的一个或多个实施例中，将能够拆分的任务称为：可拆分任务；将拆分后得到的任务称为：子任务；将可拆分任务和子任务统称为：任务。

基于此，在本说明书实施例中，如图2a所示，对于任一个可拆分任务而言，通常具有7种状态：等待状态(Pending，P)、已分片状态(Splitup，S)、等待合并状态(Merging，M)、已合并状态(Merged，G)、已完成状态(Finished，F)、已终止状态(Abend，A)以及已延后(Delay，D)。此外，图2a中也示出了各状态之间的转换关系。

可见，对任一可拆分任务的处理过程，可认为是将该可拆分任务进行分片成若干子任务，并针对子任务进行处理，再将各子任务的处理结果进行合并，完成对可拆分任务的处理。

如图2b所示，对于每一子任务而言，通常具有4种状态：P、执行中状态(R)、F以及A。同样地，可从图2b获知子任务的4种状态之间的转换关系，这里便不再过多赘述。

上述所提及的状态将以任务状态信息的形式存储在任务数据库中，以便任务处理设备根据任务状态信息对任务进行相应的处理(该过程在下文中将详细描述，这里不过多赘述)。

基于上述图1中所示的架构以及图2a和2b所示的任务状态，下面将详细说明本说明书实施例中的分布式任务处理方法。

对于任务分发设备而言，本说明书实施例提供一种分布式任务处理方法，如图3所示，具体包括以下步骤：

步骤S301：接收消息发送规则。

在本说明书实施例中，所述的消息发送规则，对于任务分发设备而言，可认为是一段功能代码，可由相应的业务人员输入至任务分发设备中。当然，这只是设置消息发送规则的一种方式，并不作为对本申请的限定。作为一种可行的实施方式，所述的消息发送规则可包括：以某种设定的时间周期生成并发送诸如任务调度消息、根据任务的状态发送任务处理消息等。

步骤S303：根据所述消息发送规则，生成任务消息分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

如前所述，在本说明书实施例中，任务消息可包括：任务调度消息及任务处理消息。

具体而言，所述的任务调度消息可认为是任务分发设备向任务处理设备发出的与任务相关的预处理操作的指令消息。在本说明书实施例中，任务调度消息进一步可包括：任务创建消息和任务扫描消息。

其中，所述的任务创建消息用于指示任务处理设备创建可拆分任务。所述的任务扫描消息用于指示任务处理设备扫描任务数据库中相应的任务表，以查找任务表中需要进行处理的任务。当然，任务分发设备生成并发送上述的任务创建消息和任务扫描消息的周期可以相同，也可以不同，具体将根据实际应用的需要进行设置和定义，这里并不应作为对本申请的限定。

而所述的任务处理消息，用于指示处理设备对需要进行处理的任务进行相应的处理操作。

在本说明书的某些实施例中，对于上述如图1所示的任务分发设备而言，其可以进一步分为定时任务分发设备和消息设备。

其中，所述的定时任务分发设备用于向任务处理***发送上述的任务调度消息，而所述的消息设备用于发送上述的任务处理消息。

这里所述的消息设备，同样可以是一台具有消息传输功能的服务器、计算机等设备，或是相应的设备集群。在一些实施例中，所述的消息设备隶属于消息***，如：Kafka。消息***可以是相应的业务提供方后台的分布式订阅消息发布***，在应用本说明书实施例中的任务处理方法时，借用了该消息***中的消息功能。

基于此，对于图3所示的方法，还包括：所述消息设备接收任务处理设备反馈的任务处理消息，将接收到的所述任务处理消息分发给各任务处理设备。

换言之，所述的任务处理消息由处理设备所生成。在一种实施例中，处理设备在对相应的任务表进行扫描后，如果发现了需要处理的任务，则会生成任务处理消息，并发送给消息设备。进而，消息设备将该任务处理消息发送给各任务处理设备，置于具体地哪个任务处理设备对该任务处理消息进行处理，则取决于哪个任务处理设备优先接收到该任务处理消息。

以上内容是基于任务分发设备侧的方法，对于任务处理设备侧而言，本说明书实施例中还提供一种分布式任务处理方法。如图4所示，具体包括以下步骤：

步骤S401：接收任务分发设备分发的任务消息。

对于所述的任务消息，具体可以参考前述内容，这里不再过多赘述。分布式的各任务处理设备都可能会接收到上述的任务消息。

步骤S403：获取对应于所述任务消息的任务锁。

在本说明书的一个或多个实施例中，由于任务分发设备向分布式的多个任务处理设备分发任务消息，那么，将不止一个任务处理设备接收到该任务消息。对于此情况，为了避免出现对同一任务的重复处理，故采用任务锁的方式，也即，只有获得到任务锁的任务处理设备，才可对相应的任务进行处理。

步骤S405：当获取到所述任务锁时，对所述任务消息进行处理。

作为本说明书中的一种实施例，任务锁具有不同的类型，换言之，不同的任务消息对应着不同的任务锁，任务处理设备需要根据任务消息，获取对应的任务锁。诸如：任务调度消息对应着相应的任务调度锁、任务处理消息对应着任务处理锁等。显然，任务处理设备在获取到相应的任务锁后，实现诸如任务扫描、任务创建、任务拆分等处理。

通过前述如图3及图4的方法可知，在本说明书实施例中，分布式的任务处理架构中无需依赖中央管理服务器，即，并不需要进行任务管理、分配，而是通过相应的任务分发设备，向分布式的各任务处理设备分发任务消息，使得接收到任务消息的任务处理设备“抢”任务锁。只有获取到任务锁的任务处理设备才可以对任务消息进行处理，从而实现了对任务消息的同步互斥处理。特别是在大量任务的情况下，任务分发设备并不需要服务的任务分配逻辑，而仅是将任务消息分发给各任务处理设备，由任务处理设备通过“抢”锁的方式处理任务消息。这样的分布式任务处理方法简单且高效。

在本说明书的实施例中，对任务锁的“抢锁”过程可如图5所示，具体包括以下步骤：

步骤S501：任务处理设备生成取锁字符串。

这里所述的取锁字符串用于获取相应的任务锁。任务处理设备通常将基于其接收到的任务消息，来生成相应的取锁字符串(为了便于描述，在以下的描述中，将取锁字符串简称为：任务锁Key)。

具体而言，如表1所示，示出了在不同的任务场景下的任务锁Key。

表1

从表1中可见，任务锁Key的展现方式与文件目录结构相似，其构成可包括：/***/业务/操作/任务ID。当然，这里仅是一种可行的任务锁的字符结构，在实际应用中还可以采用其他方式，这里并不应作为对本申请的限定。

步骤S503：根据该任务锁Key，在任务锁表中查找任务锁记录，并判断记录是否已存在，若是，则执行步骤S505；否则，则执行步骤S507。

任务锁表可共用于分布式的各个任务处理设备。通过任务锁表，能够避免出现不同任务设备重复持锁的现象。

步骤S505：判断是否为同一使用者，若是，则执行步骤S509；否则，则执行步骤S511。

步骤S507：在任务锁表中***该任务锁Key进行记录。

步骤S509：更新该任务锁Key对应的任务锁的过期时间。

步骤S511：判断任务锁是否超时，若是，则加锁失败；否则，则执行步骤S513。

步骤S513：更新使用者和超时时间。

从图5中可见，在执行完步骤S507、S509以及S513后，均可以获得相应的任务锁ID(也即，成功取锁)。

这里需要说明的是，在任务锁表中，通常可记录有如下信息：

任务锁ID、任务锁Key、任务锁使用者信息、任务锁过期时间

其中，任务锁ID的表现形式可以为：LOCK_时间(年、月、日等)_序列号。

任务锁使用者信息具体可包括：服务器域名、线程号等。

任务锁过期时间可以是具体的时间，用于表征超过该时间后该任务锁失效。

以上是取锁的过程。当任务处理设备处理完相应的任务后，还将释放相应的任务锁，其过程可如图6所示，具体包括以下步骤：

步骤S601：任务处理设备生成解锁字符串。

在本说明书实施例中，所述的解锁字符串，同样也可以是上述的任务锁Key，用以表明需要解除的任务锁。

步骤S603：根据该任务锁Key，在任务锁表中查找任务锁记录，并判断记录是否已存在，若是，则执行步骤S605；否则，解锁失败。

步骤S605：判断是否为同一使用者，若是，则执行步骤S607；否则，解锁失败。

步骤S607：删除任务锁记录。

步骤S609：判断删除是否成功，若是，则解锁成功，否则，解锁失败。

对于如图4所示的方法，当获得了相应的任务锁后，任务处理设备便可以针对任务消息进行处理。在本说明书实施例中，对于不同的任务消息，任务处理设备可以调用相应的处理逻辑进行处理。

为了更清楚地理解上述的分布式任务处理过程，现以一实际应用示例进行说明。在该示例中，可采用如图7所示的业务架构(图7中的架构可认为是图1中架构的扩展)。

在图7中可见，定时任务分发设备用于向多个任务处理设备分发任务调度消息，即，任务创建消息(task_create)和任务扫描消息(task_scan)。该示例中，两种消息定时分发。

消息设备用于向多个任务处理设备分发任务处理消息，即，可拆分任务执行消息(task_execute)和子任务执行消息(taskslice_execute)。

这里需要说明的是，本说明书实施例中的任务处理器(TaskWorker)，可以理解为任务的处理逻辑。每一TaskWorker中都包含5部分的处理逻辑，分别对应于一个任务的5个阶段，即：任务创建、任务分片、任务执行、任务合并、任务结束。上述的5种处理逻辑具有先后顺序，前一个阶段结束了才能进入下一个阶段。

在实际的应用场景中，上述的5中处理逻辑分别对应着5种执行方法，如图8所示。

具体而言，任务创建(getTaskList)方法，用于实现构建任务的逻辑，在这个方法里，将业务任务抽象为一个或多个任务元数据TaskMeta对象，方法返回任务元数据TaskMeta的列表，任务框架后续将这些任务元数据列表存储到主任务表MAIN_TASK中(这里的主任务也就是上述实施例中所提及的可拆分任务，为便于描述，下文中将使用MAIN_TASK进行描述)。

任务分片(split)方法，用于将可拆分任务拆分为一个或多个子任务，主任务和子任务之间通过主任务ID相关联，方法返回子任务业务数据的列表，任务框架后续将这些子任务业务数据列表存储到子任务(TASK_SLICE)表中。

任务执行(execute)方法，用于定义子任务的执行逻辑，执行成功返回true否则为false

任务合并(merge)方法，用于所有子任务执行完成后，将子任务的执行结果合并，执行成功返回true否则返回false。

任务结束(finalize)方法，用于定义整个任务处理完成后的处理逻辑，如：发送任务处理完成通知消息，记录任务完成日志等，执行成功返回true否则返回false。

此外，在任务处理过程中，调用上述5中方法的执行主体，通常可以称为：任务执行器(TaskExecute)。所述的任务执行器具体可以是一种处理单元、或功能单元。任务执行器通常与任务的状态相关，在一个可行的实施例中，所述的任务执行器可以包括：

任务创建执行器(CreateTaskExecutor)，将调用Task对应Taskworker的getTaskList()方法，获得要创建任务的元数据列表，将元数据转换为Task，并将Task存储到主任务表MAIN_TASK中，新创建Task任务状态都是P。

P状态执行器(PendingTaskExecutor)，将调用Task对应Taskworker的split()方法执行任务分片逻辑，将主任务分成一个或多个子任务。

S状态执行器(SplitUpTaskExecutor)，分发某个任务的所有未完成的子任务执行消息分发：查询TASK_SLICE表，找出某个任务所有未执行完的子任务，将这些子任务信息封装为子任务执行消息分发给消息中心。

M状态执行器(MergingTaskExecutor)，将调用Task对应Taskworker的merge()方法，执行子任务合并逻辑。

G状态执行器(MergedTaskExecutor)，将调用Task对应Taskworker的finalize()方法，执行任务完成后的处理逻辑。

分片任务执行器(TaskSliceExecutor)，将调用Task对应Taskworker的execute()方法，执行子任务的主业务逻辑。

基于此，首先说明对任务调度消息的处理过程：

对于task_create消息而言，当任务处理设备接收到任务创建消息之后，将确定所需创建的任务类型，以便在任务处理器集合中查找匹配的任务处理器。也即，当任务处理设备接收到task_create消息后，将获取与该task_create消息对应的任务锁，取锁成功后，在任务处理器集合中，调用每个TaskWorker的getTaskList方法，同时在DB中获取要创建任务元数据列表，查询任务表，检查对应任务是否已经存在，如果不存在，则创建任务，并保存到MAIN_TASK表中。

对于task_scan消息而言，获取扫描任务锁，检查MAIN_TASK表，查找出所有状态非终态(非F和A状态)的Task记录，根据Task的状态执行相应的业务逻辑：

如果Task状态为S，检查TASK_SLICE表，查询该任务对应所有子任务记录状态是否为终态(F)，如果是终态，则将任务状态推进到下一个状态M，如果非终态，将这些子任务的任务ID封装为子任务执行消息，批量发送这些消息到消息设备。

如果Task状态为非S状态，将这些任务的任务ID封装为任务执行消息，批量发送这些消息到消息设备。

对任务处理消息的处理过程：

对于task_execute消息而言，从消息中提取出任务ID，根据任务ID，获取该任务的任务锁，根据任务ID，从MAIN_TASK表中查找对应的Task记录获取任务类型、开始执行时间，任务状态等信息。根据任务类型找到Task对应的任务处理器，根据任务状态找到对应任务执行器。任务执行器内部调用任务处理器对应的方法来执行业务逻辑，例如：对P状态的任务，***将选择任务执行器PendingTaskExecutor，该PendingTaskExecutor内部将调用Task对应Taskworker的split()方法来执行任务分片逻辑。

对于taskslice_execute消息而言，从消息中提取出子任务ID，根据子任务ID，获取该子任务的任务锁。此后，根据子任务ID，从TASK_SLICE表中查找对应的子任务记录，获取该子任务对应的主任务ID、子任务状态、子任务业务数据等信息。根据获取的主任务ID，找到主任务匹配的任务处理器，在子任务执行器TaskSliceExecutor内部调用主任务的任务处理器的execute方法来执行子任务的业务逻辑。

基于上述内容可见，本说明书实施例中分布式的任务处理方法，通过将一个大任务分解为若干子任务的方式，使得各个子任务可以分布式的并行处理，互不依赖。同时，将将任务处理分解为若干个有序阶段，每个阶段的执行相互独立。这样的处理方式更加有效、快捷。

此外，从上述的处理架构可见，架构中并不需要部署中心服务器，在分布式架构中，每个任务处理设备都是独立的处理单元，扩展较为简单。

以上为本说明书实施例提供的分布式的任务处理方法，基于同样的思路，本说明书实施例基于任务处理设备一侧，还提供一种分布式的任务处理装置，如图9所示，所述装置包括：

接收模块901，接收任务分发设备分发的任务消息；

任务锁获取模块902，获取对应于所述任务消息的任务锁；

处理模块903，当获取到所述任务锁时，对所述任务消息进行处理。

具体地，所述任务锁获取模块902，确定所述任务消息对应的待处理任务的任务数据，根据所述任务数据生成取锁字符串，在任务锁表中获取匹配于所述取锁字符串的任务锁；

其中，所述任务数据至少包括：待处理任务的任务状态数据、任务标识数据。

具体地，所述任务锁获取模块902，在获取任务锁之前，在所述任务锁表中，确定所述取锁字符串可用。

更具体地，所述任务锁获取模块902，确定所述取锁字符串未记录在所述任务锁表中。

所述任务锁获取模块902，确定与已记录在所述任务锁表中的取锁字符串的使用者信息相同。

所述任务锁获取模块902，确定已记录在所述任务锁表中、与所述取锁字符串的使用者信息相同的任务锁未超时。

具体地，所述装置还包括：任务锁解除模块904，当对所述任务消息的处理完成时，生成解锁字符串，解除所述任务锁。

具体地，所述处理模块903，确定所述任务消息所对应的待处理任务，调用预先定义的、与该待处理任务对应的任务执行逻辑，对所述待处理任务进行处理；

其中，所述任务消息包括：任务调度消息以及任务处理消息；

所述待处理任务包括：可拆分任务以及根据所述可拆分任务得到的子任务。

具体地，所述任务调度消息包括：任务创建消息及任务扫描消息；

所述处理模块903，当所述任务调度消息为任务创建消息时，调用任务创建逻辑创建可拆分任务，并写入任务表；

当所述任务调度消息为任务扫描消息时，调用任务扫描逻辑在所述任务表中扫描未处理的可拆分任务以及子任务。

所述任务处理消息包括：可拆分任务处理消息及子任务处理消息；

所述处理模块903，当所述任务处理消息为可拆分任务处理消息时，调用可拆分任务的处理逻辑对所述可拆分任务进行处理；

当所述任务处理消息为子任务处理消息时，调用子任务的处理逻辑对所述子任务进行处理；

其中，可拆分任务的处理逻辑至少包括：对可拆分任务进行拆分、对合并后的可拆分任务完成处理；

子任务的处理逻辑至少包括：查找未处理的子任务、按照子任务的业务逻辑处理该子任务、对处理完成后的多个子任务进行合并。

具体对，所述装置还包括：消息反馈模块905，根据所述处理模块查找到的各未处理的子任务，生成子任务执行消息发送给所述任务分发设备。

基于上述如图9所述的装置，本说明书实施例还提供一种分布式的任务处理设备，包括：

存储器，存储任务处理程序；

通讯接口，接收任务分发设备分发的任务消息；

处理器，在通讯接口接收到任务消息后，调用存储器中存储的任务处理程序，并执行：

获取匹配于所述任务消息的任务锁；

当获取到所述任务锁时，对所述任务消息进行处理。

如图10所示，本说明书实施例基于任务分发设备一侧，还提供一种分布式的任务处理装置，所述装置包括：

接收模块1001，接收消息发送规则；

消息分发模块1002，根据所述消息发送规则，生成任务消息分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

具体地，所述任务消息包括：任务调度消息和任务处理消息；

所述消息分发模块1002，针对所述任务调度消息，按照设定周期，将生成的任务调度消息分发给各任务处理服务器；

针对所述任务处理消息，接收由任务处理设备发送的任务执行消息，根据所述任务执行消息生成任务处理消息并分发给各任务处理设备。

基于上述如图10所述的装置，本说明书实施例还提供一种分布式的任务处理设备，包括：

存储器，存储任务处理程序；

通讯接口；

处理器，调用存储器中存储的任务处理程序，并执行：

根据所述消息发送规则，生成任务消息通过所述通讯接口分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

本说明书实施例还提供一种分布式的任务处理***，至少包括：分布式的任务处理服务器、任务分发设备以及任务数据库，其中，

所述分布式的任务处理服务器，接收任务分发设备分发的任务消息，获取对应于所述任务消息的任务锁，当获取到所述任务锁时，对所述任务消息进行处理；

所述任务分发设备，按照设定的消息发送规则，将任务消息分发给各分布式的任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理；

所述任务数据库，存储任务数据以及由所述任务处理服务器写入的待处理任务。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和介质类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可，这里就不再一一赘述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤或模块可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在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 (29)

1.一种分布式的任务处理方法，任务分发设备向分布式的任务处理设备分发任务消息；所述方法包括：

所述任务处理设备接收所述任务分发设备分发的任务消息；

获取匹配于所述任务消息的任务锁；

当获取到所述任务锁时，对所述任务消息进行处理。

2.如权利要求1所述的方法，获取匹配于所述任务消息的任务锁，具体包括：

确定所述任务消息对应的待处理任务的任务数据；

根据所述任务数据生成取锁字符串；

在任务锁表中获取匹配于所述取锁字符串的任务锁；

其中，所述任务数据至少包括：待处理任务的任务状态数据、任务标识数据。

3.如权利要求2所述的方法，在获取任务锁之前，所述方法还包括：

在所述任务锁表中，确定所述取锁字符串可用。

4.如权利要求3所述的方法，确定所述取锁字符串可用，具体包括：

确定所述取锁字符串未记录在所述任务锁表中。

5.如权利要求3所述的方法，确定所述取锁字符串可用，具体包括：

确定与已记录在所述任务锁表中的取锁字符串的使用者信息相同。

6.如权利要求3所述的方法，确定所述取锁字符串可用，具体包括：

确定已记录在所述任务锁表中、与所述取锁字符串的使用者信息相同的任务锁未超时。

7.如权利要求1所述的方法，所述方法还包括：

当对所述任务消息的处理完成时，生成解锁字符串，解除所述任务锁。

8.如权利要求1所述的方法，对所述任务消息进行处理，具体包括：

确定所述任务消息所对应的待处理任务；

调用预先定义的、与该待处理任务对应的任务执行逻辑，对所述待处理任务进行处理；

其中，所述任务消息包括：任务调度消息以及任务处理消息；

所述待处理任务包括：可拆分任务以及根据所述可拆分任务得到的子任务。

9.如权利要求8所述的方法，所述任务调度消息包括：任务创建消息及任务扫描消息；

调用预先定义的、与该待处理任务对应的任务执行逻辑，对所述待处理任务进行处理，具体包括：

当所述任务调度消息为任务创建消息时，调用任务创建逻辑创建可拆分任务，并写入任务表；

当所述任务调度消息为任务扫描消息时，调用任务扫描逻辑在所述任务表中扫描未处理的可拆分任务以及子任务。

10.如权利要求8所述的方法，所述任务处理消息包括：可拆分任务处理消息及子任务处理消息；

调用预先定义的、与该待处理任务对应的任务执行逻辑，对所述待处理任务进行处理，具体包括：

当所述任务处理消息为可拆分任务处理消息时，调用可拆分任务的处理逻辑对所述可拆分任务进行处理；

当所述任务处理消息为子任务处理消息时，调用子任务的处理逻辑对所述子任务进行处理；

其中，可拆分任务的处理逻辑至少包括：对可拆分任务进行拆分、对合并后的可拆分任务完成处理；

子任务的处理逻辑至少包括：查找未处理的子任务、按照子任务的业务逻辑处理该子任务、对处理完成后的多个子任务进行合并。

11.如权利要求9所述的方法，所述方法还包括：

根据查找到的各未处理的子任务，生成子任务执行消息发送给所述任务分发设备。

12.一种分布式的任务处理方法，包括：

任务分发设备接收消息发送规则；

根据所述消息发送规则，生成任务消息分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

13.如权利要求12所述的方法，所述任务消息包括：任务调度消息和任务处理消息；

根据所述消息发送规则，生成任务消息分发给各任务处理服务器，具体包括：

针对所述任务调度消息，按照设定周期，将生成的任务调度消息分发给各任务处理服务器；

针对所述任务处理消息，接收由任务处理设备发送的任务执行消息，根据所述任务执行消息生成任务处理消息并分发给各任务处理设备。

14.一种分布式的任务处理装置，任务分发设备向分布式的任务处理设备分发任务消息；所述装置包括：

接收模块，接收所述任务分发设备分发的任务消息；

任务锁获取模块，获取匹配于所述任务消息的任务锁；

处理模块，当获取到所述任务锁时，对所述任务消息进行处理。

15.如权利要求14所述的装置，所述任务锁获取模块，确定所述任务消息对应的待处理任务的任务数据，根据所述任务数据生成取锁字符串，在任务锁表中获取匹配于所述取锁字符串的任务锁；

其中，所述任务数据至少包括：待处理任务的任务状态数据、任务标识数据。

16.如权利要求15所述的装置，所述任务锁获取模块，在获取任务锁之前，在所述任务锁表中，确定所述取锁字符串可用。

17.如权利要求16所述的装置，所述任务锁获取模块，确定所述取锁字符串未记录在所述任务锁表中。

18.如权利要求16所述的装置，所述任务锁获取模块，确定与已记录在所述任务锁表中的取锁字符串的使用者信息相同。

19.如权利要求16所述的装置，所述任务锁获取模块，确定已记录在所述任务锁表中、与所述取锁字符串的使用者信息相同的任务锁未超时。

20.如权利要求14所述的装置，所述装置还包括：任务锁解除模块，当对所述任务消息的处理完成时，生成解锁字符串，解除所述任务锁。

21.如权利要求14所述的装置，所述处理模块，确定所述任务消息所对应的待处理任务，调用预先定义的、与该待处理任务对应的任务执行逻辑，对所述待处理任务进行处理；

其中，所述任务消息包括：任务调度消息以及任务处理消息；

所述待处理任务包括：可拆分任务以及根据所述可拆分任务得到的子任务。

22.如权利要求21所述的装置，所述任务调度消息包括：任务创建消息及任务扫描消息；

所述处理模块，当所述任务调度消息为任务创建消息时，调用任务创建逻辑创建可拆分任务，并写入任务表；

当所述任务调度消息为任务扫描消息时，调用任务扫描逻辑在所述任务表中扫描未处理的可拆分任务以及子任务。

23.如权利要求21所述的装置，所述任务处理消息包括：可拆分任务处理消息及子任务处理消息；

所述处理模块，当所述任务处理消息为可拆分任务处理消息时，调用可拆分任务的处理逻辑对所述可拆分任务进行处理；

当所述任务处理消息为子任务处理消息时，调用子任务的处理逻辑对所述子任务进行处理；

其中，可拆分任务的处理逻辑至少包括：对可拆分任务进行拆分、对合并后的可拆分任务完成处理；

子任务的处理逻辑至少包括：查找未处理的子任务、按照子任务的业务逻辑处理该子任务、对处理完成后的多个子任务进行合并。

24.如权利要求22所述的装置，所述装置还包括：消息反馈模块，根据所述处理模块查找到的各未处理的子任务，生成子任务执行消息发送给所述任务分发设备。

25.一种分布式的任务处理装置，包括：

接收模块，接收消息发送规则；

消息分发模块，根据所述消息发送规则，生成任务消息分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。

26.如权利要求25所述的装置，所述任务消息包括：任务调度消息和任务处理消息；

所述消息分发模块，针对所述任务调度消息，按照设定周期，将生成的任务调度消息分发给各任务处理服务器；

针对所述任务处理消息，接收由任务处理设备发送的任务执行消息，根据所述任务执行消息生成任务处理消息并分发给各任务处理设备。

27.一种分布式的任务处理***，至少包括：分布式的任务处理服务器、任务分发设备以及任务数据库，其中，

所述分布式的任务处理服务器，接收任务分发设备分发的任务消息，获取对应于所述任务消息的任务锁，当获取到所述任务锁时，对所述任务消息进行处理；

所述任务分发设备，按照设定的消息发送规则，将任务消息分发给各分布式的任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理；

所述任务数据库，存储任务数据、任务锁表以及由所述任务处理服务器写入的待处理任务。

28.一种分布式的任务处理设备，包括：

存储器，存储任务处理程序；

通讯接口，接收任务分发设备分发的任务消息；

处理器，在通讯接口接收到任务消息后，调用存储器中存储的任务处理程序，并执行：

获取匹配于所述任务消息的任务锁；

当获取到所述任务锁时，对所述任务消息进行处理。

29.一种分布式的任务处理设备，包括：

存储器，存储任务处理程序；

通讯接口；

处理器，调用存储器中存储的任务处理程序，并执行：

根据所述消息发送规则，生成任务消息通过所述通讯接口分发给各任务处理服务器，以使得接收到所述任务消息的任务处理服务器基于所述任务消息进行任务处理。