CN105446801A - 分布式系统中的任务处理方法和装置 - Google Patents

Abstract

本申请实施例公开了一种分布式系统中的任务处理方法和装置。其中，该方法包括：所述多个任务处理器中的任一任务处理器在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活；如果所述任务的当前存活状态为存活，则不处理所述任务；如果所述任务的当前存活状态为死亡，先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡。根据本申请的实施例，可以解决现有技术中因多个任务服务器(或任务进程)重复处理同一个任务所引起的业务数据不满足幂等性的问题。

Description

分布式系统中的任务处理方法和装置

技术领域

本申请涉及分布式计算领域，特别是涉及分布式系统中的任务处理方法和装置。

背景技术

无论是在大型的互联网应用中，还是在企业级架构中，都越来越广泛地采用分布式服务框架来提供各种服务。例如，在一个大型的互联网应用中，不可避免地需要将一个“应用”拆分成多个“业务”(或者，也可以称为“服务”)，而每个“业务”对应的任务最终是由分布式系统中的服务器处理完成的。

一般情况下，一个“应用”下的各“业务”之间很可能会存在依赖关系，并且，依赖关系还可能错综复杂。因此，对于每一个“业务”而言，都有可能因为其依赖的其它“业务”出现异常而被迫中断。此时，就需要对中断“业务”进行异常处理。现有技术中的一种异常处理方式是：将中断“业务”在中断前的业务数据保存到存储服务器上，待触发重新处理该中断“业务”对应的任务时，再由分布式系统中的任务服务器(或任务进程)根据存储服务器上的业务数据继续处理该中断“业务”对应的任务。

在实现本申请的过程中，本申请的发明人发现现有技术中至少存在如下问题：当“业务”中断后，是由工作人员通过在后台界面上进行人工操作来触发重新处理中断“业务”对应的任务的。但是，如果在误操作的情况下，多名工作人员重复性地触发重新处理同一个中断“业务”对应的任务，就会造成多个任务服务器(或任务进程)重复处理同一个任务，从而引起业务数据不满足幂等性要求。

发明内容

为了解决上述技术问题，本申请实施例提供了分布式系统中的任务处理方法和装置，以解决现有技术中因多个任务服务器(或任务进程)重复处理同一个任务所引起的业务数据不满足幂等性的问题。

本申请实施例公开了如下技术方案：

一种分布式系统中的任务处理方法，所述分布式系统包括多个任务处理器，所述方法包括：

所述多个任务处理器中的任一任务处理器在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活；

如果所述任务的当前存活状态为存活，则不处理所述任务；如果所述任务的当前存活状态为死亡，先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡。

优选的，所述方法还包括：

在将所述任务的当前存活状态从死亡标记为存活后，所述多个任务处理器中的任一任务处理器被设置为定时更新所述任务的当前存活时间。

进一步优选的，所述方法还包括：

所述多个任务处理器中的任一任务处理器被设置为定时判断所述任务的当前存活状态是否为存活；

如果所述任务的当前存活状态为存活，进一步判断所述任务持续存活的时间长度是否大于或等于预设的时间长度阈值；

如果是，更改所述任务的当前存活状态为死亡，否则，保持所述任务的当前存活状态为存活。

优选的，所述方法还包括：

在启动任务之前，判断预设的工作周期是否到达；

如果是，自动启动所述任务，否则，不启动所述任务。

优选的，所述分布式系统还包括与所述多个任务处理器通信的存储服务器，所述判断所述任务的当前存活状态是否为存活，包括：

读取保存在所述存储服务器中的用于指示所述任务的当前存活状态的标识；

根据所述标识确定所述任务的当前存活状态是否为存活。

进一步优选的，每种类型下的任务在所述存储服务器上保存唯一一个所述标识。

一种分布式系统中的任务处理装置，包括：

第一判断模块，用于在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活；

