一种任务的执行方法、装置及其存储介质与流程

本发明涉及互联网技术领域，尤其是指一种任务的执行方法、装置及其存储介质。

背景技术：

在执行任务时，经常会遇到一些耗时比较长的任务。比如，需要对线上数据库集群中主库和从库数据是否一致进行校验，尤其遇到数据量较大的情况，校验时间可能会持续好几个小时。再比如对线上数据库集群中主库和从库角色进行切换，为了使切换不在中间发生异常，通常会做一些前置的检查、环境的初始化操作，整个过程可能持续几分钟。整个数据库集群的升级需要对每一个从库，先启动新的服务，之后导入备份数据，追平数据，等待服务正常，删掉老的从库，最后按照同样的方式将老的主库切换到新的服务器上，上述的整个过程都会耗费较长的时间去执行。在一般的web服务器上运行这些服务，服务升级或者重启的时候要观察在先的任务是否执行结束，否则要等待正在执行的任务排空。任务之间的相互影响造成了不必要的等待和关联。

执行任务的时候一般都涉及状态的修改、软件的安装、密码账号的维护、耗费性能的比对等，上述涉及的内容都应该是单实例运行的，但是这会导致在运行服务的服务器宕机时，执行任务不可用，这一点不符合当前对服务高性能、高可用的要求。发明人发现现有技术中至少存在如下问题，在执行任务时由于任务之间的相互等待和关联，导致后续的任务无法执行，处于不可用的状态。

技术实现要素：

本发明的实施例提供了一种任务的执行方法，该方法包括：

接收用户发布的任务；

将所述任务存储在预设的任务数据库中；

按照预定方式确定生成子程序的预定数量；

根据所述预定数量生成对应数量的子程序；

每个子程序分别独立探测所述数据库中的任务；

子程序将探测发现的任务提交到对应的预置执行程序中进行执行。

可选地，所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行步骤后，该方法还包括：

判断所述任务在预置执行程序中的执行情况；

如果任务执行失败，那么将所述任务发送回所述数据库，返回执行所述每个子程序分别独立探测所述数据库中的任务的步骤。

可选地，所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行步骤前，该方法还包括：

根据所述任务选择执行任务集市中对应的所述预置执行程序，其中，所述执行任务集市为执行任务的多项执行程序。

可选地，所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行步骤之前，该方法还包括：

每个子程序获取任务的提交权限；

如果获取任务的提交权限成功，执行所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行的步骤。

可选地，每个子程序通过分布式锁的方式获取任务的权限。

可选地，所述每个子程序通过分布式锁的方式获取提交任务的权限包括：

对任务进行赋值得到具有初始赋值的任务；

将赋值后的任务进行加锁；

根据预定算法对任务的初始赋值进行计算得到任务的判断值；

对具有判断值的任务进行解锁；

根据预定判断原则对判断值进行判断得到判断结果；

根据判断结果获取提交任务的权限。

可选地，所述按照预定方式确定生成子程序的预定数量为按照根据所述数据库中任务数量生成对应数量子程序的方式确定子程序的数量。

本申请还提供了一种任务的执行装置，包括：

接收模块，用于接收用户发布的任务；

存储模块，用于将所述任务存储在预设的任务数据库中；

确定模块，用于按照预定方式确定生成子程序的预定数量；

生成模块，用于根据所述预定数量生成对应数量的子程序；

探测模块，用于每个子程序分别独立探测所述数据库中的任务；

提交模块，用于子程序将探测发现的任务提交到对应的预置执行程序中进行执行。

可选地，所述执行装置还包括：

选择模块，还用于根据所述任务选择执行任务集市中对应的所述预置执行程序，其中，所述执行任务集市为执行任务的多项执行程序。

可选地，所述执行装置进一步包括：

获取权限模块，用于每个子程序获取任务的提交权限；

所述提交模块，还用于如果获取任务的提交权限成功，执行所述将探测发现的任务提交到对应的预置执行程序中进行执行的步骤。

可选地，所述执行装置进一步包括：

所述获取权限模块，还用于每个子程序通过分布式锁的方式获取任务的权限。

可选地，所述执行装置进一步包括：

赋值模块，用于对任务进行赋值得到具有初始赋值的任务；

加锁模块，用于将赋值后的任务进行加锁；

计算模块，用于根据预定算法对任务的初始赋值进行计算得到任务的判断值；

解锁模块，用于对具有判断值的任务进行解锁；

判断模块，用于根据预定判断原则对判断值进行判断得到判断结果；

