CN111666134A

CN111666134A - 一种分布式任务调度的方法和***

Info

Publication number: CN111666134A
Application number: CN201910163677.XA
Authority: CN
Inventors: 廖耀华
Original assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Current assignee: Beijing Jingdong Century Trading Co Ltd; Beijing Jingdong Shangke Information Technology Co Ltd
Priority date: 2019-03-05
Filing date: 2019-03-05
Publication date: 2020-09-15

Abstract

本发明公开了分布式任务调度方法和***，涉及计算机技术领域。该方法的一具体实施方式包括：接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求；在数据库中查询所述任务锁定对象；响应于查询到所述任务锁定对象，将记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号；接收第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号；响应于确定所述第一版本号与所述特定版本号相同，对所述数据库执行第一更新；以及当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件。该实施方式提高了分布式***的可靠性并降低了方案部署复杂性。

Description

一种分布式任务调度的方法和***

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式任务调度的方法和***。

背景技术

现有的分布式任务调度方案比较多，常用的是通过Redis方案或者Zookeeper方案获取分布式锁，来解决对多主机多任务处理的调度问题。分布式锁具有排他性，在同一时间只会有一个进程能获取到锁并执行任务，其它进程无法同时获取。当任务执行完毕后该进程释放锁，但是计算机不是100％可靠，因此会出现释放锁失败的问题。

通过Redis方案获取分布式锁是目前使用最多的技术，基本原理就是多个线程通过Redis方案的原子操作获取锁，其中只有一个线程会拿到锁。在这种方案下对释放锁失败的问题一般的解决思路是设置Redis键的过期时间，这样即使释放锁失败，也可以到期释放锁，但对键的过期时间设置为多长不好界定。而通过Zookeeper方案获取分布式锁是通过使用它的临时有序节点来实现的，这种方式部署相对麻烦，生产环境中使用的比较少。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

(1)Redis方案中对键的过期时间设置不妥便会导致锁失效的问题，但多长时间是合适的又不好界定。

(2)Zookeeper方案由于强依赖Zookeeper因而分布式***的可靠性不能保证并且Zookeeper方案部署相对麻烦。

因此，现行的解决方案下分布式***中锁失效的问题没有得到很好的解决，进而使得分布式***的可靠性难以保证。

发明内容

有鉴于此，本发明实施例提供一种分布式任务调度的方法和***，能够通过使用数据库乐观锁取代传统的Redis方案，因此不需要设置过期时间，避免了对键的过期时间设置不妥便会导致锁失效的问题，并且通过在使用乐观锁的基础上采用Zookeeper作为辅助检查方案，避免了直接采用Zookeeper方案带来的部署困难问题，并且不会强依赖Zookeeper。而且能够在避免了现有方案的问题的同时，还能很好地解决了分布式任务调度中的锁失效问题。

为实现上述目的，根据本发明实施例的一个方面，提供了一种分布式任务调度的方法。

根据本发明实施例的分布式任务调度的方法，包括：

接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求；

在数据库中查询所述任务锁定对象；

响应于查询到所述任务锁定对象，从所述数据库读取与所述任务锁定对象相关的记录并将所述记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号；

接收来自所述一个或多个服务器中的第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号；

响应于确定所述第一版本号与所述特定版本号相同，使用所述第一更新数据对所述数据库执行第一更新；以及

当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件，其中，所述第一服务器和所述第二服务器相同或不同。

可选地，在接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求之前还包括：

创建与检查服务器相对应的父节点；以及

在所述父节点下创建与所述一个或多个服务器相对应的一个或多个子节点，其中所述父节点在列表中维护其下当前存活的所有子节点。

可选地，所述一个或多个子节点是其所对应的所述一个或多个服务器的IP地址列表。

可选地，所述父节点和所述一个或多个子节点是EPHEMERAL类型节点。

可选地，使得所述一个或多个服务器中的其他服务器触发监听事件进一步包括：

