CN106445651A - 执行任务的方法及系统 - Google Patents

Abstract

本发明提供一种处理任务的方法及系统，有利于解决数据库压力问题和单点问题。其中，处理任务的方法，包括：业务中心创建多个任务，任务分为预设类型任务和其他类型任务；业务中心将预设类型任务发送到任务驱动引擎中，任务驱动引擎为多线程并发任务调度框架；多个工作节点各自执行从任务驱动引擎中获取到的预设类型任务；业务中心将其他类型任务发送到数据库的任务表中；多个工作节点各自执行从数据库的任务表中获取到的其他类型任务。

Description

执行任务的方法及系统

技术领域

本发明涉及互联网技术领域，具体涉及一种执行任务的方法及系统。

背景技术

中国的彩民数量逐年增长，随着互联网的发展，越来越多的彩民选择在互联网平台进行购彩。网络出票中心是整个网络彩票系统的核心，它负责整个网络彩票系统的投注、出票流程。因为购彩是一种有时效性的活动，所以网络出票中心需要在截止时间前为用户完成下单和出票。而在购彩高峰期，瞬间的下单量十分巨大。面对巨大的访问量，如何保证系统的高可用性是一个关键问题。同时随着数据量的增加，如何水平扩展并降低维护成本也是另外一个关键问题。

现有的解决海量数据的方案为：通过分库分表(Sharding)在数据存储层实现伸缩，来降低数据库的压力。具体地，将原来单一数据库按照一定的规则进行切分，把数据分散到多台物理机上存储，从而突破单机限制。这种切分对上层应用来说是透明的，多个物理上分布的数据库在逻辑上依然是一个库。但是，该方案具有如下的缺点：

a.数据库压力问题

所有的任务都存在数据库中，会有几十个任务调度定时的访问数据库，数据库会频繁的输入输出。随着任务量的逐渐增加，数据库压力很大，稳定性差。

b.单点问题

在高并发的环境下，会存在重复下单、重复投注的问题，造成不必要的经济损失。

发明内容

有鉴于此，本发明提供一种处理任务的方法及系统，有助于解决数据库压力问题和单点问题。本发明的其他目的和有益效果可从具体实施方式中得出。

为实现上述目的，根据本发明的一个方面，提供了一种处理任务的方法，包括：业务中心创建多个任务，所述任务分为预设类型任务和其他类型任务；所述业务中心将所述预设类型任务发送到任务驱动引擎中，所述任务驱动引擎为多线程并发任务调度框架；多个工作节点各自执行从所述任务驱动引擎中获取到的所述预设类型任务；所述业务中心将所述其他类型任务发送到数据库的任务表中；所述多个工作节点各自执行从所述数据库的任务表中获取到的所述其他类型任务。

可选地，在所述工作节点执行从所述任务驱动引擎中获取到的预设类型任务失败的情况下，所述方法还包括：所述工作节点重新从所述任务驱动引擎中获取相应的所述预设类型任务并执行；所述任务驱动引擎将累计失败次数加1，然后判断所述累计失败次数是否超过阀值，若是，则将执行失败的预设类型任务从任务队列中消费，并且将一个与执行失败的预设类型任务相同的预设类型任务插入所述任务队列的队尾。

可选地，还包括：所述业务中心将所述预设类型任务发送到所述数据库的任务表中；在所述任务驱动引擎故障的情况下，所述多个工作节点各自执行从所述数据库的任务表中获取到的预设类型任务。

为实现上述目的，根据本发明的另一方面，提供了一种处理任务的系统，其特征在于，包括：业务中心、任务驱动引擎、数据库以及多个工作节点，其中，所述业务中心用于创建多个任务，所述任务分为预设类型任务和其他类型任务，用于将所述预设类型任务发送到所述任务驱动引擎中，以及用于将所述其他类型任务发送到所述数据库的任务表中；所述任务驱动引擎为多线程并发任务调度框架；所述多个工作节点用于各自执行从所述任务驱动引擎中获取到的所述预设类型任务，以及用于各自执行从所述数据库的任务表中获取到的所述其他类型任务。

可选地，所述工作节点还用于在所述工作节点执行从所述任务驱动引擎中获取到的预设类型任务失败的情况下，重新从所述任务驱动引擎中获取相应的所述预设类型任务并执行；所述任务驱动引擎还用于当所述工作节点执行从所述任务驱动引擎中获取到的相应的所述预设类型任务失败时，将累计失败次数加1，然后判断所述累计失败次数是否超过阀值，若是，则将执行失败的预设类型任务从任务队列中消费，重新将一个与执行失败的预设类型任务相同的预设类型任务插入所述任务队列的队尾。