所述获取权限模块，还用于根据判断结果获取提交任务的权限。

可选地，所述执行装置进一步包括：

所述确定模块，还用于按照根据所述数据库中任务数量生成对应数量子程序的方式确定子程序的数量。

本申请还提供了一种任务的执行装置，所述装置包括：处理器和存储器；

所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行所述的任务的执行方法的步骤。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现所述的任务的执行方法步骤。

如上可见，基于上述实施例，本申请的任务的执行方法通过每个子程序独立执行多个任务，使得多个任务在执行过程中相互独立。解决了在执行任务时由于任务之间的相互等待和关联，导致后续的任务无法执行，处于不可用的状态的技术问题。

附图说明

图1为一个实施例中任务的执行方法的流程示意图；

图2为另一个实施例中任务的执行方法的流程示意图；

图3为另一个实施例中任务的执行方法的流程示意图；

图4为另一个实施例中任务的执行方法的流程示意图；

图5为一个实施例中任务的执行方法的执行架构示意图；

图6为一个实施例中任务的执行装置的架构示意图；

图7为另一个实施例中任务的执行装置的架构示意图；

图8为另一个实施例中任务的执行装置的架构示意图；

图9为另一个实施例中任务的执行装置的架构示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明进一步详细说明。

图1为一个实施例中任务的执行方法的流程示意图。如图1所示，在一实施例中，本申请提供了一种任务的执行方法，该方法包括：

s101，接收用户发布的任务；

本步骤中首先接收用户发布的任务，此处所指的任务可以是用户发布的一项任务，也可以是用户发布的多项任务。

s102，将所述任务存储在预设的任务数据库中；

本步骤中的数据库用于存储用户发布的任务，为了更好的实现后续的步骤，数据库可以采用任务池的方式。任务池底层的服务者可以以插件化的方式实现任务的引入。任务池是业务层存储任务的组件，同时任务池是任务的容器。任务池只是构建任务数据库的一种具体形式，并不是对数据库具体方式的限定。任务池是本领域技术人员的惯用技术手段，关于任务池在此就不再进行赘述了。

s103，按照预定方式确定生成子程序的预定数量；

本步骤中需要确定生成子程序的数量，子程序生成的数量则需要按照预定方式确定。预定方式可以是设定一个额定数量，只要子程序的数量未满足额定数量，则不断的生成子程序。

s104，根据所述预定数量生成对应数量的子程序；

本步骤中通过上一步骤确定的子程序生成的预定数量生成相应数量的子程序。子程序的数量如果采用额定数量不断生成的方式，那么子程序减少时则应该补充相应数量的子程序，以使一直保持额定数量的子程序。

s105，每个子程序分别独立探测所述数据库中的任务；

本步骤中每一个子程序都会独立的去探测数据库中的任务。另外，在本步骤中子程序可以采用主动的方式对任务进行探测。

s106，子程序将探测发现的任务提交到对应的预置执行程序中进行执行。

当子程序发现数据库中存储有任务后，子程序就会将发现的任务提交到对应的预置执行程序中进行执行。需要指出的是子程序的执行步骤相互之间并不产生关联和影响，每一个子程序都是独立进行处理。

在本实施例中提供了一种任务的执行方法，首先建立一个任务数据库用于存储用户发布的一项或多项任务。用户可以发布待执行的多项任务，并且任务存储于数据库中。按照预定方式确定需要生成子程序的预定数量，预定方式可以设定一个额定数量，根据额定数量确定最终生成子程序的预定数量，之后根据预定数量不断的生成新的子程序。每个子程序都会对数据库中的任务进行独立的探测，当子程序探测到了数据库中的任务后，子程序就会提交该任务到预置的执行程序中进行执行。上述子程序的探测、发现、提交过程，每个子程序都会独立完成。如果多个子程序同时发现一个任务进行上述操作时，还会涉及子程序提交权限的问题。子程序的提交权限可以遵从先到先得的原则，即最先发现任务的子程序获得提交任务到预置的执行程序中的权限。上述的获取提交权限功能可以通过分布式锁进行权限设置。最后，子程序还会根据任务的属性参数分配给不同的执行程序去执行。分布式锁的权限获取和预置执行程序的分配在后文中会进行详细说明，在此就不在赘述了。在本实施例中子程序之间又不存在相互的关联或影响，因此当一个任务程序在执行时，其他任务程序不会处于等待、无法执行或者不可用的状态。

图2为一个实施例中任务的执行方法的流程示意图。如图2所示，在一实施例中，所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行步骤后，该方法还包括：

