一种基于etcd集的分布式定时任务系统的设计方法

本发明属于定时任务系统领域，特别涉及一种基于etcd集的分布式定时任务系 统的设计方法。

定时任务系统是一种按照指定策略周期性执行任务的业务应用系统，是业务应用 系统中一个常见的组成部分，通常用于处理周期性的重复任务，定时任务系统被广泛应用 于数据同步、数据预处理等领域中。

传统的定时任务系统通常在一台主机上，通过crontab等工具来实现定时任务的 调度，但随着定时任务数量的增多，单机的处理能力已经成为定时任务处理能力的瓶颈，同 时，单机系统还存在单点故障的隐患。

将定时任务系统扩展到一个分布式集中是一种可行的改进的方法，但由于分布 式集实现起来非常复杂性，以至于分布式定时任务系统难以高效的开发，设计出的分布 式定时任务系统的稳定性和可靠性都难以保证。

本发明为了克服上述现有技术的不足，提供了一种基于etcd集的分布式定时任 务系统的设计方法，保证了开发的分布式定时任务系统的高效性。

为实现上述目的，本发明采用了以下技术措施：

一种基于etcd集的分布式定时任务系统的设计方法，包括以下步骤：

S1、根据业务需求准备定时任务的配置文件；

S2、定时任务配置服务将所述配置文件存入etcd集中的第一服务器，再由所述 etcd集将所述配置文件的存储路径传送至执行服务集中的第二服务器；

S3、所述第二服务器按照所述存储路径从第一服务器中读取配置文件，并应用所 述配置文件；

S4、需要更新配置文件时，直接用新的配置文件替换etcd集中的配置文件；

S5、所述第二服务器监听配置文件的更新；

S6、所述第二服务器申请执行定时任务；

S7、当所述第二服务器申请到定时任务时，开始执行所述定时任务，并更新定时任 务的申请状态至etcd集中，增加当前定时任务的描述信息至新的配置文件中；否则，重复 步骤S5。

步骤S5具体包括：

S51、所述第二服务器通过etcd集中的Watch API监听配置文件的更新；

S52、所述第二服务器应用新的配置文件配置自身，并重新调用所述Watch API继 续监听配置文件的变更。

步骤S6具体包括：

S61、当第二服务器判定时间条件满足定时任务的时间点时，所述第二服务器申请 执行定时任务；

S62、通过etcd集中的checkAndSet API检测所述定时任务是否已被其它第二服 务器申请；

S63、若所述定时任务已被申请，则定时任务申请失败，否则，定时申请成功。

优选的，所述配置文件为全局的配置文件，所述定时任务的配置信息均保存在配 置文件中。

优选的，所述配置文件的格式为yaml格式。

进一步的，所述配置文件通过RESTful接口存入etcd集中的第一服务器。

进一步的，所述存储路径为/crontab/config.yaml路径。

进一步的，所述描述信息包括所述第二服务器的编号、第二服务器所在主机名称、 第二服务器的网络地址、第二服务器的端口号、定时任务的进程号、以及定时任务的启动时 间。

更进一步的，所述第一服务器设置为多个，两个所述第一服务器之间彼此双向通 信连接。

更进一步的，每一个所述第一服务器可对应多个所述第二服务器。

本发明的有益效果在于：

1)、本发明的执行服务集中的第二服务器通过共享同一个配置文件，采用竞争 方式来完成一个定时任务，对于不同的定时任务，可以根据业务需求随时更新配置文件，并 且直接用新的配置文件替换etcd集中的配置文件，避免了配置文件逐一更新第二服务器 的繁琐，保证了第二服务器读取到的配置文件的一致性，因此本发明保证了开发的分布式 定时任务系统的高效性。

2)、所述第一服务器设置为多个，两个所述第一服务器之间彼此双向通信连接，保 证了etcd集中的第一服务器能够同时同步地读取到配置文件；所述第二服务器按照所述 存储路径从第一服务器中读取配置文件，并应用所述配置文件，有效的保证了读取配置文 件的一致性。