可选地，所述业务中心还用于将所述预设类型任务发送到所述数据库的任务表中；所述多个工作节点还用于在所述任务驱动引擎故障的情况下，各自执行从所述数据库的任务表中获取到的预设类型任务。

根据本发明的技术方案，通过引入任务驱动引擎，一方面可以将分布式高并发的预设类型任务从数据库的任务表中剥离出来，减轻了数据库的压力，另一方面任务驱动引擎本身能够将若干个并发的任务变为任务队列，解决了单点问题。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的执行任务的方法的主要步骤的示意图。

图2是根据本发明实施例的执行任务的系统的主要部件的示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的执行任务的方法的主要步骤的示意图。如图1所示，该方法主要包括如下的步骤S11至步骤S15。

步骤S11：业务中心创建多个任务。其中，任务分为预设类型任务和其他类型任务两类。

为使本发明被更好地理解，下面结合网络购彩情景来举例说明。业务中心通常是指网销彩票服务商系统后台，相当于服务端。预设类型任务通常是指具有分布式、高并发的特点的任务，这些任务如果按照传统方式交给数据库来处理，会给数据库带来很大压力。预设类型任务具体包括哪些任务这是由人工预先确定的。在网络购彩情景中预设类型任务可以包括彩票投注任务、彩票出票任务等等任务。在其他情景中预设类型任务可以是话费充值任务、秒杀下单任务等等任务。所有任务中去除预设类型任务，剩下的就是其他类型任务，具体地可以是用户登录认证任务、支付任务等等任务。

步骤S12：业务中心将预设类型任务发送到任务驱动引擎中，其中，任务驱动引擎为多线程并发任务调度框架。

例如，任务驱动引擎可以为基于Redis和MongoDB实现的多线程并发任务调度框架，该设置的任务驱动引擎具有技术成熟，简单易行，通用性强等优点。任务驱动引擎可以理解为数据库的缓存层。任务驱动引擎能够对任务进行时序上的安排调整，将并发的多个任务变成顺序执行的任务队列。需要说明的是，BasePopTasksHandler和BasePushTaskManager是任务驱动引擎处理任务的抽象类，需要集成它们来实现任务的插入(push)和取出(pop)，可以通过模板模式来实现。为了方便后续业务扩展，定义TaskTypeExecutor接口，从任务驱动引擎pop消息实现该接口即可。

步骤S13：多个工作节点各自执行从任务驱动引擎中获取到的预设类型任务。

多个节点是指分布在地理上不同位置的多个客户端，它们是执行各种任务的主体。例如多个彩民购彩应用APP，它们可以执行彩票投注任务；又例如多个彩票代理商出票应用APP，它们可以执行彩票出票任务。

步骤S14：业务中心将其他类型任务发送到数据库的任务表中。

需要说明的是，步骤S14不一定要在步骤S12和步骤S13之后执行，只需要在步骤S11之后执行即可。

步骤S15：多个工作节点各自执行从数据库的任务表中获取到的其他类型任务。

需要说明的是，步骤S15不一定要在步骤S12和步骤S13之后执行，只需要在步骤S14之后执行即可。

由上可知，本发明实施例的处理任务方法通过集成任务驱动引擎实现队列任务，第一方面，将分布式高并发的预设类型任务从数据库中剥离出来，缓解数据库压力的同时也提高了系统性能；第二方面，通过引入任务驱动引擎任务可以使预设类型任务严格按照队列执行，避免并发任务带来的故障，解决了单点问题。因此，本发明实施例的处理任务方法具有处理效率高，简便易行，稳定健壮等优点。

实际应用中由于各种原因，工作节点执行从任务驱动引擎中获取到的相应的预设类型任务时有可能会失败。传统技术中任务驱动引擎通常对于执行失败的任务有失败次数限制，超过一定阈值(例如50次)将被放入失败队列，等待预设时长(例如20分钟)之后才会被执行。这对一些有时限要求的任务来说，这样的流程是不符合要求的。以网络购彩情景为例，如果彩票投注任务或彩票出票任务被放入失败队列，当下次被执行时，可能已经超过了投注、出票截止时间，造成下单失败。针对于此，在本发明的实施方式中，当工作节点执行从任务驱动引擎中获取到的相应的预设类型任务失败时，还可以包括如下步骤S16和步骤S17(图1中未示出)：

步骤S16：工作节点重新从任务驱动引擎中获取相应的预设类型任务并执行。