任务处理模块，用于如果所述第一判断模块的判断结果为是，不处理所述任务，如果所述第一判断模块的判断结果为否，先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡。

优选的，所述装置还包括：

存活时间更新模块，用于在将所述任务的当前存活状态从死亡标记为存活后，定时更新所述任务的当前存活时间。

进一步优选的，所述装置还包括：

第二判断模块，用于定时判断所述任务的当前存活状态是否为存活；

第三判断模块，用于如果所述第二判断模块的判断结果为是，进一步判断所述任务持续存活的时间长度是否大于或等于预设的时间长度阈值；

状态修正模块，用于如果所述第三判断模块的判断结果为是，更改所述任务的当前存活状态为死亡，如果所述第三判断模块的判断结果为否，保持所述任务的当前存活状态为存活。

优选的，所述装置还包括：

第四判断模块，用于在启动任务之前，判断预设的工作周期是否到达；

启动模块，用于如果所述第四判断模块的判断结果为是，自动启动所述任务，如果所述第四判断模块的判断结果为否，不启动所述任务。

优选的，所述第一判断模块包括：

读取子模块，用于读取保存在存储服务器中的用于指示所述任务的当前存活状态的标识；

识别子模块，用于根据所述标识确定所述任务的当前存活状态是否为存活。

进一步优选的，每种类型下的任务在所述存储服务器上保存唯一一个所述标识。

由上述实施例可以看出，与现有技术相比，本申请技术方案的优点在于：

当分布式系统中的一个任务处理器(或任务进程)正在处理某任务时，该任务的存活状态就会标记为存活，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为存活，进而就不会再去处理该任务。当该任务处理器(或任务进程)处理完该任务时，该任务的存活状态就会标识为死亡，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为死亡，就可以处理该任务。保证多个任务服务器(或任务进程)不会重复处理同一个任务，进而也保证了业务数据的幂等性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1示意性地示出了本申请的实施方式可以在其中实施的示例性应用场景；

图2为本申请一个实施例提供的一种分布式系统中的任务处理方法的流程图；

图3为本申请另一个实施例提供的一种分布式系统中的任务处理方法的流程图；

图4为本申请另一个实施例提供的一种分布式系统中的任务处理方法的流程图；

图5为本申请另一个实施例提供的一种分布式系统场景下的任务处理方法的示意图；

图6为本申请一个实施例提供的一种分布式系统中的任务处理装置的结构框图；

图7为本申请另一个实施例提供的另一种分布式系统中的任务处理装置的结构框图；

图8为本申请另一个实施例提供的另一种分布式系统中的任务处理装置的结构框图；

图9为本申请另一个实施例提供的另一种分布式系统中的任务处理装置的结构框图；

图10为本申请实施例四提供的第一判断模块的一种结构框图。

具体实施方式

本申请实施例提供了分布式系统中的任务处理方法和装置。本申请实施例所涉及的技术方案的核心在于，利用存活状态(存活状态包括存活和死亡)向任务处理器(或任务进程)指示某任务是否正在被其它任务处理器(或任务进程)处理。基于存活状态，当分布式系统中的一个任务处理器(或任务进程)正在处理某任务时，该任务的存活状态就会标记为存活，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为存活，进而就不会再去处理该任务。当该任务处理器(或任务进程)处理完该任务时，该任务的存活状态就会标识为死亡，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为死亡，就可以处理该任务。