s201，判断所述任务在预置执行程序中的执行情况；

本步骤中根据任务的被执行情况进行判断。如果判断任务被成功执行，那么方法流程自然结束。

s202，如果任务执行失败，那么将所述任务发送回所述数据库，返回执行所述每个子程序分别独立探测所述数据库中的任务的步骤。

本步骤中如果任务判断为被执行失败，那么则将任务发送回数据库重新通过子程序再次提交任务，直到任务被成功执行一次。

本实施例中提供了在子程序提交任务执行失败的后续方法，首先要判断任务的执行情况。如果执行失败，那么将所述任务发送回数据库，然后循环子程序对任务的操作步骤，相当于对返回的任务进行一个幂等操作。简言之，就是不断的多次提交任务，直到任务被执行。

在具体应用过程中，如果提交的任务没有被执行，那么可以认为任务或者预置的执行程序出现了故障，工作人员会对故障进行排除。任务或者执行程序的故障排出后，由于任务在本实施例中会被不断的进行提交和执行，所以任务最终一定会被执行。

在一实施例中，所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行步骤前，该方法还包括：

s301，根据所述任务获取执行任务集市中对应的所述预置执行程序，其中，所述执行任务集市为执行任务的多项执行程序。

本步骤中提出了执行程序集市的概念，执行程序集市具有多项执行程序。可以根据数据库中存储的不同类型的任务，将任务根据不同类型分配给不同的对应匹配的执行程序执行，匹配的方式还可以通过任务具有唯一的标识和执行程序中对应的标识记录进行匹配。

图3为另一个实施例中任务的执行方法的流程示意图。如图3所示，在一实施例中，所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行步骤之前，该方法还包括：

s401，每个子程序获取任务的提交权限；

当多个子程序发现数据库中的同一项任务时，子程序之间由于独立提交任务，因此多个子程序之间存在提交权限的问题。因为实际操作中应该只有其中一个子程序可以进行提交操作。所以每一个子程序在提交前需要确认是否有提交任务的权限，以防止多个子程序同时执行提交操作。

s402，如果获取任务的提交权限成功，执行所述子程序将探测发现的任务提交到对应的预置执行程序中进行执行的步骤。

在本步骤中其中一个子程序确认获取了提交权限后，则执行提交任务的操作。在进行获取提交权限的多个子程序中，只会有一个子程序得到提交任务的权限。

本实施例是针对多个子程序发现同一任务的情况，每一个子程序都会去获取提交任务的权限，在发现上述同一任务的多个子程序中只会有一个子程序获得提交任务的权限并执行提交任务。另外，对于没有获得提交权限的子程序，放弃提交任务。

在一实施例中，所述获取任务的提交权限为通过分布式锁的方式获取任务的提交权限。

在本实施例中提供了一种对多个子程序分别获取提交权限的具体方式，每个子程序通过分布式锁的方式获取任务的权限。

图4为另一个实施例中任务的执行方法的流程示意图。如图4所示，在一实施例中，所述每个子程序通过分布式锁的方式获取提交任务的权限包括：

s501，对任务进行赋值得到具有初始赋值的任务；

本步骤中针对多个子程序获取了同一个任务后，由于每个子程序都独立的进行提交任务的操作，所以获取同一个任务的多个子程序之间会产生相互影响。对于第一个发现任务的子程序而言，首先要对任务进行赋值，任务会因此得到一个初始赋值。

s502，将赋值后的任务进行加锁；

在本步骤中对赋值后的任务进行加锁，加锁后的任务则不会被子程序执行提交操作。

s503，根据预定算法对任务的初始赋值进行计算得到任务的判断值；

在本步骤中，对初始赋值会根据预定算法进行计算得到一个判断值。预定算法可以根据具体的分布锁的判断逻辑进行设置。需要指出的是无论其他的子程序如果再通过预定算法进行计算，此时由于任务处于加锁状态，因此所有子程序都无法提交任务。

s504，对具有判断值的任务进行解锁；

本步骤对任务进行解锁，此时任务已经根据前面的步骤使任务具有了判断值。因此在本步骤中进行解锁以便之后的步骤中子程序可以提交任务。

s505，根据预定判断原则对判断值进行判断得到判断结果；

本步骤是根据判断值经过预定判断原则判断后得到的判断结果，此处的判断结果是否可以提交任务的依据。

s506，根据判断结果获取提交任务的权限。

