一种定时任务执行方法、服务端、客户端及存储介质

技术领域

本申请涉及计算机技术，尤其涉及一种定时任务执行方法、服务端、客户端及存储介质。

背景技术

随着云计算技术的发展，微服务架构被越来越多地部署应用在云中。微服务架构，就是把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，本质上是用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

在微服务架构中，常常要定时执行一些任务。比如，订单系统的超时状态判断、缓存数据的定时更新、定时给用户发短信，甚至是一些定期计算的报表等等。

然而，在部署定时任务时，如果部署多台设备执行定时任务，则会将一个任务重复执行；如果只部署一台设备执行定时任务，则在设备出现延迟或其他问题时，可能造成定时任务执行的遗漏。

发明内容

本申请实施例期望提出一种定时任务执行方法、服务端、客户端及存储介质，能够以简单的系统架构对定时任务不重复不遗漏地执行。

本申请的技术方案是这样实现的：

本申请实施例提供一种定时任务执行方法，所述方法包括：

接收并储存定时任务信息；

基于所述定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令；

若所述第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中，确定第二执行服务器；所述心跳回应时间为所述第一执行服务器回应所述至少一个同步服务器的心跳信号的时间；

基于所述定时任务信息，通过所述第二执行服务器向所述目标客户端定时发送第二定时任务指令。

上述方案中，在所述接收并储存定时任务信息之前，所述方法还包括：

将初始服务器确定为所述第一执行服务器；所述初始服务器为所述服务端中最先启动的服务器。

上述方案中，所述若所述第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中，确定第二执行服务器，包括：

若所述第一执行服务器的心跳回应时间超过阈值，则在所述至少一个同步服务器中进行选举，以确定所述第二执行服务器。

上述方案中，所述在所述至少一个同步服务器中进行选举，以确定所述第二执行服务器，包括：

将所述至少一个同步服务器作为至少一个待选服务器；

所述至少一个待选服务器中的每个待选服务器对所述至少一个待选服务器中的任一待选服务器进行投票；

若所述至少一个待选服务器中的任一待选服务器得票数超过阈值，则将所述任一待选服务器确定为所述第二执行服务器。

上述方案中，在所述基于所述定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令之后，所述方法还包括：

接收定时任务执行状态信息；所述定时任务执行状态信息表征所述目标客户端执行定时任务的状态。

上述方案中，在所述接收并储存定时任务信息之后，所述方法还包括：

将所述定时任务信息同步到所述至少一个同步服务器上。

上述方案中，在所述基于所述定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令之前，所述方法还包括：

通过负载均衡算法在客户端集群中确定所述目标客户端；所述客户端集群包括至少一个客户端。

本申请实施例还提供一种定时任务执行方法，所述方法包括：

接收定时任务指令；所述定时任务指令包括：第一定时任务指令或第二定时任务指令；所述第一定时任务指令通过第一执行服务器定时发送；所述第二定时任务指令通过第二执行服务器定时发送；

基于所述定时任务指令执行对应的定时任务，得到对应的定时任务执行状态信息；

向服务端发送所述定时任务执行状态信息。

上述方案中，在所述接收定时任务指令之前，所述方法还包括：

向所述服务端发送定时任务信息；所述服务端基于所述定时任务信息定时发送所述第一定时任务指令或所述第二定时任务指令。

本申请实施例还提供一种服务端，包括：

服务端接收单元，用于接收并储存定时任务信息；

服务端发送单元，用于基于所述定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令；

确定单元，用于若所述第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中，确定第二执行服务器；所述心跳回应时间为所述第一执行服务器回应所述至少一个同步服务器的心跳信号的时间；

所述服务端发送单元，还用于基于所述定时任务信息，通过所述第二执行服务器向所述目标客户端定时发送第二定时任务指令。

本申请实施例还提供一种客户端，包括：

客户端接收单元，用于接收定时任务指令；所述定时任务指令包括：第一定时任务指令或第二定时任务指令；所述第一定时任务指令通过第一执行服务器定时发送；所述第二定时任务指令通过第二执行服务器定时发送；