从所述列表中删除与所述第二服务器相对应的第二子节点得到新的列表；

向所述新的列表中的子节点发送所述新的列表；

接收来自与所述新的列表中的子节点相对应的服务器的锁查询请求，其中所述锁查询请求是关于所述第二子节点是否持有未释放的锁；

根据所述锁查询请求对所述数据库进行查询；以及

响应于查询到所述第二子节点持有未释放的锁，释放所述锁，其中所述锁是针对所述任务的乐观锁。

可选地，当所述第二子节点持有未释放的锁时，所述任务的任务锁定状态为1。

可选地，释放所述锁进一步包括：将所述任务的任务锁定状态置为0。

接收所述一个或多个服务器的IP地址；

根据所述IP地址在数据库中查询任务锁定状态为1的任务；以及

响应于查询到所述任务锁定状态为1的所述任务，将所述任务的所述任务锁定状态置为0。

可选地，在在数据库中查询所述任务锁定对象之后还包括：

响应于没有查询到所述任务锁定对象，向所述数据库写入与所述任务锁定对象相关的记录。

可选地，其中，所述记录至少包括以下字段：任务类型字段、任务描述字段、任务锁定状态字段和版本号字段。

根据本发明实施例的另一个方面，提供了一种分布式任务调度的***。

根据本发明实施例的分布式任务调度的***，包括：

查询请求接收模块，用于接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求；

锁定对象查询模块，用于在数据库中查询所述任务锁定对象；

锁定对象处理模块，用于响应于查询到所述任务锁定对象，从所述数据库读取与所述任务锁定对象相关的记录并将所述记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号；

更新接收模块，用于接收来自所述一个或多个服务器中的第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号；

更新执行模块，用于响应于确定所述第一版本号与所述特定版本号相同，使用所述第一更新数据对所述数据库执行第一更新；以及

辅助检查模块，用于当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件，其中，所述第一服务器和所述第二服务器相同或不同。

可选地，所述辅助检查模块进一步用于：

创建与检查服务器相对应的父节点；以及

可选地，所述辅助检查模块进一步用于：

向所述新的列表中的子节点发送所述新的列表；

根据所述锁查询请求对所述数据库进行查询；以及

可选地，所述辅助检查模块进一步用于：将所述任务的任务锁定状态置为0。

可选地，所述***进一步包括：

服务器启动模块，用于接收所述一个或多个服务器的IP地址；

可选地，所述锁定对象处理模块进一步用于：

可选地，所述记录至少包括以下字段：任务类型字段、任务描述字段、任务锁定状态字段和版本号字段。

根据本发明实施例的另一个方面，提供了分布式任务调度电子设备。

根据本发明实施例的分布式任务调度电子设备，包括：

一种分布式任务调度电子设备，其特征在于，包括：

一个或多个处理器；

存储***，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本发明实施例第一方面提供的分布式任务调度的方法。

根据本发明实施例的再一个方面，提供了一种计算机可读介质。

根据本发明实施例的计算机可读介质，其上存储有计算机程序，该程序被处理器执行时实现本发明实施例第一方面提供的分布式任务调度的方法。

上述发明中的一个实施例具有如下优点或有益效果：因为采用数据库乐观锁在分布式***中进行任务调度同时使用Zookeeper进行辅助检查的技术手段，所以克服了键的过期时间设置不妥便会导致的锁失效以及强依赖zookeeper的技术问题，进而达到提高了分布式***的可靠性并降低了方案部署复杂性的技术效果。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

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

图1是根据本发明实施例的分布式任务调度的方法的主要流程的示意图；

图2是根据本发明实施例的一个示例性Docker启动阶段的示例流程示意图；

图3是根据本发明实施例的一个示例性任务执行阶段的示例流程示意图；

图4是根据本发明实施例的一个示例性程序检查阶段的示例流程示意图；