步骤S17：任务驱动引擎将累计失败次数加1，然后判断累计失败次数是否超过阀值，若累计失败次数超过阈值，则执行以下步骤：任务驱动引擎将累计失败次数清零；任务驱动引擎将执行失败的预设类型任务从任务队列中消费，并重新将一个相同的预设类型任务请求插入任务队列的队尾。

该实施方式中，当一个任务执行失败次数超过阈值时，通过立即取消当前任务并且重新向任务驱动引擎推送一个相同任务，这样就能够保证工作节点几乎不间断地尝试执行任务，直到任务成功执行为止，维护了流程的正常运行。

传统的执行分布式任务技术方案中，还会遇到水平扩展问题以及分布式管理一致性问题。具体地：在系统运行一段时间后，数据就会积累到超过承载上限，此时就需要对数据库进行扩容，也就是增加新的物理节点来分摊数据。如果是根据ID进行路由，那么就需要重新计算数据进行迁移。如果是按照增量区进行路由，也就是近期系统的读写都集中在新节点上，就会有“热点”问题，从而影响性能。面对这种两难的处境，Sharding扩容显得异常困难。另外，如果要修改分布式节点中的相关配置，如果分布式节点数目众多时，维护起来人力成本巨大且容易出错。针对于此，在本发明的实施方式中，工作节点可以基于zookeeper实现，集成curator框架，这样可以实现统一的分布式节点配置管理。

ZooKeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。根据Zookeeper的结构特性，分布式配置以组的形式体现，分组也使得水平扩展更加容易，我们可以根据实际需求随时增减组，也可以增减组内服务器数量。组对象可以由HostGroup类实现，通过Spring注入分组信息。每个组是独立的，每个组的配置信息存储目录为：/zookeeper根路径/组名，在系统中通过CacheConfigureImpl来实现。Curator框架提供了监听接口PathChildrenCacheListener，该接口可以监听节点的变化，可以根据需求实现该接口，例如修改线程池队列大小，修改任务执行频率等。只要一个节点变化，其它节点都会同步更新。

当系统启动时，会将Zookeeper的配置缓存到本地，当工作节点与Zookeeper连接不通时，读取本地缓存，为了保证本地缓存能与Zookeeper服务端配置一致，可以启动一个线程定时检查Zookeeper是否有变化，如果有变化就同步本地缓存，该功能实现类为LocalConfigureManagerImpl。

由上可知，基于Zookeeper的监听机制可以很容易的扩展业务，只需实现监听接口，当一个节点变化时，就能保证其它节点同步变化。分布式配置可以保证分布式节点的同步变化，分组的实现使得系统的水平扩展更加容易，不仅降低了部署成本和维护成本，而且也降低了出错率。

在本发明的实施方式中，还可以包括以下的步骤S18和步骤S19(图1中未示出)。

步骤S18：业务中心将所有预设类型任务发送到数据库的任务表中。

需要说明的是，步骤S18位于步骤S11之后。将步骤S18联合上文中的步骤S14来理解，业务中心将所有的任务都发送到了数据库的任务表中。

步骤S19：当任务驱动引擎故障时，多个工作节点各自执行从数据库的任务表中获取到的相应的所述预设类型任务。

具体地，当任务驱动引擎故障时，工作节点中的zookeeper开关开启降级模式，工作节点跳过任务驱动引擎直接访问所述数据库的任务表执行预设类型任务。

上述实施方式中，引入降级模式为流程的稳定运行提供了双重保证，也增加了方法的可靠性和健壮性。

图2是根据本发明实施例的执行任务的系统的主要部件的示意图。如图2所示，该执行任务的系统20包括：业务中心21、任务驱动引擎22、数据库23以及多个工作节点24。

业务中心21用于创建多个任务，任务分为预设类型任务和其他类型任务。业务中心21还用于将所有预设类型任务发送到任务驱动引擎22中，以及用于将所有其他类型任务发送到数据库23的任务表中。

任务驱动引擎22为多线程并发任务调度框架。例如：任务驱动引擎为基于Redis和MongoDB实现的多线程并发任务调度框架。该设置的任务驱动引擎具有技术成熟，简单易行，通用性强等优点。

多个工作节点24用于各自执行从任务驱动引擎中获取到的预设类型任务，以及用于各自执行从数据库的任务表中获取到的其他类型任务。

由上可知，本发明实施例的处理任务系统通过集成任务驱动引擎实现队列任务，第一方面，将分布式高并发的预设类型任务从数据库中剥离出来，缓解数据库压力的同时也提高了系统性能；第二方面，通过引入任务驱动引擎任务可以使预设类型任务严格按照队列执行，避免并发任务带来的故障，解决了单点问题。因此，本发明实施例的处理任务系统具有处理效率高，简便易行，稳定健壮等优点。