执行单元，用于基于所述定时任务指令执行对应的定时任务，得到对应的定时任务执行状态信息；

客户端发送单元，用于向服务端发送所述定时任务执行状态信息。

本申请实施例还提供一种服务端，包括：

服务端存储器，用于存储可执行指令；

服务端处理器，用于执行所述服务端存储器中存储的可执行指令时，实现上述方案中的定时任务执行方法。

本申请实施例还提供一种客户端，包括：

客户端存储器，用于存储可执行指令；

客户端处理器，用于执行所述客户端存储器中存储的可执行指令时，实现上述方案中的定时任务执行方法。

本申请实施例还提供一种存储介质，存储有可执行指令，用于引起服务端处理器或客户端处理器执行时，实现上述方案中的定时任务执行方法。

由此可见，本申请提供了一种定时任务执行方法、服务端、客户端及存储介质，能够在接收定时任务信息后，基于定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令；而若第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中，确定第二执行服务器，再通过第二执行服务器向目标客户端定时发送第二定时任务指令，以保证定时任务的顺利执行。这样，仅通过服务端内部的集群，便保证了每一时刻都有一台执行服务器向目标客户端定时发送指令，不会因多台执行服务器执行同一定时任务而造成重复，也不会因某一执行服务器故障而造成遗漏，从而，能够以简单的系统架构对定时任务不重复不遗漏地执行。

附图说明

图1为本申请实施例提供的一种定时任务执行方法的架构示意图一；

图2为本申请实施例提供的一种定时任务执行方法的架构示意图二；

图3为本申请实施例提供的一种定时任务执行方法的流程图一；

图4为本申请实施例提供的一种定时任务执行方法的流程图二；

图5为本申请实施例提供的一种定时任务执行方法的流程图三；

图6为本申请实施例提供的一种定时任务执行方法的流程图四；

图7为本申请实施例提供的一种定时任务执行方法的流程图五；

图8为本申请实施例提供的一种定时任务执行方法的流程图六；

图9为本申请实施例提供的一种定时任务执行方法的流程图七；

图10为本申请实施例提供的一种定时任务执行方法的流程图八；

图11为本申请实施例提供的一种定时任务执行方法的流程图九；

图12为本申请实施例提供的一种服务端的结构示意图一；

图13为本申请实施例提供的一种客户端的结构示意图一；

图14为本申请实施例提供的一种服务端的结构示意图二；

图15为本申请实施例提供的一种客户端的结构示意图二。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和实施例对本申请的技术方案进一步详细阐述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

如果发明文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

为了保证定时任务不重复不遗漏的执行，可以采用分布式定时任务调度。分布式定时任务调度具有高可用性，能解决定时任务在集群部署情况下的协调调度问题，保证任务不重复不遗漏的执行。然而，在微服务架构中，要实现分布式定时任务调度，往往需要另外部署独立的服务，无法实现统一配置，统一管理。例如，

方案1：基于中间件作为发送中心，然后调度系统获取定时任务列表，执行定时任务。该方案是中心化的实现方案，如果发送中心出现故障无法保证高可用，而且需要更多的资源。

方案2：基于长连接实现服务端和客户端的交互，执行定时任务。该方案的服务端不是集群方案，服务端无法实现高可用。

方案3：在每个微服务中嵌套定时任务。该方案无法做到统一管理、配置和监控等，不是高可用方案。

上述方案均存在不同维度的缺陷。

图1为本申请实施例提供的定时任务执行方法的一个可选的架构示意图，如图1所示，服务端01中包括服务端：执行服务器011以及同步服务器012、013；客户端集群02中包括至少一个客户端：目标客户端021以及其他客户端022、023。服务端01中同一时刻只有执行服务器011和客户端集群02进行交互。执行服务器011可以接收客户端集群02中任一客户端发送的定时任务信息，但执行服务器011同一时刻只向目标客户端021发送定时任务执行指令。同步服务器012和013会向执行服务器011进行数据同步。