图5是根据本发明实施例的一个示例性Zookeeper检查阶段的示例流程示意图；

图6是根据本发明实施例的另一个分布式任务调度的方法的主要流程的示意图；

图7是根据本发明实施例的分布式任务调度的***的主要模块的示意图；

图8是本发明实施例可以应用于其中的示例性***架构图；

图9是适于用来实现本发明实施例的终端设备或服务器的计算机***的结构示意图。

具体实施方式

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

图1是根据本发明实施例的分布式任务调度的方法的主要流程的示意图，如图1所示，根据本发明实施例的分布式任务调度的方法包括步骤S101、S102、S103、S104、S105和S106。

步骤S101：接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求。

本方案采用数据库的乐观锁，来通过Docker执行程序释放。步骤S101至步骤S105是乐观锁方案的正常执行流程。在本文中，术语“Docker”指的是服务器，例如Linux服务器，执行方法的代码程序可以部署在Docker上面，贯穿本文所使用的术语“服务器”可以与“Docker”互换使用而不影响方案实施以及技术效果。

本技术方案可以分两个阶段：(1)正常执行阶段；(2)辅助检查阶段。正常执行阶段包括Docker启动阶段和任务执行阶段。辅助检查阶段包括程序检查和Zookeeper检查。其中，Docker启动阶段可以在任务执行阶段中的每个服务器重启时完成，主要目的是解决在Docker还持有未释放的锁的情况下经历了重启所导致的锁无法释放的问题，进一步提高了分布式***的可靠性。Zookeeper检查主要解决任务执行阶段中Docker宕机所导致的锁无法释放的问题。而程序检查会定时运行，可以每隔10分钟检查一次，和正常执行阶段同步开始，主要解决任务执行阶段中当任务执行完毕需要释放乐观锁但释放失败的问题。

在正常执行阶段阶段，当任务在执行中时，不会释放数据库的乐观锁直到任务执行完毕。但是我们因为有新需求上线不得不重新启动Docker容器(这是经常遇到的事情)，当Docker容器重新启动后，数据库的乐观锁就不会再释放了。因此我们增加了Docker启动的处理逻辑，主要解决数据库的乐观锁不会释放的问题，当Docker容器启动后会自动执行***，释放本机持有的数据库乐观锁。

优选地，在接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求(步骤S101)之前还包括：

接收所述一个或多个服务器的IP地址；

下面结合附图2描述一个示例性Docker启动阶段的主要步骤。

图2是根据本发明实施例的一个示例性Docker启动阶段的示例流程示意图，如图2所示，根据本发明实施例的一个示例性Docker启动阶段200包括步骤S201、S202、S203、S204和S205。

步骤S201：Docker启动开始。

在一个实施例中，Docker启动开始包括Docker应用程序启动，Web容器初始化，执行任务锁释放***。

步骤S202：执行任务锁释放***。

在一个实施例中，任务锁释放***获取本机IP地址，通过IP地址查询数据库中是否存在处于锁定中的任务，即数据库中的锁定状态是1的任务。

步骤S203：检查是否有本机锁定的任务。

步骤S204：释放锁。

如果存在锁定中的任务(步骤S203处为“是”)，则释放任务的锁，将数据库中任务的锁定状态设置为0。如果不存在(步骤S203处为“否”)，则不做任何操作，跳到步骤步骤S205。

步骤S205：Docker启动完成。

Docker启动阶段解决了重启Docker时会引起的乐观所无法释放的问题，增强了分布式***的可靠性。在一些实施例中，在步骤S101之前也可以不包括Docker启动阶段。

步骤S102：在数据库中查询所述任务锁定对象。

如果有Docker想要执行一个任务，第一步先要查询该任务是否被其他Docker锁定。因此，在步骤S101中接收到来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求之后，将在数据库中查询所述任务锁定对象以确定该任务目前是否被其他服务器锁定。