首先参考图1，图1示意性地示出了本申请的实施方式可以在其中实施的示例性应用场景。其中，当业务A被迫中断时，管理服务器10会将业务A对应的任务21存储到一个任务队列30中，并将业务A在中断前的业务数据22保存到存储服务器41上，以及将任务21的当前存活状态211保存到存储服务器42上(此时，由于任务21没有被任何一个任务处理器处理，因此，任务21的当前存活状态211被标记为死亡)。在此之后，当任务服务器51在触发下从任务队列30中的提取任务21并启动了任务21时，任务处理器51从存储服务器42中读取任务21的当前存活状态211，当确定当前存活状态211为死亡时，先将任务21的当前存活状态211从死亡标记为存活，再从存储服务器41中读取业务A在中断前的业务数据22，并基于业务数据22处理任务21。在任务处理器51处理任务21的过程中，如果任务处理器52也在触发下启动从任务队列30中提取任务21并启动了任务21，任务处理器52先从存储服务器42读取任务21的当前存活状态211，此时，由于确定出当前存活状态211为存活，因此，任务处理器52不会对任务21进行处理。当任务处理器51对任务21处理完毕后，任务处理器51再将任务21的当前存活状态211从存活重新标记为死亡。

管理服务器10可以是Web服务器，也可以是其他类型的服务器，例如APP服务器。任务处理器51和52还可以是任务进程。本领域技术人员可以理解，图1所示的示意图仅是本申请的实施方式可以在其中得以实现的一个示例。本申请实施方式的应用范围不受到该框架任何方面的限制。

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例进行详细描述。

方法实施例

请参阅图2，其为本申请一个实施例提供的一种分布式系统中的任务处理方法的流程图，所述分布式系统包括多个任务处理器，该方法包括以下步骤：

步骤201：所述多个任务处理器中的任一任务处理器在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活，如果是，进入步骤202，否则，进入步骤203。

在本申请的一个优选实施方式中，读取保存在存储服务器中的用于指示所述任务的当前存活状态的标识，所述存活状态包括存活和死亡；根据所述标识确定所述任务的当前存活状态是否为存活。

具体地，可以将该任务的任务名以及当前存活状态的标识以映射关系保存在存储服务器上，以便先根据任务名找到对应的当前存活状态的标识，然后再从存储服务器中读取该标识。

步骤202：不处理所述任务，结束流程。

步骤203：先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡，结束流程。

需要说明的是，上述“任务”可以是一个任务，也可以是同一个业务类型下的多个任务。

在申请的另一个优选实施方式中，每种类型下的任务在所述存储服务器上保存唯一一个所述标识。

另外，如果是由工作人员触发重新处理中断“业务”对应的任务，考虑到工作人员往往并不能及时进行触发，就会影响到“业务”处理的实时性。特别是某些对于实时性要求比较高的“业务”，对于延迟几乎是无法容忍的。

因此，在本申请的一个优选实施方式中，如图3所示，在启动任务之前，判断预设的工作周期是否到达，如果到达，自动启动所述任务，如果没有到达，不启动所述任务(并继续判断预设的工作周期是否到达)。

可以理解的，作为一种替换方案，各任务处理器(或任务进程)并不是在工作人员的触发下启动并处理各中断“业务”对应的任务，而是每隔一定的时间段就自动启动中断“业务”对应的任务，从而保证“业务”处理的实时性。

需要说明的是，在本申请的技术方案中，并不限定工作周期的具体长度。工作周期的长度可以由业务类型决定，即，对于实时性处理要求越高的业务，工作周期的长度越短，反之，对于实时性处理要求越低的业务，工作周期的长度越长。另外，各个任务处理器(或任务进程)之间的工作周期可以是同步的，但是，为了避免竞争，更优选的方式是不同步。

由上述实施例可以看出，与现有技术相比，本申请技术方案的优点在于：

当分布式系统中的一个任务处理器(或任务进程)正在处理某任务时，该任务的存活状态就会标记为存活，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为存活，进而就不会再去处理该任务。当该任务处理器(或任务进程)处理完该任务时，该任务的存活状态就会标识为死亡，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为死亡，就可以处理该任务。保证多个任务服务器(或任务进程)不会重复处理同一个任务，进而也保证了业务数据的幂等性。