可以理解的是，与方案1相比，服务端01自身实现了集群化方案，客户端集群02直接与服务端01交互，不依赖与第三方发送中心，可以实现去中心化；与方案2相比，服务端01和客户端集群02都可以实现集群部署，不会因个别设备出现问题而导致定时任务执行受阻，实现了高可用性；与方案3相比，执行服务器011同一时刻只向目标客户端021发送定时任务执行指令，这样，在同一时刻，定时任务只被执行一次，避免定时任务被重复执行，保证了执行的一致性。

需要说明的是，服务端01中同步服务器的数目、以及客户端集群02中其他客户端的数目不局限于图1所示出的数目。在图1的基础上可以增加或减少同步服务器的数目和其他客户端的数目，仍属于本申请保护的范围。

客户端集群02与服务端01的交互、以及执行服务器011与同步服务器012、013的交互，可以使用Netty作为通信框架。

图2为本申请实施例提供的定时任务执行方法的另一个可选的架构示意图，如图2所示，服务端01中包括多个进程工具软件包：客户端包031、核心包032、通信包033、集群包034和负载均衡包035。其中：

客户端包031，包括了客户端集群02所需要的SDK(Software Developme nt Kit，软件开发工具包)，用于实现客户端集群02与执行服务器011的心跳连接、定时任务信息发送、任务执行交互、参数配置等；其中，定时任务信息中包括：执行时间、任务说明、任务执行参数、任务执行方法(可以是Http接口)、任务返回值等。

核心包032，用于服务端01发布执行定时任务的核心内容；核心包032中包括了定时任务功能，并且内部也实现了定时任务动态信息的配置等特性；

通信包033，用于执行服务器011和同步服务器012、013之间的通信；通信包033中包括了通信方式、协议、序列化方式等信息的定义；

集群包034，用于实现服务端01的集群方案；

负载均衡包035，用于实现服务端01向客户端集群02发送指令的负载均衡策略。

客户端包031、核心包032、通信包033、集群包034和负载均衡包035可以采用.jar格式的数据包。客户端包031可以采用schedule-client.jar包；核心包032可以采用schedule-core.jar包；通信包033可以采用schedule-net.jar包；集群包034可以采用schedule-cluster.jar包；负载均衡包035可以采用schedule-ba lance.jar包。

图3是本申请实施例提供的定时任务执行方法的一个可选的流程示意图，将结合图3示出的步骤进行说明。

S101、接收并储存定时任务信息。

本申请实施例中，服务端01可以接收并储存客户端集群02所发送的定时任务信息。

在本申请实施例中，参考图1，客户端集群02中的任一客户端可以引用服务端01中的客户端包031，以配置服务端01的地址，从而在启动的时候，发送定时任务信息给服务端01中当时的执行服务器011。执行服务器011接收并储存定时任务信息，并且将定时任务信息同步给同步服务器012和013(数据同步)，从而，保证了服务端01中定时任务信息的一致性。

S102、基于定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令。

本申请实施例中，定时任务信息中包括了执行时间、任务说明、任务执行参数、任务执行方法、任务返回值等定时任务的相关信息。服务端01在接收到定时任务信息后，可以基于定时任务信息，通过第一执行服务器向目标客户端021定时发送第一定时任务指令。

在本申请实施例中，服务端01启动时通过集群包034实现集群化，集群化后的服务端01中的服务器可以有三种身份：执行服务器、同步服务器和待选服务器。其中，只有执行服务器可以与客户端集群02进行数据交互；同步服务器会向执行服务器进行数据同步；服务端01在所有待选服务器中确定执行服务器。

在本申请实施例中，服务端01可以将初始服务器确定为第一执行服务器，其中，初始服务器为服务端中最先启动的服务器。例如，服务端01启动时，服务器A、B、C同时开始启动，服务器A最先启动完成，则服务器A被确定为第一执行服务器，并向服务器B、C发送心跳请求以进行告知；服务器B、C在收到服务器A发送的心跳请求后转换身份为同步服务器，开始向服务器A同步相关数据以及相关状态信息。