在一个实施例中，Docker应用程序通过任务类型查询任务锁定对象。

步骤S103：响应于查询到所述任务锁定对象，从所述数据库读取与所述任务锁定对象相关的记录并将所述记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号。

优选地，在在数据库中查询所述任务锁定对象之后还包括：

在一个实施例中，如果任务锁定对象为null，说明数据库中没有保存这个类型的任务，于是往数据库中***一条记录，字段包括：任务类型(int)、任务描述(varchar)、任务锁定状态(int，值为0，表示任务还没有锁定)，版本号(long，值为1)。之后获取本机IP。

在一个实施例中，如果任务锁定对象不为null，则从任务锁定对象中获取任务锁定状态，如果任务锁定状态的值为1(说明该任务已经锁定)，则流程结束。如果任务锁定状态的值为0(说明该任务未锁定)，则获取本机IP。

步骤S104：接收来自所述一个或多个服务器中的第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号。

只有在Docker确定该任务没有被锁定的情况下才会执行该任务，同时可能有多个Docker确认了该任务没有被锁定并且想要执行该任务。乐观锁机制其实就是在数据库表中引入一个版本号(version)字段来实现的。当我们要从数据库中读取数据的时候，同时把这个version字段也读出来，如果要对读出来的数据进行更新后写回数据库，则需要将version加1，同时将新的数据与新的version更新到数据表中，且必须在更新的时候同时检查目前数据库里version值是不是之前的那个version，如果是，则正常更新。如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了。

因此，每个Docker应用程序开始更新数据库中该任务数据，更新条件包括：任务类型、任务锁定状态(值为0)、版本号(如果从第2步过来，值为1；如果从第3步过来，可以从锁定对象中获取)。更新字段包括：任务锁定状态(更新为1)、版本号(在原版本号基础上加1)、本机IP地址、更新时间(当前时间)。基于数据库乐观锁，只会有一个Docker应用程序可以修改成功。

步骤S105：响应于确定所述第一版本号与所述特定版本号相同，使用所述第一更新数据对所述数据库执行第一更新。

在这种情况下，步骤S104中就是接收到了多个想要执行任务的服务器中最早完成更新数据的服务器，使得其成功取得乐观锁并完成更新。

如上文所提到的，正常执行阶段包括Docker启动阶段和任务执行阶段。一般在多个Docker中的每一个开机时都会经历Docker启动阶段，在每个Docker开机后就进入了该Docker的任务执行阶段。在一个实施例中，在Docker的任务执行阶段，当任务达到可执行点的时候，多个Docker容器会同时去执行这个任务，这时所有的Docker都会去抢数据库这把乐观锁，只有抢到乐观锁的Docker可以执行任务。

下面结合附图3描述一个示例性任务执行阶段的主要步骤。

图3是根据本发明实施例的一个示例性任务执行阶段的示例流程示意图，如图3所示，根据本发明实施例的一个示例性任务执行阶段300包括步骤S301、S302、S303、S304、S305、S306和S307。

步骤S301：一个或多个Docker准备执行任务。

在一个实施例中，步骤S301可进一步包括与所述一个或多个Docker相对应的子步骤S301_1至步骤S301_N，分别表示Docker_1至Docker_N准备执行任务的步骤。

如果任务锁定对象为null，说明数据库中没有保存这个类型的任务，于是往数据库中***一条记录，字段包括：任务类型(int)、任务描述(varchar)、任务锁定状态(int，值为0，表示任务还没有锁定)，版本号(long，值为1)。然后获取本机的IP地址。

如果任务锁定对象不为null，则从任务锁定对象中获取任务锁定状态，如果任务锁定状态的值为1(说明该任务已经锁定)，则流程结束。如果任务锁定状态的值为0(说明该任务未锁定)，则获取本机的IP地址。

步骤S302：所述一个或多个Docker通过任务号和版本号获取数据库乐观锁。