3)、所述第二服务器通过etcd集中的Watch API监听配置文件的更新，所述第二 服务器应用新的配置文件配置自身，并重新调用所述Watch API继续监听配置文件的变更， 确保在配置文件更新后，第二服务器能够及时准确的变更自身的配置文件，使设计出的分 布式定时任务系统具备更高的准确性和可靠性。

图1为本发明的系统架构图；

图2为本发明的系统配置时序图。

图中的附图标记含义如下：

10—定时任务配置服务 20—etcd集 30—执行服务集

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

如图1所示，从系统架构角度来看，分布式定时任务系统主要由3部分组成，包括定 时任务配置服务10、etcd集20、执行服务集30，它们分别用于系统的配置以及系统配置 更新、存储系统配置以及定时任务状态、按照系统的配置内容执行定时任务。

如图1、2所示，从系统架构和功能实现两个方面来讨论分布式定时任务系统的设 计实现。

S1、根据业务需求准备定时任务的配置文件；

所述配置文件用来描述分布式定时任务系统需要执行的定时任务的细节，所述配 置文件中至少包含一个定时任务列表，每一条任务包括任务名称、crontab格式的定时任务 描述等，配置文件格式可以为yaml格式、json格式、xml格式等，优选使用yaml格式。

为了更好的理解配置文件，表1为一个简化的配置文件，其中定义了两个定时任 务。任务一的名称为mytask1，每隔1小时执行一次mycommand1；任务二的名称为mytask2,每 天固定01:00时执行mycommand2。

表1：

S2、定时任务配置服务10将所述配置文件存入etcd集20中的第一服务器，由所 述etcd集20将所述配置文件的存储路径传送至执行服务集30中的第二服务器，所述存 储路径为/crontab/config.yaml路径。

S3、所述第二服务器按照/crontab/config.yaml路径从第一服务器中读取配置文 件，并应用所述配置文件。

如上述的配置文件，将在系统中创建两个定时任务。

S4、可以根据业务需求随时更新配置文件，需要更新配置文件时，直接用新的配置 文件替换etcd集20中的配置文件。

S5、所述第二服务器监听配置文件的更新；

所述第二服务器通过etcd集20中的Watch API监听配置文件的更新；所述第二 服务器应用新的配置文件配置自身，并重新调用所述Watch API继续监听配置文件的变更， 确保了在配置文件更新后，第二服务器能够及时准确的变更自身的配置文件。

S6、执行服务申请执行定时任务；

所述第二服务器根据所述配置文件中的每个定时任务的时间点向etcd集20申 请执行定时任务，当第二服务器执行所述定时任务的时间条件满足定时任务的时间点时， 所述第二服务器申请执行定时任务，通过etcd集20中的checkAndSet API检测所述定时 任务是否已被其它第二服务器申请，若所述定时任务已被申请，则定时任务申请失败，否 则，定时申请成功。

如任务一mytask1在2015年11月13日14:00时的任务，文件路径即为/crontab/ mytask1/2015-11-13-14-00，根据etcd集20的特性可以保证只有一个第二服务器会返回 成功的结果。

当某一个第二服务器的负载较高时，可以考虑在步骤S2前，等待一段时间，这样可 以让负载以较低的第二服务器优先申请到任务。

S7、当所述第二服务器申请到定时任务时，开始执行所述定时任务，并更新定时任 务的申请状态至etcd集10中，增加当前定时任务的描述信息至新的配置文件中；否则，重 复步骤S5。

所述描述信息包括所述第二服务器的编号、第二服务器所在主机名称、第二服务 器的网络地址、第二服务器的端口号、定时任务的进程号、以及定时任务的启动时间。

进一步，所述第一服务器设置为多个，两个所述第一服务器之间彼此双向通信连 接，且所述第一服务器之间的数据进行同步更新，即为在一个所述第一服务器取得所述配 置文件的同时，其他所述第一服务器也同步取得配置文件的数据。

更进一步的，每一个所述第一服务器可对应多个所述第二服务器。