在本申请实施例中，服务端01将初始服务器确定为第一执行服务器后，还向客户端集群02中的每个客户端进行链接确认，若每个客户端中存在链接确认失败的异常客户端，则剔除异常客户端在服务端的信息。

S103、若第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中，确定第二执行服务器；心跳回应时间为第一执行服务器回应至少一同步服务器的心跳信号的时间。

本申请实施例中，服务端01中的每个服务器之间基于心跳信号进行通信。服务端01中每个服务器之间基于心跳信号来完成状态确认、数据同步请求等过程。服务端01若判定第一执行服务器的心跳回应时间超过阈值，则在除第一执行服务器外的至少一个同步服务器中，确定第二执行服务器。至少一个同步服务器会定时向第一执行服务器发送心跳信号，心跳回应时间是第一执行服务器回应至少一个同步服务器的心跳信号的时间。例如，服务器A为第一执行服务器，服务端01中还包括服务器B、C等同步服务器，服务器A和服务器B、C之间可以发送心跳信号。当服务器B、C向服务器A发送了心跳信号后，服务器A会对该心跳信号进行回应。若服务器A回应心跳信号的时间超过了阈值，则服务端01可以判定服务器A状态异常，并在服务器B、C中确定第二执行服务器来保证和目标客户端021的交互。

在本申请实施例中，服务端01可以在至少一个同步服务器中进行选举，以确定第二执行服务器。例如，作为第一执行服务器的服务器A被判定状态异常后，服务器B、C的身份由同步服务器转变为待选服务器，服务器B、C拥有了投票和选举的权利。当服务器B、C中的任一待选服务器获得了一半以上的票数，则服务端01将该服务器确定为第二执行服务器，第二执行服务器为新的执行服务器011。服务器A在状态恢复正常后，则身份由执行服务器转变为同步服务器，与第二执行服务器进行数据同步。

在本申请实施例中，服务端01确定第二执行服务器后，还向客户端集群02中的每个客户端进行链接确认，若客户端集群02中存在链接确认失败的异常客户端，则剔除异常客户端在服务端的信息。

S104、基于定时任务信息，通过第二执行服务器向目标客户端定时发送第二定时任务指令。

本申请实施例中，服务端01在确定了第二执行服务器为新的执行服务器011后，可以基于定时任务信息，通过第二执行服务器向目标客户端定时发送第二定时任务指令。

可以理解的是，在第一执行服务器状态异常时，服务端01在内部的集群中确定第二执行服务器来与目标客户端021交互，保证了任一时刻有一台执行服务器向目标客户端定时发送定时任务指令，从而，能够以简单的系统架构对定时任务不重复不遗漏地执行。

在本申请的一些实施例中，在图3示出的S101前还包括图4示出的S201，将结合各步骤进行说明。

S201、将初始服务器确定为第一执行服务器；初始服务器为服务端中最先启动的服务器。

本申请实施例中，服务端01可以在所有服务器进行启动时，将初始服务器确定为第一执行服务器，其中，初始服务器为服务端中最先启动的服务器。

可以理解的是，将初始服务器确定为第一执行服务器，保证了任一时刻有一台执行服务器向目标客户端定时发送指令，从而，对定时任务不遗漏地执行。

在本申请的一些实施例中，可以通过图5示出的S1031来实现图3示出的S103，将结合各步骤进行说明。

S1031、若第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中进行选举，以确定第二执行服务器。

本申请实施例中，服务端01可以在至少一个同步服务器中进行选举，以确定第二执行服务器作为新的执行服务器011。例如，作为第一执行服务器的服务器A被判定状态异常后，服务器B、C的身份由同步服务器转变为待选服务器，服务器B、C拥有了投票和选举的权利。当服务器B、C中的任一待选服务器获得了一半以上的票数，则服务端01将该服务器确定为第二执行服务器，第二执行服务器为新的执行服务器011。服务器A在状态恢复正常后，则身份由执行服务器转变为同步服务器，与第二执行服务器进行数据同步。