每个Docker应用程序开始更新数据库中该任务数据，更新条件包括：任务类型、任务锁定状态(值为0)、版本号(如果步骤S301中发现任务锁定对象为null，值为1；如果步骤S301中发现任务锁定对象不为null，可以从锁定对象中获取)。更新字段包括：任务锁定状态(更新为1)、版本号(在原版本号基础上加1)、本机IP地址、更新时间(当前时间)。

步骤S303：所述一个或多个Docker中的一个Docker成功获取乐观锁。

基于数据库乐观锁，只会有一个Docker应用程序可以修改成功。

步骤S304：获取到乐观锁的Docker开始执行任务。

获取到乐观锁的Docker应用程序开始执行任务，当任务执行完毕后，释放锁，释放锁的操作就是把任务锁定状态更新为0。

步骤S305：获取到乐观锁的Docker执行任务完毕并释放乐观锁。

步骤S306：乐观锁释放成功。

步骤S307：乐观锁释放失败，发送告警邮件。

在步骤S305中，数据库不可能100％可靠，因此存在释放乐观锁失败的问题，除此之外，Docker服务器宕机也会导致释放乐观锁失败，项目上线的时候，如果任务正在执行，也会导致释放乐观锁失败。如果乐观锁释放失败，需要增加人为干预的环节。当释放乐观锁失败时，会发送报警邮件和短信，及时通知开发人员手动释放乐观锁。

如上文所述，辅助检查阶段包括程序检查和Zookeeper检查。在任务正常执行的过程中，不可能保证服务100％可靠，因此增加了辅助检查阶段。辅助检查阶段包括两类检查，一类是程序检查，一类是Zookeeper检查。程序检查主要是解决任务在执行过程中中断的问题，和上述任务执行阶段的步骤S307有点类似，但是处理的时间节点不一样，任务执行阶段的步骤S307处于任务已经执行完毕，但是释放乐观锁出现问题，这时可以直接人工干预释放乐观锁。但是程序检查主要是针对任务在执行过程中出现了问题导致任务中断。

下面结合附图4描述一个示例性程序检查阶段的主要步骤。

图4是根据本发明实施例的一个示例性程序检查阶段的示例流程示意图，如图4所示，根据本发明实施例的一个示例性程序检查阶段400包括步骤S401、S402、S403和S404。

步骤S401：检查程序启动。

在一个实施例中，检查程序启动后从任务表里面获取执行中的任务对象。

步骤S402：获取任务对乐观锁的持有时间。

在一个实施例中，用当前时间减去任务获取到乐观锁的时间，得到当前任务持有乐观锁的时间。

步骤S403：确定所述持有时间是否超过30分钟。

在其他实施例中，30分钟这个值可以配置，根据任务执行长短配置，一般配置为所有任务中执行时间最长的那个任务持有乐观锁的时间，因此一般情况下不会触发该条件，除非程序确实出现问题。

步骤S404：确定所述持有时间超过30分钟，发送告警邮件和短信。

如果任务持有乐观锁的时间超过30分钟，则发送告警邮件和短信。开发人员收到告警信息后，检查任务是否已经中断，如果中断则手动释放乐观锁，如果任务还在继续执行，则忽略。

步骤S106：当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件，其中，所述第一服务器和所述第二服务器相同或不同。

步骤S106是和步骤S101至步骤S105描述的乐观锁方案的正常执行流程同步的Zookeeper检查。

在使用数据库乐观锁来对分布式***进行调度时，如果周期性任务(例如，每隔1个小时执行一次)正在执行，那么数据库中该任务已经被锁定，其它执行任务的Docker服务器无法执行该任务。如果当该任务执行到一半时，执行该任务的Docker突然宕机，那么数据库中该任务的锁无法释放，如果不采取措施释放该锁，这个任务以后都不会再执行(本来是每隔1个小时执行一次的)。本文中所提供的Zookeeper检查就是在解决Docker宕机所引起的锁无法释放的问题。在一个实施例中，这里的“释放”动作是由其中的某个Docker完成的。