如果任务处理器(或任务进程)在处理任务的过程中突然发生故障，如，任务处理器突然断电，或者任务进程突然崩溃，就无法及时更新任务的当前存活状态，即，任务将一直处于存活状态。在这种情况下，其它任务处理器(或处理进程)将无法继续处理该任务。为了解决这个问题，在实施例一的步骤203中，在将任务的当前存活状态从死亡标记为存活后，所述多个任务处理器中的任一任务处理器还需要被设置为定时更新所述任务的当前存活时间。

其中，在存储服务器中，不仅保存有任务的任务名以及当前存活状态的标识，还保存有任务的当前存活时间，并且任务的当前存活时间是实时更新的。

当存储服务器中保存有任务的当前存活时间时，分布式系统中的任意一个或任意多个任务服务器(任务进程)就可以根据任务的当前存活时间对该任务进行定时的检测，一旦发现该任务持续存活的时间长度是否大于或等于预设的时间长度阈值，就将该任务的当前存活状态更改为死亡。

请参阅图4，其为本申请另一个实施例提供的一种分布式系统中的任务检测方法的流程图，在任务处理器(或任务进程)执行实施例一中的任务处理方法的同时，执行该任务检测方法，其可以包括以下步骤：

步骤401：所述多个任务处理器中的任一任务处理器被设置为定时判断所述任务的当前存活状态是否为存活，如果是，进入步骤402，否则，返回步骤401。

步骤402：判断所述任务持续存活的时间长度是否大于或等于预设的时间长度阈值，如果是，进入步骤403，否则，进入步骤404。

其中，预设的时间长度阈值可以是所述任务执行耗时的历史最大值的N倍，N为非零整数。

步骤403：更改所述任务的当前存活状态为死亡，结束流程。

步骤404：保持所述任务的当前存活状态为存活，结束流程。

由上述实施例可以看出，与现有技术相比，本申请技术方案的优点在于：

除了可以保证多个任务服务器(或任务进程)不会重复处理同一个任务，进而也保证了业务数据的幂等性之外，还保证了当任务处理器(或任务进程)在处理任务的过程中因突然发生故障而无法及时更新任务的当前存活状态，使任务一直处于存活状态时，其它任务处理器(或处理进程)还可以正常地继续处理该任务。

下面以由三个任务处理器(分别为任务处理器1、2和3)所构成的分布式系统为例，说明三个任务处理器处理任务的方法。假设，任务处理器1、2和3每隔5分钟启动一次任务，并且，由任务处理器1每隔5分钟进行一次任务检测。

请参阅图5，其为本申请另一个实施例提供的一种分布式系统场景下的任务处理方法的示意图，该方法包括以下步骤：

步骤511：任务处理器1在1点10分启动任务A。

其中，任务A表示业务类型A对应的所有任务，其可以为一个任务集合。

步骤512：任务处理器1从存储服务器中获取任务A的当前存活状态。

其中，任务A的当前存活状态包括存活和死亡。

步骤513：任务处理器1根据任务A的当前存活状态确定任务A死亡，将存储服务器中任务A的当前存活状态从死亡标记为存活。

步骤514：任务处理器1处理任务A。

步骤515：任务处理器1在处理任务A的过程中，每隔30秒更新存储服务器中任务A的当前存活时间。

步骤516：任务处理器1在1点15分停止处理任务A(此时任务A还没有全部处理完毕)，将存储服务器中任务A的当前存活状态从存活标记为死亡。

步骤521：任务处理器2在1点12分启动任务A。

步骤522：任务处理器2从存储服务器中获取任务A的当前存活状态。

步骤523：任务处理器2根据任务A的当前存活状态确定任务A存活，不处理任务A。

步骤531：任务处理器3在1点16分启动任务A。

步骤532：任务处理器3从存储服务器中获取任务A的当前存活状态。

步骤533：任务处理器3根据任务A的当前存活状态确定任务A死亡，将存储服务器中任务A的当前存活状态从死亡标记为存活。

步骤534：任务处理器3处理任务A。