可以理解的是，在第一执行服务器状态异常时，服务端01在内部的集群中确定第二执行服务器来与目标客户端021交互，保证了任一时刻有一台执行服务器向目标客户端定时发送定时任务指令，从而，能够以简单的系统架构对定时任务不重复不遗漏地执行。

在本申请的一些实施例中，可以通过S1032-S1034来实现图5示出的S1031，将结合各步骤进行说明。

S1032、将至少一个同步服务器作为至少一个待选服务器。

本申请实施例中，服务端01在至少一个同步服务器中进行的选举，可以先将至少一个同步服务器进行身份转换，以作为至少一个待选服务器，从而拥有了投票和选举的权利。

S1033、至少一个待选服务器中的每个待选服务器对至少一个待选服务器中的任一待选服务器进行投票。

本申请实施例中，服务端01可以使每个待选服务器对任一待选服务器进行投票。其中，每个待选服务器可以对自己进行投票，也可以对其他待选服务器进行投票。

S1034、若至少一个待选服务器中的任一待选服务器得票数超过阈值，则将任一待选服务器确定为第二执行服务器。

本申请实施例中，若任一待选服务器得票数超过阈值，例如，得票数过半，或者得票数超过三分之二，则服务端01可以将任一待选服务器确定为第二执行服务器。

在本申请的一些实施例中，在图3示出的S102后还包括图6示出的S105，将结合各步骤进行说明。

S105、接收定时任务执行状态信息；定时任务执行状态信息表征目标客户端执行定时任务的状态。

本申请实施例中，服务端01在向目标客户端021发送第一定时任务指令或者第二定时任务指令后，还接收目标客户端021反馈的定时任务执行状态信息；其中，定时任务执行状态信息表征了目标客户端021执行定时任务的状态，如目标客户端021执行定时任务成功，则发送“成功”；目标客户端021执行定时任务受阻，则发送“异常”。

可以理解的是，服务端得到定时任务执行状态信息反馈，可以记录定时任务完成状况，为后续定时任务的执行提供参考。

在本申请的一些实施例中，在图3示出的S101后还包括图7示出的S106，将结合各步骤进行说明。

S106、将定时任务信息同步到至少一个同步服务器上。

本申请实施例中，服务端01在接收到定时任务信息后，可以将定时任务信息同步到服务端01中的同步服务器上。例如，服务器A作为当前的执行服务器011，接收到客户端集群02发送的定时任务信息后，则向服务端01中同步服务器B、C发起同步请求，以将该定时任务信息同步到服务端01中的每个服务器上。

可以理解的是，执行服务器将定时任务的相关数据及时同步，能够实现数据共享，从而，在执行服务器状态异常时，服务端仍能有效运行。从而，能够对定时任务不遗漏地执行。

在本申请的一些实施例中，在图3示出的S102前还包括图8示出的S107，将结合各步骤进行说明。

S107、通过负载均衡算法在客户端集群中确定目标客户端；客户端集群包括至少一个客户端。

本申请实施例中，服务端01可以通过负载均衡算法在客户端集群02中确定目标客户端021，并向目标客户端021发送第一定时任务指令或者第二定时任务指令，以保证当前执行周期中最多只有一次执行定时任务，避免定时任务的重复执行。其中，客户端集群02中包括了至少一个客户端。例如，参考图1，假设客户端集群02中的3台客户端都向服务端01中发送了定时任务信息a，定时任务信息a的执行时间为每隔5分钟。服务端01中的执行服务器011每隔5分钟会通过负载均衡算法，从该3台客户端中选择一台作为目标客户端021，并向目标客户端021发送定时任务指令。目标客户端021执行定时任务信息a相关的定时任务，然后把执行结果信息发送给服务端01。服务端01保存执行结果信息。