Zookeeper检查主要解决Docker宕机的问题。例如，如果Docker_1正在执行任务A，这时Docker1宕机，但是任务A还没有正常结束，那么任务A持有的乐观锁不会释放，当Docker_2执行任务A时，发现任务A的锁没有释放，则放弃执行任务A，这样任务A永远也不会执行。

优选地，在接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求之前还包括：

创建与检查服务器相对应的父节点；以及

优选地，使得所述一个或多个服务器中的其他服务器触发监听事件进一步包括：

向所述新的列表中的子节点发送所述新的列表；

根据所述锁查询请求对所述数据库进行查询；以及

下面结合附图5描述一个示例性Zookeeper检查阶段的主要步骤。

图5是根据本发明实施例的一个示例性Zookeeper检查阶段的示例流程示意图，如图5所示，根据本发明实施例的一个示例性Zookeeper检查阶段500包括步骤S501、S502、S503、S504、S505、S506和S507。

步骤S501：Zookeeper检测一个或多个Docker的心跳。

所有执行任务的Docker注册Zookeeper。注册逻辑如下：首先在Zookeeper服务端创建一个节点/SERVERS，接着每个Docker在启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如Docker_1创建/SERVERS/${Docker_1的IP}，Docker_2创建/SERVERS/${Docker_2的IP}，然后Docker_1、Docker_2、.......、Docker_n都watch/SERVERS这个父节点。EPHEMERAL类型节点有一个很重要的特性，就是客户端和Zookeeper服务端连接断掉就会使节点消失，那么当某一个Docker宕机的时候，其对应的节点就会消失，然后集群中所有对/SERVERS进行watch的客户端都会收到通知。

步骤S502：发现所述一个或多个Docker中有Docker宕机。

步骤S503：仍存活的Docker执行watcher监视器。

如果Docker_1宕机，则其它Docker(除了Docker_1)会触发监听事件，执行如下操作：首先获取/SERVERS节点下面的所有子节点(所有存活Docker的IP列表)，因为Docker_1宕机，则/SERVERS节点下面的所有子节点不包含Docker_1的IP，于是跟上次的IP列表比较可以得到Docker_1的IP。

步骤S504：仍存活的Docker检查宕机的Docker是否持有锁。

步骤S505：响应于确定宕机的Docker持有特定任务的锁，则释放该锁。

其它Docker拿到Docker_1的IP后，从数据库中查询Docker_1尚未执行完的任务(即Docker_1还持有任务的乐观锁没有释放，但是Docker_1已经宕机了，永远也不可能释放乐观锁)，将Docker_1持有任务的乐观锁释放掉。

在本申请中的术语具有其通用含义。乐观锁机制采取了更加宽松的加锁机制。大多是基于数据版本Version记录机制实现。术语“Zookeeper”是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致***的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。术语“Docker”是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

本发明采用数据库乐观锁技术和Zookeeper完成分布式任务调度，在任务获取锁阶段通过数据库乐观锁来保证每个任务在同一时刻只会分配给一个线程，当任务执行完毕后再释放锁，因为数据库的可靠性和易用性，该方案实现简单且可靠，但是存在一个问题，当Docker出现故障后，任务获取的锁无法释放，这时，我们会通过Zookeeper检测Docker心跳，当Docker宕机后，Zookeeper会检测到宕机的Docker并执行watcher监视器来释放锁。本方案中，当Docker发生故障时，由Zookeeper完成锁的释放，Zookeeper在整个过程中只是作为一种辅助装备，并没有强依赖Zookeeper，解决了Redis锁失效的问题和Zookeeper的可靠性问题。在一些实施方式中，本申请的实施方式也可应用于悲观锁。