步骤535：任务处理器3在处理任务A的过程中，每隔30秒更新存储服务器中任务A的当前存活时间。

步骤536：任务处理器3在1点19分处理完所有的任务A，将存储服务器中任务A的当前存活状态从存活标记为死亡。

步骤541：任务处理器1在1点10分启动检测任务。

步骤542：任务处理器1从1点10分开始，每隔30秒从存储服务器中获取任务A的当前存活状态和当前存活时间。

步骤543：如果任务处理器1根据任务A的当前存活状态确定任务A存活，并且根据任务A的当前存活时间确定任务A持续存活的时间长度大于或等于5分钟，将存储服务器中任务A的当前存活状态更改为死亡。

由上述实施例可以看出，与现有技术相比，本申请技术方案的优点在于：

当分布式系统中的一个任务处理器(或任务进程)正在处理某任务时，该任务的存活状态就会标记为存活，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为存活，进而就不会再去处理该任务。当该任务处理器(或任务进程)处理完该任务时，该任务的存活状态就会标识为死亡，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为死亡，就可以处理该任务。保证多个任务服务器(或任务进程)不会重复处理同一个任务，进而也保证了业务数据的幂等性。

另外，还保证了当任务处理器(或任务进程)在处理任务的过程中因突然发生故障而无法及时更新任务的当前存活状态，使任务一直处于存活状态时，其它任务处理器(或处理进程)还可以正常地继续处理该任务。

装置实施例

与上述一种分布式系统中的任务处理方法相对应，本申请实施例还提供了一种分布式系统中的任务处理装置。请参阅图6，其为本申请一个实施例提供的一种分布式系统中的任务处理装置的结构框图，该装置包括第一判断模块601和任务处理模块602。下面结合该装置的工作原理进一步介绍其内部结构以及连接关系。

第一判断模块601，用于在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活；

任务处理模块602，用于如果所述第一判断模块601的判断结果为是，不处理所述任务，如果所述第一判断模块601的判断结果为否，先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡。

在本申请的一个优选实施方式中，如图7所示，在图6所示的结构的基础之上，该装置还包括：存活时间更新模块603a，用于在将所述任务的当前存活状态从死亡标记为存活后，定时更新所述任务的当前存活时间。

在本发明的另一个优选实施方式中，如图8所示，该装置进一步还包括：

第二判断模块604a，用于定时判断所述任务的当前存活状态是否为存活；

第三判断模块605a，用于如果所述第二判断模块的判断结果为是，进一步判断所述任务持续存活的时间长度是否大于或等于预设的时间长度阈值；

状态修正模块606a，用于如果所述第三判断模块的判断结果为是，更改所述任务的当前存活状态为死亡，如果所述第三判断模块的判断结果为否，保持所述任务的当前存活状态为存活。

在本发明的一个优选实施方式中，如图9所示，在图6所示的结构的基础之上，还装置还包括：

第四判断模块603b，用于在启动任务之前，判断预设的工作周期是否到达；

启动模块604b，用于如果所述第四判断模块的判断结果为是，自动启动所述任务，如果所述第四判断模块的判断结果为否，不启动所述任务。

在本发明的一个优选实施方式中，如图10所示，第一判断模块601包括：

读取子模块6011，用于读取保存在存储服务器中的用于指示所述任务的当前存活状态的标识；

识别子模块6012，用于根据所述标识确定所述任务的当前存活状态是否为存活。

在本申请的另一个优选实施方式中，每种类型下的任务在所述存储服务器上的保存唯一一个所述标识。

由上述实施例可以看出，与现有技术相比，本申请技术方案的优点在于：

当分布式系统中的一个任务处理器(或任务进程)正在处理某任务时，该任务的存活状态就会标记为存活，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为存活，进而就不会再去处理该任务。当该任务处理器(或任务进程)处理完该任务时，该任务的存活状态就会标识为死亡，此时，如果有其它的任务处理器(或任务进程)也想要处理该任务，根据存活状态就可以确定该任务为死亡，就可以处理该任务。保证多个任务服务器(或任务进程)不会重复处理同一个任务，进而也保证了业务数据的幂等性。