可以理解的是，确定目标客户端保证了同一时刻只向一个客户端发送定时任务执行指令，从而，能够对定时任务不重复地执行。

图9是本申请实施例提供的定时任务执行方法的一个可选的流程示意图，将结合图9示出的步骤进行说明。

S301、接收定时任务指令；定时任务指令包括：第一定时任务指令或第二定时任务指令；第一定时任务指令通过第一执行服务器定时发送；第二定时任务指令通过第二执行服务器定时发送。

本申请实施例中，客户端集群02可以接收服务端01定时发送的定时任务指令。其中，定时任务指令可以是第一执行服务器发送的第一定时任务指令，也可以是第二执行服务器发送的第二定时任务指令。

S302、基于定时任务指令执行对应的定时任务，得到对应的定时任务执行状态信息。

本申请实施例中，客户端集群02在接收到定时任务指令后，可以基于定时任务指令执行对应的定时任务，并得到对应的定时任务执行状态信息。其中，定时任务执行状态信息表征了目标客户端021执行定时任务的状态。

S303、向服务端发送定时任务执行状态信息。

本申请实施例中，客户端集群02在得到定时任务执行状态信息后，向服务端发送该定时任务执行状态信息，以反馈目标客户端021执行定时任务的状态。

可以理解的是，客户端集群将定时任务执行状态信息进行反馈，可以记录定时任务完成状况，为后续定时任务的执行提供参考。

在本申请的一些实施例中，在图9示出的S301前还包括图10示出的S401，将结合各步骤进行说明。

S401、向服务端发送定时任务信息；服务端基于定时任务信息定时发送第一定时任务指令或第二定时任务指令。

本申请实施例中，客户端集群02可以向服务端01发送定时任务信息，定时任务信息中包括了执行时间、任务说明、任务执行参数、任务执行方法、任务返回值等定时任务的相关信息。服务端01可以基于定时任务信息定时发送第一定时任务指令或第二定时任务指令。

图11是本申请实施例提供的定时任务执行方法的一个可选的流程示意图，将结合图11示出的步骤进行说明。

S601、客户端集群配置服务端地址。

本申请实施例中，客户端集群02中每个客户端可以通过调用客户端包031，来配置服务端地址。

S602、客户端集群向服务端发送定时任务信息。

本申请实施例中，客户端集群02可以发送定时任务信息给服务端01。其中，定时任务信息中包括了执行时间、任务说明、任务执行参数、任务执行方法、任务返回值等定时任务的相关信息。

S603、服务端集群化。

本申请实施例中，服务端01可以通过调用集群包034实现集群化。集群中有三种身份：执行服务器、同步服务器和待选服务器，这三种身份会随着集群的状态进行转换。其中，只有执行服务器可以与客户端集群02进行数据交互；同步服务器会向执行服务器进行数据同步；服务端01在所有待选服务器中确定执行服务器。

S604、服务端接收并存储定时任务信息。

本申请实施例中，服务端01可以通过当前的执行服务器接收客户端集群02所发送的定时任务信息。

S605、服务端定时发送定时任务执行指令给客户端集群。

本申请实施例中，服务端01在接收到定时任务信息后，可以基于定时任务信息，通过当前的执行服务器定时发送对应的定时任务执行指令给客户端集群02。

在本申请的一些实施例中，可以通过S701-S702来实现图10示出的S603，将结合各步骤进行说明。

S701、服务端确定初始服务器为第一执行服务器。

本申请实施例中，服务端01可以将初始服务器确定为第一执行服务器，来和客户端集群02进行交互。其中，初始服务器是服务端01中最先启动的服务器。例如，服务器A启动完成时会发送给其他服务器B、C心跳信号。此时，若其他服务器B、C还未启动完成，那么，服务器A直接成为第一执行服务器。当服务器B、C启动完成，并且发送心跳信号给服务器A，发现服务A的身份已经是执行服务器，那么，服务器B、C的身份直接转换为同步服务器；同时，服务器B、C开始同步服务器A的相关数据以及相关状态信息。