图6是根据本发明实施例的另一个分布式任务调度的方法的主要流程的示意图，如图6所示，根据本发明实施例的另一个分布式任务调度的方法包括步骤S601、S602、S603、S604、S605、S606、S607、S608、S609和S610。

步骤S601：创建与检查服务器相对应的父节点。

步骤S602：在所述父节点下创建与所述一个或多个服务器相对应的一个或多个子节点，其中所述父节点在列表中维护其下当前存活的所有子节点。

步骤S603：接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求。

步骤S604：在数据库中查询所述任务锁定对象。

步骤S605：响应于没有查询到所述任务锁定对象，向所述数据库写入与所述任务锁定对象相关的记录。

步骤S606：响应于查询到所述任务锁定对象，从所述数据库读取与所述任务锁定对象相关的记录并将所述记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号。

步骤S607：接收来自所述一个或多个服务器中的第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号。

步骤S608：响应于确定所述第一版本号与所述特定版本号不同，向所述第一服务器发通知。

步骤S609：响应于确定所述第一版本号与所述特定版本号相同，使用所述第一更新数据对所述数据库执行第一更新。

步骤S610：当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件，其中，所述第一服务器和所述第二服务器相同或不同。

向所述新的列表中的子节点发送所述新的列表；

根据所述锁查询请求对所述数据库进行查询；以及

图7是根据本发明实施例的分布式任务调度的***的主要模块的示意图，如图7所示，根据本发明实施例的分布式任务调度的***700包括：

查询请求接收模块701，用于接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求。

锁定对象查询模块702，用于在数据库中查询所述任务锁定对象。

锁定对象处理模块703，用于响应于查询到所述任务锁定对象，从所述数据库读取与所述任务锁定对象相关的记录并将所述记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号。

更新接收模块704，用于接收来自所述一个或多个服务器中的第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号。

更新执行模块705，用于响应于确定所述第一版本号与所述特定版本号相同，使用所述第一更新数据对所述数据库执行第一更新。

辅助检查模块706，用于当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件，其中，所述第一服务器和所述第二服务器相同或不同。

可选地，所述辅助检查模块706进一步用于：

创建与检查服务器相对应的父节点；以及

可选地，其中，所述一个或多个子节点是其所对应的所述一个或多个服务器的IP地址列表。

可选地，其中，所述父节点和所述一个或多个子节点是EPHEMERAL类型节点。

可选地，所述辅助检查模块706进一步用于：

向所述新的列表中的子节点发送所述新的列表；

根据所述锁查询请求对所述数据库进行查询；以及

可选地，其中，当所述第二子节点持有未释放的锁时，所述任务的任务锁定状态为1。

可选地，所述分布式任务调度的***700进一步包括：

服务器启动模块707，用于接收所述一个或多个服务器的IP地址；

可选地，所述锁定对象处理模块703进一步用于：

图8示出了可以应用本发明实施例的分布式任务调度方法或分布式任务调度***的示例性***架构800。

如图8所示，***架构800可以包括终端设备801、802、803，网络804和服务器805。网络804用以在终端设备801、802、803和服务器805之间提供通信链路的介质。网络804可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备801、802、803通过网络804与服务器805交互，以接收或发送消息等。终端设备801、802、803上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备801、802、803可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器805可以是提供各种服务的服务器，例如对用户利用终端设备801、802、803所浏览的购物类网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的产品信息查询请求等数据进行分析等处理，并将处理结果(例如目标推送信息、产品信息--仅为示例)反馈给终端设备。

需要说明的是，本发明实施例所提供的分布式任务调度方法一般由服务器805执行，相应地，分布式任务调度***一般设置于服务器805中。

应该理解，图8中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