在本发明的实施方式中，工作节点24还可用于：当工作节点24执行从任务驱动引擎22中获取到的相应的预设类型任务失败时，重新从任务驱动引擎22中获取相应的预设类型任务并执行。任务驱动引擎22还可用于：当工作节点执行从任务驱动引擎22中获取到的相应的预设类型任务失败时，将累计失败次数加1，然后判断累计失败次数是否超过阀值，若累计失败次数超过阈值，则将累计失败次数清零，将执行失败的预设类型任务从任务队列中消费，重新将一个相同的预设类型任务请求插入任务队列的队尾。该实施方式中，当一个任务执行失败次数超过阈值时，通过立即取消当前任务并且重新向任务驱动引擎推送一个相同任务，这样就能够保证工作节点几乎不间断地尝试执行任务，直到任务成功执行为止，维护了流程的正常运行。

在本发明的实施方式中，工作节点可以基于zookeeper实现，集成curator框架，这样可以实现统一的分布式节点配置管理。基于Zookeeper的监听机制可以很容易的扩展业务，只需实现监听接口，当一个节点变化时，就能保证其它节点同步变化。分布式配置可以保证分布式节点的同步变化，分组的实现使得系统的水平扩展更加容易，不仅降低了部署成本和维护成本，而且也降低了出错率。

在本发明的实施方式中，业务中心21还可用于将所有预设类型任务发送到数据库23的任务表中；以及多个工作节点24还可用于当任务驱动引擎22故障时，各自执行从数据库23的任务表中获取到的相应的预设类型任务。该实施方式中，引入降级模式为流程的稳定运行提供了双重保证，也增加了方法的可靠性和健壮性。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (6)

1.一种处理任务的方法，其特征在于，包括：

业务中心创建多个任务，所述任务分为预设类型任务和其他类型任务；

所述业务中心将所述预设类型任务发送到任务驱动引擎中，所述任务驱动引擎为多线程并发任务调度框架；

多个工作节点各自执行从所述任务驱动引擎中获取到的所述预设类型任务；

所述业务中心将所述其他类型任务发送到数据库的任务表中；

所述多个工作节点各自执行从所述数据库的任务表中获取到的所述其他类型任务。

2.如权利要求1所述的处理任务的方法，其特征在于，在所述工作节点执行从所述任务驱动引擎中获取到的预设类型任务失败的情况下，所述方法还包括：

所述工作节点重新从所述任务驱动引擎中获取相应的所述预设类型任务并执行；

所述任务驱动引擎将累计失败次数加1，然后判断所述累计失败次数是否超过阀值，若是，则将执行失败的预设类型任务从任务队列中消费，并且将一个与执行失败的预设类型任务相同的预设类型任务插入所述任务队列的队尾。

3.如权利要求1所述的处理任务的方法，其特征在于，还包括：

所述业务中心将所述预设类型任务发送到所述数据库的任务表中；

在所述任务驱动引擎故障的情况下，所述多个工作节点各自执行从所述数据库的任务表中获取到的预设类型任务。

4.一种处理任务的系统，其特征在于，包括：业务中心、任务驱动引擎、数据库以及多个工作节点，其中，

所述业务中心用于创建多个任务，所述任务分为预设类型任务和其他类型任务，用于将所述预设类型任务发送到所述任务驱动引擎中，以及用于将所述其他类型任务发送到所述数据库的任务表中；

所述任务驱动引擎为多线程并发任务调度框架；

所述多个工作节点用于各自执行从所述任务驱动引擎中获取到的所述预设类型任务，以及用于各自执行从所述数据库的任务表中获取到的所述其他类型任务。

5.如权利要求4所述的处理任务的系统，其特征在于，

所述工作节点还用于在所述工作节点执行从所述任务驱动引擎中获取到的预设类型任务失败的情况下，重新从所述任务驱动引擎中获取相应的所述预设类型任务并执行；

所述任务驱动引擎还用于当所述工作节点执行从所述任务驱动引擎中获取到的相应的所述预设类型任务失败时，将累计失败次数加1，然后判断所述累计失败次数是否超过阀值，若是，则将执行失败的预设类型任务从任务队列中消费，重新将一个与执行失败的预设类型任务相同的预设类型任务插入所述任务队列的队尾。

6.如权利要求5所述的处理任务的系统，其特征在于，

所述业务中心还用于将所述预设类型任务发送到所述数据库的任务表中；

所述多个工作节点还用于在所述任务驱动引擎故障的情况下，各自执行从所述数据库的任务表中获取到的预设类型任务。