S702、若第一执行服务器的心跳回应时间超过阈值，服务端则在至少一个同步服务器中，确定第二执行服务器。

本申请实施例中，执行服务器和同步服务器通过心跳信号进行通信。若第一执行服务器A在接收到至少一个同步服务器发出的心跳信号后，进行回应的心跳回应时间超出了阈值，则服务端01将至少一个同步服务器B、C的身份转换为待选服务器，此时，服务器B、C拥有投票和选举的权利。服务端01在待选服务器B、C中进行选举投票，当投票过程中，若某个待选服务器的得票数超过半数，则该待选服务器的身份直接转换为执行服务器，即作为第二执行服务器。第一执行服务器A恢复正常后，其身份转换为同步服务器，然后和第二执行服务器进行数据同步。

在本申请的一些实施例中，可以通过S703-S704来实现图10示出的S604，将结合各步骤进行说明。

S703、第二执行服务器接收并储存定时任务信息，并进行数据同步。

本申请实施例中，在确定了第二执行服务器后，第二执行服务器便接收并储存客户端集群02所发送的定时任务信息，并和其他的同步服务器进行数据同步。

本申请实施例中，执行服务器可以并行的向其他的至少一个同步服务器发起复制数据请求。当这条数据被复制到大多数服务器上，执行服务器将这条数据应用到其状态机，并向客户端集群02返回执行结果。

S704、第二执行服务器与客户端集群进行链接确认。

本申请实施例中，执行服务器被确定后，会向客户端集群02中每个客户端发送心跳信号，以完成链接确认。执行服务器若与客户端集群02中任一客户端发送心跳信号失败次数达到阈值，则剔除该客户端在服务端01的信息。

需要说明的是，服务端01中只有执行服务器才能和客户端集群02发送信息。同步服务器保存和同步执行服务器的信息。当执行服务器发生故障，服务端01直接从同步服务器中选举出一个执行服务器，来重新和客户端集群02发送信息。

在本申请的一些实施例中，可以通过S705-S706来实现图10示出的S605，将结合各步骤进行说明。

S705、服务端通过负载均衡算法确定目标客户端。

本申请实施例中，服务端01在向客户端集群02发送定时任务执行指令之前，会通过负载均衡算法在客户端集群02中确定一个目标客户端，而后可以将定时任务执行指令发送给目标客户端。这样，保证了每次至多只有一次执行定时任务。

S706、服务端发送定时任务执行指令给目标客户端。

本申请实施例中，服务端01在确定了目标客户端后，可以将定时任务执行指令发送给目标客户端。

在本申请的一些实施例中，图10示出的S605之后还包括S707-S708，将结合各步骤进行说明。

S707、目标客户端执行定时任务。

本申请实施例中，客户端集群02中的目标客户端在接收到服务端01发送的定时任务执行指令后，可以通过反射机制执行相应的定时任务。

S708、目标客户端发送定时任务执行状态信息给服务端。

本申请实施例中，目标客户端在完成了定时任务执行后，可以将定时任务的执行情况，如成功、异常等，作为定时任务执行状态信息发送给服务端01。

可以理解的是，本申请实施例提供的定时任务执行方法，在集群化选举的过程中使用了“去中心化”架构，不借助第三方一致性框架来选举执行服务器。这样，保证了不会因为第三方框架出现问题导致整个服务出现崩溃，保证了服务的高可用、一致性。“去中心化”架构可以体现在：

1、自定义数据交互协议，包括通信方式、序列化方式等；

2、自定义服务端发送消息进行负载均衡策略；

3、支持跨语言、跨平台使用。

本申请实施例所提供的定时任务执行方法，与上文中所提到的方案1-3相比，具有如下优点：

与方案1相比，本申请实施例可以不依赖第三方中间系统，服务端自己作为中心化，实现高可用；

与方案2相比，本申请实施例可以实现集群模式，从而，防止因服务端单点故障而导致的系统崩溃；