本步骤的目的在于根据判断结果确定子程序是否可以获得提交任务的权限，如果子程序获得了提交任务的权限，那么子程序则会对任务进行提交。如果子程序未获得提交的权限，子程序则会放弃提交操作。

本实施例提供了一种分布式锁的具体实现方法。在多个子程序对同一任务分别进行独立的操作时，为了防止多个子程序之间的相互干扰，通过分布式锁的方式对子程序提供进行后续操作的权限。

在一实施例中，所述按照预定方式确定生成子程序的预定数量为按照根据所述数据库中任务数量生成对应数量子程序的方式确定子程序的数量。

在本实施例中，提供了一种具体的按照预定方式用于确定生成子程序的预定数量的方式。子程序的数量与数据库中任务的数量一致，可以尽可能的压低数据处理量，减小运算处理的负担。

基本原理与工作过程：

图5为一个实施例中任务的执行方法的执行架构示意图。如图5所示，为了更好的说明本申请的整体技术方案，以执行集群为例对本申请的技术方案做出进一步的说明。需要指出的是执行集群只是本申请的一个具体实施例，并不是对本申请技术方案的具体限定。

首先，接收用户发布的任务。此时接收的任务可以是一项或者是多项，为了更好实现之后的执行程序分配步骤，每一个任务可以具有一个唯一的标识(task_id，即任务的标识)用于对每一个任务进行标记，并且任务中可以说明任务类型(task_type，即任务的类型)，以及与任务相关的具体执行参数(task_params，即任务的执行参数)等信息。

随后，将任务存储在预设的任务数据库中。其中的数据库可以优选采用任务池的方式。因为任务池不但可以作为任务的容器，还具有可以以插件化的方式存储任务。

具体来说，任务池的组件可能是一个mysql服务，也可能是一个kafka服务。(mysql是一个关系型数据管理系统，kafka是一个开源流处理平台。)

mysql服务需要定时轮询所有的记录，查找当前状态可以执行的任务。这种方式可以在实时性不高的情况下延长轮询时间，降低系统负载。另外，客户使用简单的数据库编写就可以完成请求的发送。

kafka能够实时的接收客户发送的请求，整个过程几乎没有延迟，客户端需要使用kafka来发送请求。

上述的基础服务组件(即mysql服务和kafka服务)在正确配置后，任务池都能够在不需要用户感知的情况下完成消息的传递。

根据所述数据库中的按照预定方式确定生成子程序的预定数量，根据所述预定数量生成对应数量的子程序。以kubernetes为例，kubernetes是开源的docker容器集群管理系统。其中，docker即一个开源的应用容器引擎。集群管理系统为docker的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能。本申请的执行集群将执行平台部署成kubernetes上的服务，这样做主要两方面的优势：一方面，在一个docker宕机的时候其他docker依然可以接收任务并正常执行，实现了服务高可用。另一方面，可以实现任务执行的负载均衡，在任务执行密集的时候，可以分派到不同的dokcer上去执行，这样不会导致任务在一个docker阻塞的情况。本步骤中的子程序即为是上述的dokcer。

下面简单介绍一下kubernetes启动应用涉及的概念：

pod：pod是kubernetes调度的最小单位，是可以创建和部署的最简单的kubernetes对象。每个pod有自己的ip地址，本发明的任务就在一个pod上部署一份，一个pod可以运行一个或多个docker，优选一个pod上运行一个docker。

replicationcontroller：replicationcontroller能保证在任何时间一定会有指定数量的pod在运行，比如指定数量为3，就会一直有三个pod提供服务。换句话说，replicationcontroller保证了同构服务的运行和可用。

service：kubernetes中的服务是一个抽象对象，它定义了一组逻辑的pods和一个访问它们的策略，服务让互相依赖的pod之间的耦合松动，通过replicationcontroller控制运行的副本数量。

通过kubernetes搭建执行集群，通过指定replicationcontroller来控制能够同时执行通用任务的docker数量。每个执行服务接收到新的任务后，就会去获取提交权限确定是否可以执行，如果确定具备提交权限就执行提交任务准备进行执行，否则就放弃此次提交。

在每个子程序分别独立探测所述数据库中的任务的步骤中，根据上述执行集群的描述，可以理解为每个docker分别独立探测数据库中的任务。

子程序(即docker)将探测发现的任务提交到对应的预置执行程序中进行执行。如果多个docker发现了同一个执行程序，那么实际上每个docker都会去执行提交任务的步骤，docker的提交优先级顺序可以根据发现任务的先后顺序确定，当然也可以根据其他提交顺序进行执行。任务池中的任务会被执行集群的docker通过的主动方式(即pull的方式)进行读取。