另外，还保证了当任务处理器(或任务进程)在处理任务的过程中因突然发生故障而无法及时更新任务的当前存活状态，使任务一直处于存活状态时，其它任务处理器(或处理进程)还可以正常地继续处理该任务。

所述领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述到的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，可以采用软件功能单元的形式实现。

需要说明的是，本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-OnlyMemory，ROM)或随机存储记忆体(RandomAccessMemory，RAM)等。

以上对本申请所提供的分布式系统中的任务处理方法和装置进行了详细介绍，本文中应用了具体实施例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

1.一种分布式系统中的任务处理方法，所述分布式系统包括多个任务处理器，其特征在于，所述方法包括：

所述多个任务处理器中的任一任务处理器在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活；

如果所述任务的当前存活状态为存活，则不处理所述任务；如果所述任务的当前存活状态为死亡，先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在将所述任务的当前存活状态从死亡标记为存活后，所述多个任务处理器中的任一任务处理器被设置为定时更新所述任务的当前存活时间。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

所述多个任务处理器中的任一任务处理器被设置为定时判断所述任务的当前存活状态是否为存活；

如果所述任务的当前存活状态为存活，进一步判断所述任务持续存活的时间长度是否大于或等于预设的时间长度阈值；

如果是，更改所述任务的当前存活状态为死亡，否则，保持所述任务的当前存活状态为存活。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在启动任务之前，判断预设的工作周期是否到达；

如果是，自动启动所述任务，否则，不启动所述任务。

5.根据权利要求1至4中任意一项所述的方法，其特征在于，所述分布式系统还包括与所述多个任务处理器通信的存储服务器，所述判断所述任务的当前存活状态是否为存活，包括：

读取保存在所述存储服务器中的用于指示所述任务的当前存活状态的标识；

根据所述标识确定所述任务的当前存活状态是否为存活。

6.根据权利要求5所述的方法，其特征在于，每种类型下的任务在所述存储服务器上保存唯一一个所述标识。

7.一种分布式系统中的任务处理装置，其特征在于，包括：

第一判断模块，用于在启动任务之后且处理所述任务之前，判断所述任务的当前存活状态是否为存活；

任务处理模块，用于如果所述第一判断模块的判断结果为是，不处理所述任务，如果所述第一判断模块的判断结果为否，先将所述任务的当前存活状态从死亡标记为存活，再处理所述任务，并在处理完所述任务后，将所述任务的当前存活状态从存活标记为死亡。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

存活时间更新模块，用于在将所述任务的当前存活状态从死亡标记为存活后，定时更新所述任务的当前存活时间。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

第二判断模块，用于定时判断所述任务的当前存活状态是否为存活；

第三判断模块，用于如果所述第二判断模块的判断结果为是，进一步判断所述任务持续存活的时间长度是否大于或等于预设的时间长度阈值；

状态修正模块，用于如果所述第三判断模块的判断结果为是，更改所述任务的当前存活状态为死亡，如果所述第三判断模块的判断结果为否，保持所述任务的当前存活状态为存活。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括：

第四判断模块，用于在启动任务之前，判断预设的工作周期是否到达；

启动模块，用于如果所述第四判断模块的判断结果为是，自动启动所述任务，如果所述第四判断模块的判断结果为否，不启动所述任务。

11.根据权利要求7至10中任意一项所述的装置，其特征在于，所述第一判断模块包括：

读取子模块，用于读取保存在存储服务器中的用于指示所述任务的当前存活状态的标识；

识别子模块，用于根据所述标识确定所述任务的当前存活状态是否为存活。

12.根据权利要求11所述的装置，其特征在于，每种类型下的任务在所述存储服务器上保存唯一一个所述标识。