下面参考图9，其示出了适于用来实现本发明实施例的终端设备的计算机***900的结构示意图。图9示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图9所示，计算机***900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有***900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本发明的***中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的***、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括查询请求接收模块、锁定对象查询模块、锁定对象处理模块、更新接收模块、更新执行模块和辅助检查模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，锁定对象查询模块还可以被描述为“用于在数据库中查询所述任务锁定对象的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求；在数据库中查询所述任务锁定对象；响应于查询到所述任务锁定对象，从所述数据库读取与所述任务锁定对象相关的记录并将所述记录发送到所述一个或多个服务器，所述记录包括任务锁定状态和特定版本号；接收来自所述一个或多个服务器中的第一服务器的对所述任务的第一更新数据，所述第一更新数据包括第一版本号；响应于确定所述第一版本号与所述特定版本号相同，使用所述第一更新数据对所述数据库执行第一更新；以及当所述一个或多个服务器中的第二服务器发生错误事件时，使得所述一个或多个服务器中的其他服务器触发监听事件，其中，所述第一服务器和所述第二服务器相同或不同。

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

Claims

1.一种分布式任务调度的方法，其特征在于，包括：

在数据库中查询所述任务锁定对象；

2.根据权利要求1所述的方法，其特征在于，其中，在接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求之前还包括：

创建与检查服务器相对应的父节点；以及

3.根据权利要求2所述的方法，其特征在于，其中，所述一个或多个子节点是其所对应的所述一个或多个服务器的IP地址列表。

4.根据权利要求2所述的方法，其特征在于，其中，所述父节点和所述一个或多个子节点是EPHEMERAL类型节点。

5.根据权利要求2所述的方法，其特征在于，其中，使得所述一个或多个服务器中的其他服务器触发监听事件进一步包括：

向所述新的列表中的子节点发送所述新的列表；

根据所述锁查询请求对所述数据库进行查询；以及

6.根据权利要求5所述的方法，其特征在于，其中，当所述第二子节点持有未释放的锁时，所述任务的任务锁定状态为1。

7.根据权利要求5所述的方法，其特征在于，其中，释放所述锁进一步包括：将所述任务的任务锁定状态置为0。

8.根据权利要求1所述的方法，其特征在于，其中，在接收来自一个或多个服务器对任务的任务锁定对象的一个或多个查询请求之前还包括：

接收所述一个或多个服务器的IP地址；

9.根据权利要求1所述的方法，其特征在于，其中，在在数据库中查询所述任务锁定对象之后还包括：

10.根据权利要求1或9所述的方法，其特征在于，其中，所述记录至少包括以下字段：任务类型字段、任务描述字段、任务锁定状态字段和版本号字段。

11.一种分布式任务调度的***，其特征在于，包括：

12.根据权利要求11所述的***，其特征在于，其中，所述辅助检查模块进一步用于：

创建与检查服务器相对应的父节点；以及

13.根据权利要求12所述的***，其特征在于，其中，所述一个或多个子节点是其所对应的所述一个或多个服务器的IP地址列表。

14.根据权利要求12所述的***，其特征在于，其中，所述父节点和所述一个或多个子节点是EPHEMERAL类型节点。

15.根据权利要求12所述的***，其特征在于，所述辅助检查模块进一步用于：

向所述新的列表中的子节点发送所述新的列表；

根据所述锁查询请求对所述数据库进行查询；以及

16.根据权利要求15所述的***，其特征在于，其中，当所述第二子节点持有未释放的锁时，所述任务的任务锁定状态为1。

17.根据权利要求15所述的***，其特征在于，其中，所述辅助检查模块进一步用于：将所述任务的任务锁定状态置为0。

18.根据权利要求11所述的***，其特征在于，所述***进一步包括：

19.根据权利要求11所述的***，其特征在于，所述锁定对象处理模块进一步用于：

20.根据权利要求11或19所述的***，其特征在于，其中，所述记录至少包括以下字段：任务类型字段、任务描述字段、任务锁定状态字段和版本号字段。

21.一种分布式任务调度电子设备，其特征在于，包括：

一个或多个处理器；

存储***，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-10中任一所述的方法。

22.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-10中任一所述的方法。