如果docker将任务提交给对应预置执行程序后，预置执行程序对任务的执行失败，那么需要将任务发送回数据库或任务池，并返回执行每个docker分别独立探测数据库中的任务的步骤。不断循环重复提交，直到任务被成功执行。预置执行程序用于执行任务失败的原因在于任务或者预置执行程序出现故障，在排出故障后保证任务会因为不断循环执行，最终被预置执行程序成功执行。

另外，预置执行程序实际上可以是多项执行程序中的一项，换言之，可以创建一个执行任务集市，执行任务集市里面有执行数据库或任务池中任务的所有执行程序。根据任务的标识(task_id)、任务类型(task_type)，以及具体执行参数(task_params)分配给匹配的对应执行程序进行执行。

需要指出的是当多个docker对同一个任务需要进行提交时，除了上面提到的按照发现顺序进行提交外，还提供了一种docker通过分布锁获取提交权限的具体实施例。为了更好的对分布锁进行解释，以下通过具体算法对分布锁的执行步骤进行进一步的解释说明，第一步，对任务进行赋值得到具有初始赋值的任务，可以对未赋值的任务程序的标识(task_id)建立数据节点并对其进行赋值，设定其初始赋值为0。如果任务已经赋值则省略改步骤。第二步，将赋值后的任务进行加锁，此时所有的docker均不能提交任务。第三步，根据预定算法对任务的初始赋值进行计算得到任务的判断值。可以将预定算法设定为在初始赋值上加1，那么此时的判断值即为1。第四步，对具有判断值的任务进行解锁。此时docker已经可以提交任务，为后续的判断提交任务提供基础。第五步，根据预定判断原则对判断值进行判断得到判断结果。预定判断原则为当判断值是否大于1，不难发现，如果按照本实施例的具体分布式锁设定，判断值只会出现等于1或大于1的情况，如果等于1则可以获取提交权限，如果大于1则不具备提交权限。简言之，除了第一个docker能够获取提交权限，其他docker则无法获得提交权限。

图6为一个实施例中任务的执行装置的架构示意图。如图6所示，在一实施例中，本申请还提交了一种任务的执行装置，包括：

接收模块101，用于接收用户发布的任务；

存储模块102，用于将所述任务存储在预设的任务数据库中；

确定模块103，用于按照预定方式确定生成子程序的预定数量；

生成模块104，用于根据所述预定数量生成对应数量的子程序；

探测模块105，用于每个子程序分别独立探测所述数据库中的任务；

提交模块106，用于子程序将探测发现的任务提交到对应的预置执行程序中进行执行。

图7为一个实施例中任务的执行装置的架构示意图。如图7所示，在一实施例中，包括：

判断模块201，用于判断所述任务在预置执行程序中的执行情况；

发送模块202，用于如果任务执行失败，那么将所述任务发送回所述数据库，返回执行所述每个子程序分别独立探测所述数据库中的任务的步骤。

在一实施例中，包括：选择模块，用于根据所述任务选择执行任务集市中对应的所述预置执行程序，其中，所述执行任务集市为执行任务的多项执行程序。

图8为另一个实施例中任务的执行装置的架构示意图。如图8所示，在一实施例中，包括：

获取权限模块401，用于每个子程序获取任务的提交权限；

所述提交模块106，还用于如果获取任务的提交权限成功，执行所述将探测发现的任务提交到对应的预置执行程序中进行执行的步骤。

在一实施例中，该装置还包括：所述获取权限模块401，还用于每个子程序通过分布式锁的方式获取任务的权限。

图9为另一个实施例中任务的执行装置的架构示意图。如图9所示，在一实施例中，包括：

赋值模块501，用于对任务进行赋值得到具有初始赋值的任务；

加锁模块502，用于将赋值后的任务进行加锁；

计算模块503，用于根据预定算法对任务的初始赋值进行计算得到任务的判断值；

解锁模块504，用于对具有判断值的任务进行解锁；

判断模块505，用于根据预定判断原则对判断值进行判断得到判断结果；

所述获取权限模块401，还用于根据判断结果获取提交任务的权限。

可选地，所述执行装置进一步包括：

所述确定模块103，还用于按照根据所述数据库中任务数量生成对应数量子程序的方式确定子程序的数量。

本申请还提供了一种任务的执行装置，所述装置包括：处理器和存储器；

所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行所述的任务的执行方法的步骤。

在一实施例中，本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现所述的任务的执行方法步骤。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。