与方案3相比，本申请实施例可以解决在微服务架构中的服务过多而导致的无法统一监控、配置、统计等问题。

图12为本申请实施例提供的服务端的一个可选的结构示意图。如图12所示，本申请实施例还提供了一种服务端800，包括：服务端接收单元804、服务端发送单元805、确定单元806，其中：

所述服务端接收单元804，用于接收并储存定时任务信息；

所述服务端发送单元805，用于基于定时任务信息，通过第一执行服务器向目标客户端定时发送第一定时任务指令；

所述确定单元806，用于若第一执行服务器的心跳回应时间超过阈值，则在至少一个同步服务器中，确定第二执行服务器；心跳回应时间为第一执行服务器回应至少一个同步服务器的心跳信号的时间；

所述服务端发送单元804，还用于基于定时任务信息，通过第二执行服务器向目标客户端定时发送第二定时任务指令。

在本申请的一些实施例中，所述确定单元806，还用于将初始服务器确定为第一执行服务器；初始服务器为服务端中最先启动的服务器。

在本申请的一些实施例中，所述确定单元806，还用于若第一执行服务器的心跳回应时间超过阈值，则在同步服务器中进行选举，以确定第二执行服务器。

在本申请的一些实施例中，所述确定单元806，还用于将至少一个同步服务器作为至少一个待选服务器；至少一个待选服务器中的每个待选服务器对至少一个待选服务器中的任一待选服务器进行投票；若至少一个待选服务器中的任一待选服务器得票数超过阈值，则将任一待选服务器确定为第二执行服务器。

在本申请的一些实施例中，所述服务端接收单元804，还用于接收定时任务执行状态信息；定时任务执行状态信息表征目标客户端执行定时任务的状态。

在本申请的一些实施例中，所述服务端800，还包括：同步单元807；其中：

所述同步单元807，用于将定时任务信息同步到至少一个同步服务器上。

在本申请的一些实施例中，所述确定单元806，还用于通过负载均衡算法在客户端集群中确定目标客户端；客户端集群包括至少一个客户端。

图13为本申请实施例提供的客户端的一个可选的结构示意图。如图13所示，本申请实施例还提供了一种客户端900，包括：客户端接收单元904、执行单元905、客户端发送单元906，其中：

所述客户端接收单元904，用于接收定时任务指令；定时任务指令包括：第一定时任务指令或第二定时任务指令；第一定时任务指令通过第一执行服务器定时发送；第二定时任务指令通过第二执行服务器定时发送；

所述执行单元905，用于基于定时任务指令执行对应的定时任务，得到对应的定时任务执行状态信息；

所述客户端发送单元906，用于向服务端发送定时任务执行状态信息。

在本申请的一些实施例中，所述客户端发送单元906，还用于向服务端发送定时任务信息；服务端基于定时任务信息定时发送第一定时任务指令或第二定时任务指令。

需要说明的是，图14为本申请实施例提供的服务端的一个可选的结构示意图，如图14所示，服务端800的硬件实体包括：服务端处理器801、服务端通信接口802和服务端存储器803，其中：

服务端处理器801通常控制服务端800的总体操作。

服务端通信接口802可以使服务端800通过网络与其他装置或设备通信。

服务端存储器803配置为存储由服务端处理器801可执行的指令和应用，还可以缓存待服务端处理器801以及服务端800中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。

需要说明的是，图15为本申请实施例提供的客户端的一个可选的结构示意图，如图15所示，客户端900的硬件实体包括：客户端处理器901、客户端通信接口902和客户端存储器903，其中：

客户端处理器901通常控制客户端900的总体操作。

客户端通信接口902可以使客户端900通过网络与其他装置或设备通信。

客户端存储器903配置为存储由客户端处理器901可执行的指令和应用，还可以缓存待客户端处理器901以及客户端900中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的定时任务执行的方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得服务端800或客户端900(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述服务端或客户端集群对应的方法中的步骤。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

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

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

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

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。