WO2025124229A1 - 一种基于Quartz的分布式任务调度框架及其应用 - Google Patents

一种基于Quartz的分布式任务调度框架及其应用 Download PDF

Info

Publication number
WO2025124229A1
WO2025124229A1 PCT/CN2024/136480 CN2024136480W WO2025124229A1 WO 2025124229 A1 WO2025124229 A1 WO 2025124229A1 CN 2024136480 W CN2024136480 W CN 2024136480W WO 2025124229 A1 WO2025124229 A1 WO 2025124229A1
Authority
WO
WIPO (PCT)
Prior art keywords
task
flow
execution
task flow
quartz
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/136480
Other languages
English (en)
French (fr)
Other versions
WO2025124229A9 (zh
Inventor
胡雁平
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Cloud Technology Co Ltd
Original Assignee
China Telecom Cloud Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Cloud Technology Co Ltd filed Critical China Telecom Cloud Technology Co Ltd
Publication of WO2025124229A1 publication Critical patent/WO2025124229A1/zh
Publication of WO2025124229A9 publication Critical patent/WO2025124229A9/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G06F9/5088—Techniques for rebalancing the load in a distributed system involving task migration
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Definitions

  • the present application relates to the field of computer technology, and in particular to a Quartz-based distributed task scheduling framework and its application.
  • the execution of task flows lacks observability, and it is impossible to understand the status and progress of task execution in a timely manner, making it difficult to quickly troubleshoot problems.
  • the scalability of traditional task execution is also relatively poor. It is difficult for new tasks to reuse existing tasks, and the execution of task flows cannot be scheduled to different machines according to machine availability, so distributed and highly available scheduling of task flows cannot be achieved.
  • the traditional method includes: registering multiple scheduling applications in a distributed queue at a zookeeper registration center; calling a first scheduling application among the registered multiple scheduling applications to allocate a distributed lock to the first scheduling application so that only the first scheduling application can execute tasks; and when the first scheduling application obtains the allocated distributed lock, using the first scheduling application to execute corresponding tasks.
  • the traditional method also includes: the master node receives task pull requests sent by multiple task execution nodes at a preset frequency, the master node assigns tasks to the target task execution node according to the received task pull requests, the target task execution node is one of the multiple task execution nodes, the master node receives the task execution result sent by the target task execution node after executing the assigned task, and when the target task execution node is detected to have a fault, the executing task queue of the target task execution node is transferred to other surviving task execution nodes. This can avoid single point failures and improve the stability and availability of the system.
  • Traditional methods also include: users define, launch and operate workflows by calling interface service APIs; the distributed workflow coordinator Coordinator integrates the distributed timing engine Quartz to schedule workflows and add them to the workflow dispatch distributed message queue MQ, receives workflows and processes their task dependencies, and adds the coordinated business tasks to be executed to the task dispatch distributed message queue MQ; the distributed task executor Worker receives and executes each business task from the task dispatch distributed message queue MQ, and calls back the task execution results to the distributed workflow coordinator Coordinator through the task callback distributed message queue MQ; finally, the Coordinator persists the task execution results to the database for feedback to users; the Coordinator focuses on logical coordination processing to ensure that the workflow coordination processing and task execution are fully decoupled, thereby improving the system's throughput, scalability and scalability.
  • the traditional system includes: the system is integrated by a coordinator and multiple quartz service engines, the kernel of each quartz service engine includes multiple task management units, and the task management units are preset with a first load threshold; the coordinator is used to monitor the first load water level of the task management unit, and is used to dynamically expand a new task management unit when the first load water level of any task management unit reaches the first load threshold; the provided quartz-based distributed task scheduling method is applied to the above system, and by expanding the quartz task management unit, the load of a single task management unit is reduced, and it is no longer limited by the performance bottleneck problem of quartz, and task routing can be controlled on the control plane without increasing the workload of the application end.
  • this application proposes a distributed task scheduling framework based on Quartz and its application.
  • the purpose of this application is to provide a distributed task scheduling framework based on Quartz and its application.
  • this application provides the following technical solutions: view, task execution, scheduled tasks, alarms and components;
  • the task execution includes a self-developed task flow execution engine, which is responsible for the execution of the task flow;
  • the alarm includes an abnormal situation reporting alarm, which is used to issue the alarm for the abnormal situation;
  • the components include MySQL, Quartz, Promethus and Alertmanager, which are used to implement the entire framework.
  • the task flow task_flow contains multiple steps, each step is a subtask flow, which can be nested, such as the instance creation task flow, which contains multiple steps, and the data items contained in the task flow are as follows:
  • Each type of task ID identifies a type of task flow, such as creating an instance.
  • parentTaskID which indicates the parent task flow ID of the task flow.
  • parent task flow ID is identified by this field;
  • each of the task flows specifically executes each task step task_step, and the task step is the content actually executed.
  • the data items included in the task step are as follows:
  • stepName which indicates the class name of the task step implementation and is used to reflect the instantiation object
  • a task flow task is created first.
  • the task flow task is queued into different task flow queues according to the instance and supports priority scheduling.
  • the task flow with a high priority is executed first.
  • the execution of the task flow is triggered, and tasks are dequeued from the task flow queue to execute the task flow.
  • the thread pool of the task flow is used for scheduling and execution to improve the efficiency of execution.
  • the situation in the task flow queue is judged. If the task flow queue is empty, the process of submitting the task flow for execution is terminated. If the task flow queue is not empty, the execution process of the task flow is repeated until all the task flow tasks are executed.
  • the periodic timeout detection quartz distributed task is used to periodically detect whether there are timeout tasks in the task flow in the database, and submit the timeout to the task execution engine for execution;
  • the task is scheduled, and then an available machine is selected for scheduling and execution. If the machine fails at this time, the distributed task is scheduled to another machine for execution. If the machine does not fail at this time, the process of distributed scheduling of the task is terminated.
  • the system is able to make tasks persistent; scheduled tasks include periodic timeout detection quartz distributed tasks and periodic task heartbeat update tasks, which can distribute and schedule tasks to multiple machines, realize abnormal migration of task flows, task flow interruption restart, retry, etc., so as to ensure high availability and scalability of tasks, support cluster deployment, ensure that tasks are triggered and executed only once, and support flexible periodic tasks, etc.; alarms include abnormal situation reporting alarms, which are used to warn of abnormal situations, support the triggering of abnormal tasks and retry, and ensure the reliability and stability of tasks; components include MySQL, Quartz, Promethus and Alertmanager, which are used to implement the entire framework.
  • FIG2 is a flowchart of task flow submission and execution described in a distributed task scheduling framework based on Quartz and its application in this application;
  • FIG3 is a diagram of a double-ended concurrent queue of a task flow described in a Quartz-based distributed task scheduling framework and its application in this application;
  • FIG6 is a task distributed scheduling diagram of a distributed task scheduling framework based on Quartz and its application described in the present application;
  • FIG. 7 is a distributed scheduling diagram of task flows described in a distributed task scheduling framework based on Quartz and its application in the present application;
  • FIG8 is a flowchart of task observation and failure alarm described in a distributed task scheduling framework based on Quartz and its application in this application;
  • FIG9 is a diagram showing the steps of creating tasks for the master and standby instances described in a distributed task scheduling framework based on Quartz and its application in the present application;
  • FIG. 10 is a step diagram of a subtask flow described in a Quartz-based distributed task scheduling framework and its application in the present application.
  • one embodiment or “embodiment” as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present application.
  • the term “in one embodiment” that appears in different places in this specification does not necessarily refer to the same embodiment, nor does it refer to a separate or selective embodiment that is mutually exclusive with other embodiments.
  • FIG. 1 a system overall architecture diagram of a Quartz-based distributed task scheduling framework and its application is provided, as shown in Figure 1.
  • a Quartz-based distributed task scheduling framework and its application include views, task execution, scheduled tasks, alarms and components.
  • the view includes the task flow execution view, which is used to observe the execution of the task flow.
  • the task flow task_flow contains multiple steps, each step is a sub-task flow, which can be nested.
  • the instance creation task flow contains multiple steps.
  • the data items contained in the task flow are as follows:
  • Each type of task ID identifies a type of task flow, such as creating an instance.
  • taskID which indicates the ID of the task flow and uniquely identifies the task flow
  • parentTaskID which indicates the ID of the parent task flow of a task flow.
  • ID of the parent task flow is identified by this field.
  • This timestamp is updated regularly when the local machine schedules the execution of the task.
  • Task execution includes a self-developed task flow execution engine, which is responsible for the execution of task flows.
  • Each task flow specifically executes each task step task_step.
  • the task step is the actual execution content.
  • the data items included in the task step are as follows:
  • stepName which indicates the class name of the task step implementation and is used to reflect the instantiation object
  • orderNo indicates the step number of the task flow in which the task step is located.
  • ChildTaskID a subtask flow of the label task step
  • a task flow task is created first.
  • the task flow task is queued into different task flow queues according to the instance and supports priority scheduling. Task flows with high priorities are executed first. At this time, the execution of the task flow is triggered, and tasks are dequeued from the task flow queue to execute the task flow. Specifically, the task flow thread pool is used for scheduling and execution to improve the efficiency of execution. After the current task flow is executed, the situation in the task flow queue is judged. If the task flow queue is empty, the process of submitting the task flow for execution is terminated. If the task flow queue is not empty, the execution process of the task flow is repeated until all the task flow tasks are executed.
  • each step also involves multiple state transitions.
  • the core process is that the step enters the READY state, starts to execute and enters the RUNNING state, enters the FAIL state if there is an exception, enters the ABORT state if it is a subtask flow step, and enters the SUCCESS state after execution is completed.
  • the step is in the SKIP state, it will be skipped.
  • the whole process is shown in Figure 5.
  • the periodic task heartbeat update task is used to periodically update the heartbeat timestamp of the locally executed task flow.
  • the distributed task scheduling framework quartz is introduced.
  • This framework is a powerful open source task scheduling framework, which is flexible and reliable, with distributed scheduling, and supports cluster deployment, periodic tasks, calendar tasks, etc.
  • One of its features is distributed task scheduling, which will schedule the task and only schedule it to one available machine. The process is shown in Figure 6. The process of distributed task scheduling is as follows:
  • the execution heartbeat timestamp of the task flow will be reported to MySQL. If a machine failure, program exception or other reasons occur during the operation, the heartbeat timeout detection will be performed on the distributed task. If the task times out, it will be scheduled to run on another machine. Periodic tasks will not be executed on the failed machine.
  • Alarms include reporting alarms for abnormal situations.
  • the combination of the task flow execution engine framework and the distributed scheduling quartz can realize the distributed high-availability scheduling of the task flow.
  • the execution may fail.
  • a set of alarm mechanisms is provided.
  • the alarm mechanism process is shown in Figure 8. The specific process is as follows:
  • the instance will be abnormal, which can trigger an alarm. Quartz will use periodic distributed scheduling tasks to report the abnormal status of the instance to Pushgateway, and then Promethus will periodically pull data, calculate alarm rules, push alarm data to AlertManager, and send it to the alarm recipient to implement the alarm process;
  • the success or failure of the task flow task will be persisted in real time, and the user can observe the running status of the task flow task on the page.
  • Quartz-based distributed scheduling framework in the self-developed task flow execution engine includes the following:
  • the task execution engine obtains the task flow implementation class corresponding to the code through the task code, maintains a code-to-class mapping table, and dynamically creates a task flow through the reflection mechanism. Create the execution object of the task flow, put it into the queue, trigger the scheduling execution, the first step of the execution is to initialize the task flow, and persist the steps required to execute the master and standby instance creation task to MySQL.
  • the steps after initialization are shown in Figure 9. It can be seen that the master and standby instance creation task includes 16 steps, of which the 15th step is a subtask.
  • the task flow takes the corresponding step data according to currentStepNo in turn, obtains the corresponding implementation class through step_name, and instantiates the step object through the reflection mechanism to execute the corresponding steps.
  • a new subtask flow is created and submitted to the task execution engine.
  • the subtask flow is a task to create a whitelist, including 6 steps, as shown in Figure 10. After execution, continue to execute the last step, and complete the instance creation after execution. It is known that the task flow and task steps are persisted to MySQL. In addition, during the task execution process, the abnormal execution will also be persisted. From this, the execution of the task flow can be observed, and the execution of the task flow can be viewed through the page.
  • Application 2 Cluster instance pause task, which aims to illustrate the distributed scheduling when a service failure occurs.
  • the task will be scheduled to another machine to achieve high availability of task flow execution without user perception.
  • multiple machines When deploying services, multiple machines will be deployed. Here, two machines are deployed to execute user task operations.
  • create a 4-shard MEMDB cluster each with 2 nodes, one master and one backup, for a total of 8 redis nodes.
  • the 4 shards have 4 proxy nodes, which are deployed on 4 machines.
  • the page initiates a cluster instance pause task. You can see that the task includes multiple steps, such as pausing the redis node, pausing the proxy node, etc.
  • After submitting the task manually stop one of the services. You can see that the task is not interrupted but continues to execute. From the log of another service, you can see that the task is executed by the service, that is, it is distributed and scheduled to another machine for execution. Finally, the execution of the paused task is completed without user perception.
  • a computer device including a memory and a processor, the memory is used to store instructions, and the processor is used to execute the instructions, so that the computer device executes the steps of implementing the above-mentioned Quartz-based distributed task scheduling framework and its application.
  • a computer-readable storage medium on which a computer program is stored.
  • the steps of implementing the above-mentioned Quartz-based distributed task scheduling framework and its application are implemented.
  • the computer-readable storage medium includes: a U disk, a mobile hard disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, and other media for storing program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

提供了一种基于Quartz的分布式任务调度框架及其应用，通过视图、任务执行、定时任务、告警和组件构建任务流执行引擎框架，支持任务流的池化执行和持久化；视图中包括任务流执行视图，用于观测任务流执行的情况，及时了解任务执行的状态和进度，便于快速排查问题；任务执行包括自研任务流执行引擎，用于负责任务流的执行；定时任务包括定期超时检测quartz分布式任务和定期任务心跳更新任务，可以将任务分布式调度到多台机器上，保证任务的高可用性和可扩展性；告警包括异常情况上报告警，用于对异常情况进行告警，保证任务的可靠性和稳定性；组件包括MySQL、Quartz、Promethus和Alertmanager，用于实现整个框架。

Description

一种基于Quartz的分布式任务调度框架及其应用
相关申请
本申请要求2023年12月15日申请的，申请号为2023117227740，名称为“一种基于Quartz的分布式任务调度框架及其应用”的中国专利申请的优先权，在此将其全文引入作为参考。
技术领域
本申请涉及计算机技术领域，尤其涉及一种基于Quartz的分布式任务调度框架及其应用。
 背景技术
在数据库领域，用户使用数据库一般是在页面控制台上进行操作，如实例管理，账号管理，数据管理，容灾管理等操作，这些操作任务一般会对应多个步骤，甚至每个步骤又会嵌套子任务，然而，传统的任务执行方式通常采用在单台机器上进行任务下发和执行，这种方式存在单点故障的问题，无法保证任务的高可用性；业界其他任务执行引擎在处理任务流，即由多个步骤组成的任务时不够灵活，不能支持任务流的嵌套调度，也不能复用已有任务流，传统技术中的分布式任务调度框架在处理机器故障等异常情况时也存在不足，不能实现无状态服务和自动重启等功能，任务流的执行缺乏可观测性，无法及时了解任务执行的状态和进度，难以快速排查问题，传统任务执行的可扩展性也比较差，新的任务很难复用已有的任务，且任务流的执行无法根据机器可用情况被调度到不同的机器上，无法实现任务流的分布式高可用的调度。
传统方法包括：在zookeeper注册中心处的分布式队列中注册多个调度应用；调用注册的多个调度应用中的第一调度应用，以向所述第一调度应用分配分布式锁，使得仅所述第一调度应用能够执行任务；以及当所述第一调度应用获得所分配的分布式锁时，利用所述第一调度应用执行相应的任务。
传统方法还包括：主节点接收多个任务执行节点以预设频率发送的任务拉取请求，主节点根据接收到的任务拉取请求分配任务给目标任务执行节点，目标任务执行节点为多个任务执行节点中的一个任务执行节点，主节点接收目标任务执行节点在执行所分配的任务后发送的任务执行结果，在感知到目标任务执行节点出现故障时将目标任务执行节点的执行中任务队列转移到其它存活的任务执行节点。从而可避免单点故障，提高系统的稳定性和可用性。
传统方法还包括：用户通过调用接口服务API，对工作流进行定义、上线和运维等；分布式工作流协调器Coordinator通过集成分布式定时引擎Quartz，来定时调度工作流并添加到工作流派发分布式消息队列MQ，接收工作流并处理其任务依赖关系，将协调后待执行的业务型任务添加到任务派发分布式消息队列MQ；分布式任务执行器Worker从任务派发分布式消息队列MQ中接收各业务型任务并执行，将任务执行结果通过任务回调分布式消息队列MQ回调至分布式工作流协调器Coordinator；最后Coordinator将任务执行结果持久化保存到数据库，用于反馈用户；将Coordinator专注于逻辑协调处理，保证工作流协调处理与任务执行充分解耦，提升系统的吞吐量、扩展性以及伸缩性。
传统的系统包括：系统由协调器和多个quartz服务引擎集成，每个所述quartz服务引擎的内核包括多个任务管理单元，所述任务管理单元预设有第一负载阈值；所述协调器用于监控所述任务管理单元的第一负载水位，以及用于在任一所述任务管理单元的第一负载水位达到所述第一负载阈值时，动态扩展新的任务管理单元；提供的基于quartz的分布式任务调度方法，应用于上述系统，通过对quartz的任务管理单元的扩展，减轻了单个任务管理单元的负荷，不再受限于quartz的性能瓶颈问题，并且在不增加应用端工作负荷的同时能够在控制面管控任务路由。
以上传统技术存在本背景技术提出的问题：传统任务执行方式存在的单点故障、可观测性差、可扩展性差。为解决这一问题，本申请提出一种基于Quartz的分布式任务调度框架及其应用。
 发明内容
本部分的目的在于概述本申请的实施例的一些方面以及简要介绍一些较佳实施例。在本部分以及本申请的说明书摘要和发明名称中可能会做些简化或省略以避免使本部分、说明书摘要和发明名称的目的模糊，而这种简化或省略不能用于限制本申请的范围。
鉴于上述传统技术中一种基于Quartz的分布式任务调度框架及其应用存在的问题，提出了本申请。
因此，本申请目的是提供一种基于Quartz的分布式任务调度框架及其应用。
为解决上述技术问题，本申请提供如下技术方案：视图、任务执行、定时任务、告警和组件；
所述视图中包括任务流执行视图，用于观测任务流执行的情况；
所述任务执行包括自研任务流执行引擎，用于负责任务流的执行；
所述定时任务包括定期超时检测quartz分布式任务和定期任务心跳更新任务；
所述告警包括异常情况上报告警，用于对异常情况进行所述告警；
所述组件包括MySQL、Quartz、Promethus和Alertmanager，用于实现整个框架。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：所述任务流task_flow中包含多个步骤，每个步骤是一个子任务流，即可嵌套，如实例创建任务流，就包含多个步骤，所述任务流包含的数据项如下所示：
taskCode，表示任务id，每类任务id标识了一类任务流，如创建实例；
taskID，表示所述任务流的id，唯一标识了所述任务流；
parentTaskID，表示所述任务流的父亲任务流id，一个嵌套的子任务流，所述父亲任务流id用此字段标识；
CurrentStepNo，表示当前任务流执行的步骤；
status，表示所述任务流的状态；
version，表示所述任务流的心跳时间戳，本机调度执行该任务时会定期更新这个时间戳。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：每个所述任务流具体执行的是每个任务步骤task_step，所述任务步骤是实际执行的内容，所述任务步骤包括的数据项如下所示：
stepName，表示所述任务步骤实现的类名，被用于反射实例化对象；
orderNo，表示所述任务步骤所处的所述任务流中的第几个步骤，执行所述任务流时，依次按序执行所述任务；
childTaskID，标号所述任务步骤的一个子任务流；
status，表示所述任务步骤的状态。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：所述任务流提交执行的流程如下所示：
当用户创建实例、暂停实例、任务超时迁移、任务重试以及其他操作时，先创建任务流任务，所述任务流任务按实例入队到不同的任务流队列且支持优先级调度，优先级高的所述任务流优先被执行，此时会触发所述任务流的执行，从所述任务流队列中出队任务，进行所述任务流的执行，具体采用的是所述任务流的线程池进行调度执行，提高执行的效率，当前任务流执行结束后判断所述任务流队列中的情况，若所述任务流队列为空，则结束所述任务流提交执行的流程，若所述任务流队列不为空，则重复所述任务流的执行过程，直到所述任务流任务全部执行完毕。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：所述任务流队列采用的是Java并发包中ConcurrentLinkedDeque，所述任务流队列是一个基于链表的双端队列，使用时从队尾入队，从队头出队，此外采用两个队列的形式，一个队列保存高优先级的任务，另一个保存普通任务流的任务，调度执行时优先从高优先级的队列提取任务进行执行。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：所述定期超时检测quartz分布式任务用于定期检测数据库中任务流中的任务是否有超时任务，超时则提交给任务执行引擎运行；
所述定期任务心跳更新任务用于定期更新本地执行的任务流心跳时间戳；
任务分布式调度的过程如下所示：
首先调度任务，然后选择一个可用机器，进行调度执行，若此时机器发生故障，则将分布式任务调度到另一台机器执行，若此时机器没有发生故障，则结束所述任务分布式调度的过程。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：任务流分布式调度的过程如下所示：
首先创建所述任务流任务，然后选择一台可用运行机器运行所述任务流，每个所述任务流在本机执行时，会上报所述任务流的执行心跳时间戳到MySQL中，若在运行过程中发生机器故障、程序异常和其他原因，则对分布式任务进行心跳超时检测，若任务超时，则调度到另一台机器上运行，其中定期任务不会在故障机器中执行。
作为本申请所述一种基于Quartz的分布式任务调度框架及其应用的一种方案，其中：所述告警的机制流程如下所示：
当所述任务流运行时，若运行成功，则结束所述告警的机制流程；
若运行失败，则导致实例异常，可触发所述告警，利用quartz定期分布式调度任务进行上报实例异常状态到pushgateway，然后promethus定期拉取数据，计算告警规则，推送告警数据到alertmanager，发送给告警接收人，实现告警流程；
此外所述任务流任务在执行过程中，运行成功失败的情况均会进行实时持久化，用户在页面上可以观测到所述任务流任务的运行情况。
一种计算机设备，包括，存储器，用于存储指令；处理器，用于执行所述指令，使得所述设备执行实现一种基于Quartz的分布式任务调度框架及其应用。
一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被执行时，实现一种基于Quartz的分布式任务调度框架及其应用。
本申请的有益效果：本申请通过视图、任务执行、定时任务、告警和组件构建任务流执行引擎框架，支持任务流的池化执行和持久化，可方便扩展，支持任务流嵌套调度，具备复用已有任务流的机制，且不依赖其他组件，可实现提供lib包方便复用于其他需要任务流调度的场景；视图中包括任务流执行视图，用于观测任务流执行的情况，以页面视图的形式展示任务流的执行情况，可以及时了解任务执行的状态和进度，便于快速排查问题；任务执行包括自研任务流执行引擎，用于负责任务流的执行，提供了任务流的执行流程和状态的可持久化；定时任务包括定期超时检测quartz分布式任务和定期任务心跳更新任务，可以将任务分布式调度到多台机器上，实现了任务流的异常迁移、任务流中断重启、重试等，从而保证任务的高可用性和可扩展性，且支持集群部署，保障任务触发且只触发执行一次，并可支持灵活周期任务等；告警包括异常情况上报告警，用于对异常情况进行告警，支持异常任务的触发告警和重试，保证任务的可靠性和稳定性；组件包括MySQL、Quartz、Promethus和Alertmanager，用于实现整个框架。
 附图说明
为了更清楚地说明本申请实施例或传统技术中的技术方案，下面将对实施例或传统技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据公开的附图获得其他的附图。
图1为本申请一种基于Quartz的分布式任务调度框架及其应用的系统整体架构图；
图2为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务流提交执行流程图；
图3为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务流双端并发队列图；
图4为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务运行状态图；
图5为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务步骤运行状态图；
图6为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务分布式调度图；
图7为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务流分布式调度图；
图8为本申请一种基于Quartz的分布式任务调度框架及其应用所述的任务观测以及失败告警流程图；
图9为本申请一种基于Quartz的分布式任务调度框架及其应用所述的主备实例创建任务的步骤图；
[根据细则91更正 23.01.2025]
图10为本申请一种基于Quartz的分布式任务调度框架及其应用所述的子任务流的步骤图。
[根据细则91更正 23.01.2025]
[已删除]
 具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
在下面的描述中阐述了很多具体细节以便于充分理解本申请，但是本申请还能够采用其他不同于在此描述的其它方式来实施，本领域技术人员能够在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施例的限制。
其次，此处所称的“一个实施例”或“实施例”是指可包含于本申请至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例，也不是单独的或选择性的与其他实施例互相排斥的实施例。
再其次，本申请结合示意图进行详细描述，在详述本申请实施例时，为便于说明，表示器件结构的剖面图会不依一般比例作局部放大，而且所述示意图只是示例，其在此不应限制本申请保护的范围。此外，在实际制作中应包含长度、宽度及深度的三维空间尺寸。
实施例1
本实施例中，提供了一种基于Quartz的分布式任务调度框架及其应用的系统整体架构图，如图1所示，一种基于Quartz的分布式任务调度框架及其应用包括视图、任务执行、定时任务、告警和组件。
视图中包括任务流执行视图，用于观测任务流执行的情况。
任务流task_flow中包含多个步骤，每个步骤是一个子任务流，即可嵌套，如实例创建任务流，就包含多个步骤，任务流包含的数据项如下所示：
taskCode，表示任务id，每类任务id标识了一类任务流，如创建实例；
taskID，表示任务流的id，唯一标识了任务流；
parentTaskID，表示任务流的父亲任务流id，一个嵌套的子任务流，父亲任务流id用此字段标识；
CurrentStepNo，表示当前任务流执行的步骤；
status，表示任务流的状态；
version，表示任务流的心跳时间戳，本机调度执行该任务时会定期更新这个时间戳。
其中任务流的状态如表1所示：
表1任务流的状态
任务执行包括自研任务流执行引擎，用于负责任务流的执行。
每个任务流具体执行的是每个任务步骤task_step，任务步骤是实际执行的内容，任务步骤包括的数据项如下所示：
stepName，表示任务步骤实现的类名，被用于反射实例化对象；
orderNo，表示任务步骤所处的任务流中的第几个步骤，执行任务流时，依次按序执行任务；
childTaskID，标号任务步骤的一个子任务流；
status，表示任务步骤的状态。
其中，任务步骤的状态如表2所示：
表2任务步骤的状态
任务流提交执行的流程如图2所示，具体解释如下所示：
当用户创建实例、暂停实例、任务超时迁移、任务重试以及其他操作时，先创建任务流任务，任务流任务按实例入队到不同的任务流队列且支持优先级调度，优先级高的任务流优先被执行，此时会触发任务流的执行，从任务流队列中出队任务，进行任务流的执行，具体采用的是任务流的线程池进行调度执行，提高执行的效率，当前任务流执行结束后判断任务流队列中的情况，若任务流队列为空，则结束任务流提交执行的流程，若任务流队列不为空，则重复任务流的执行过程，直到任务流任务全部执行完毕。
任务流队列采用的是Java并发包中ConcurrentLinkedDeque，任务流队列是一个基于链表的双端队列，具有高效、线程安全、双端队列特性、支持空元素和可扩展性强的优点，比较适合任务调度的场景，使用时从队尾入队，从队头出队，如图3所示，此外采用两个队列的形式，一个队列保存高优先级的任务，另一个保存普通任务流的任务，调度执行时优先从高优先级的队列提取任务进行执行。
从队列中进行任务流出队后，触发具体的任务流执行，任务流涉及多个状态，整个流程是任务流执行时，会执行该任务流中的多个步骤，并且按序执行，投入运行时进行初始化，初始化所做的工作是初始化该任务流要执行的所有步骤并持久化入MySQL，初始化失败进入EXEC_NEW状态，初始化完成后进入READY状态，接着开始执行，依次执行任务流的每个步骤，通过currentStepNo属性知道当前需要执行的步骤，从MySQL中取到当前步骤参数，并通过反射机制动态创建对象，实例化任务步骤对象进行执行，如果步骤是嵌套的子任务流，则进入ABORT状态等待子任务流的完成，每个步骤执行完成后检查是否是任务流的最后一个任务，即判断是否执行完成，具体是判断任务流的currentStepNo属性，看是否是大于等于需要执行的步骤数，每次完成一个步骤，该属性会递增，由此判断一个任务流是否结束，在执行过程中，如果发现异常错误，则进入TERMINATE状态，如果进行重试即会进入QUERY_RETRY状态，排队等待执行，投入运行后，重新进入READY状态进行执行，整个过程如图4所示。
在任务流执行过程中，每个步骤的执行也涉及了多个状态的转换，核心流程是步骤进入READY状态，开始执行进入RUNNING状态，有异常进入FAIL状态，如果是子任务流步骤则进入ABORT状态，执行完成进入SUCCESS状态，另外如果步骤是SKIP状态则会执行跳过执行，整个过程如图5所示。
定时任务包括定期超时检测quartz分布式任务和定期任务心跳更新任务。
定期超时检测quartz分布式任务用于定期检测数据库中任务流中的任务是否有超时任务，超时则提交给任务执行引擎运行。
定期任务心跳更新任务用于定期更新本地执行的任务流心跳时间戳。
为了解决任务执行过程中可能出现的异常情况，如机器故障导致任务无法继续执行，引入了分布式任务调度框架quartz，该框架是一个功能强大的开源任务调度框架，灵活可靠，分布式调度，且支持集群部署，周期任务、日历任务等，其中一个特性是分布式任务调度，会将任务调度且只调度到一台可用的机器上，该过程如图6所示，任务分布式调度的过程如下所示：
首先调度任务，然后选择一个可用机器，进行调度执行，若此时机器发生故障，则将分布式任务调度到另一台机器执行，若此时机器没有发生故障，则结束任务分布式调度的过程。
为了解决任务流执行过程中因为机器故障、或者程序问题等导致任务执行异常等问题，将任务流执行引擎跟quartz相结合，利用quartz的分布式任务调度特性，服务被部署了多台机器，当出现上面问题时，任务流会被调度到另外一台机器上去执行，具体实现是每个任务流在本机执行时，会上报本任务流的执行心跳时间戳信息到MySQL中，具体是保存在version字段，当出现机器故障或者程序问题或者其他原因导致任务流无法继续执行时，会有一个quartz的定期任务定期检测任务流的时间戳是否超时，如果超时则会将该任务流投入本地运行，该定期任务不会在故障机器中执行，利用了quartz的分布式调度的功能，从而实现任务流在异常情况下的高可用分布式调度，整个过程如图7所示，任务流分布式调度的过程如下所示：
首先创建任务流任务，然后选择一台可用运行机器运行任务流，每个任务流在本机执行时，会上报任务流的执行心跳时间戳到MySQL中，若在运行过程中发生机器故障、程序异常和其他原因，则对分布式任务进行心跳超时检测，若任务超时，则调度到另一台机器上运行，其中定期任务不会在故障机器中执行。
告警包括异常情况上报告警。
在正常情况下，任务流执行引擎框架和分布式调度quartz的结合可实现任务流的分布式高可用调度，但是在任务流执行过程中，可能是会执行失败的，这种情况下提供了一套告警机制，告警的机制流程如图8所示，具体流程如下所示：
当任务流运行时，若运行成功，则结束告警的机制流程；
若运行失败，则导致实例异常，可触发告警，利用quartz定期分布式调度任务进行上报实例异常状态到pushgateway，然后promethus定期拉取数据，计算告警规则，推送告警数据到alertmanager，发送给告警接收人，实现告警流程；
此外任务流任务在执行过程中，运行成功失败的情况均会进行实时持久化，用户在页面上可以观测到任务流任务的运行情况。
组件包括MySQL、Quartz、Promethus和Alertmanager。
实施例2
一种基于Quartz的分布式调度框架在自研任务流执行引擎中的应用包括以下几个：
[根据细则91更正 23.01.2025]
应用一：创建主备实例任务，旨在说明有嵌套子任务的任务流创建以及任务流执行的过程，同时说明子任务流复用已有任务流的机制以及任务流可观测性的特性；首先用户下发创建实例任务，该任务持久化到MySQL，核心数据项包括任务id：1201-1668879808996605952、任务code：1201、任务描述：主备实例创建任务、实例id、参数包括部署机器信息、心跳时间、当前执行步骤:currentStepNo，初始化为0，并将任务提交给任务流执行引擎，任务执行引擎通过任务Code得到该Code对应的任务流实现类，维护了一个code到类的映射表，通过反射机制动态创建该任务流的执行对象，并投入队列，触发调度执行，执行的第一步就是进行任务流的初始化，将该主备实例创建任务需要执行的步骤持久化到MySQL，初始化后的步骤如图9所示，可以看到主备实例创建任务中包括了16个步骤，其中第15个步骤是一个子任务，该任务流根据currentStepNo依次取相应的步骤数据，通过step_name得到相应的实现类，并通过反射机制实例化步骤对象执行相应的步骤，在执行到15个步骤时，创建新的子任务流并提交给任务执行引擎，子任务流是一个创建白名单的任务，包括6个步骤，如图10所示，执行完毕继续执行最后一个步骤，执行完毕后完成实例的创建。由此知道任务流和任务步骤都持久化到了MySQL，此外任务执行过程中，执行的异常情况也会进行持久化，由此可观察该任务流的执行情况，通过页面可查看该任务流的执行情况。
应用二：集群实例暂停任务，旨在说明在出现服务故障时的分布式调度，该任务会被调度到另外一台机器，实现任务流执行的高可用，对用户无感知；在部署服务时会部署多台，这里部署2台，用来执行用户的任务操作，首先创建一个4分片的MEMDB集群，每个分片2个节点，一主一备，总共8个redis节点，4个分片具有4个代理节点，部署在4台机器，页面发起一个集群实例暂停任务，会看到该任务包括了多个步骤，如暂停redis节点、暂停proxy节点等、在提交任务后，手动将其中一个服务停止，可以看到任务并没有中断执行，而是继续执行，从另外一个服务的日志可以看到该任务被该服务执行，即被分布式调度到另外一台机器执行，最后完成该暂停任务的执行，对用户无感知。
应用三：清理数据任务，旨在说明任务流失败告警的流程，通过手动模拟任务失败，这里通过docker stop命令手动将一个单节点实例的节点暂停，然后在页面触发清理数据任务，该任务会出现异常，因为该节点不在运行，导致任务流失败，任务执行引擎会记录异常到该实例，另外会有quartz定时任务推送实例的状态到pushgateway，实例的状态包括正常、异常的状态，通过提前配置好了告警规则，告警会被promethus推送到alertmanager，被发送给告警接收人，如企业微信告警，收到告警后，知道异常的实例id，然后页面观测到该任务流的执行情况，发现是redis节点不在运行导致，手动启动redis节点，然后发起任务重试，实现清理任务流的执行。
实施例3
本实施例中，提供了一种计算机设备，包括存储器和处理器，存储器用于存储指令，处理器用于执行该指令，使得计算机设备执行实现上述一种基于Quartz的分布式任务调度框架及其应用的步骤。
实施例4
本实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被执行时实现上述一种基于Quartz的分布式任务调度框架及其应用的步骤。
该计算机可读存储介质包括：U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种存储程序代码的介质。
应说明的是，以上实施例仅用以说明本申请的技术方案而非限制，尽管参照较佳实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，能够对本申请的技术方案进行修改或者等同替换，而不脱离本申请技术方案的精神和范围，其均应涵盖在本申请的权利要求范围当中。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

  1. 一种基于Quartz的分布式任务调度框架及其应用，其特征在于：包括，
    视图、任务执行、定时任务、告警和组件；
    所述视图中包括任务流执行视图，用于观测任务流执行的情况；
    所述任务执行包括自研任务流执行引擎，用于负责任务流的执行；
    所述定时任务包括定期超时检测quartz分布式任务和定期任务心跳更新任务；
    所述告警包括异常情况上报告警，用于对异常情况进行所述告警；
    所述组件包括MySQL、Quartz、Promethus和Alertmanager，用于实现整个框架。
  2. 如权利要求1所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：所述任务流task_flow中包含多个步骤，每个步骤是一个子任务流，即可嵌套，如实例创建任务流，就包含多个步骤，所述任务流包含的数据项如下所示：
    taskCode，表示任务id，每类任务id标识了一类任务流，如创建实例；
    taskID，表示所述任务流的id，唯一标识了所述任务流；
    parentTaskID，表示所述任务流的父亲任务流id，一个嵌套的子任务流，所述父亲任务流id用此字段标识；
    CurrentStepNo，表示当前任务流执行的步骤；
    status，表示所述任务流的状态；
    version，表示所述任务流的心跳时间戳，本机调度执行该任务时会定期更新这个时间戳。
  3. 如权利要求2所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：每个所述任务流具体执行的是每个任务步骤task_step，所述任务步骤是实际执行的内容，所述任务步骤包括的数据项如下所示：
    stepName，表示所述任务步骤实现的类名，被用于反射实例化对象；
    orderNo，表示所述任务步骤所处的所述任务流中的第几个步骤，执行所述任务流时，依次按序执行所述任务；
    childTaskID，标号所述任务步骤的一个子任务流；
    status，表示所述任务步骤的状态。
  4. 如权利要求3所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：所述任务流提交执行的流程如下所示：
    当用户创建实例、暂停实例、任务超时迁移、任务重试以及其他操作时，先创建任务流任务，所述任务流任务按实例入队到不同的任务流队列且支持优先级调度，优先级高的所述任务流优先被执行，此时会触发所述任务流的执行，从所述任务流队列中出队任务，进行所述任务流的执行，具体采用的是所述任务流的线程池进行调度执行，提高执行的效率，当前任务流执行结束后判断所述任务流队列中的情况，若所述任务流队列为空，则结束所述任务流提交执行的流程，若所述任务流队列不为空，则重复所述任务流的执行过程，直到所述任务流任务全部执行完毕。
  5. 如权利要求4所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：所述任务流队列采用的是Java并发包中ConcurrentLinkedDeque，所述任务流队列是一个基于链表的双端队列，使用时从队尾入队，从队头出队，此外采用两个队列的形式，一个队列保存高优先级的任务，另一个保存普通任务流的任务，调度执行时优先从高优先级的队列提取任务进行执行。
  6. 如权利要求5所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：所述定期超时检测quartz分布式任务用于定期检测数据库中任务流中的任务是否有超时任务，超时则提交给任务执行引擎运行；
    所述定期任务心跳更新任务用于定期更新本地执行的任务流心跳时间戳；
    任务分布式调度的过程如下所示：
    首先调度任务，然后选择一个可用机器，进行调度执行，若此时机器发生故障，则将分布式任务调度到另一台机器执行，若此时机器没有发生故障，则结束所述任务分布式调度的过程。
  7. 如权利要求6所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：任务流分布式调度的过程如下所示：
    首先创建所述任务流任务，然后选择一台可用运行机器运行所述任务流，每个所述任务流在本机执行时，会上报所述任务流的执行心跳时间戳到MySQL中，若在运行过程中发生机器故障、程序异常和其他原因，则对分布式任务进行心跳超时检测，若任务超时，则调度到另一台机器上运行，其中定期任务不会在故障机器中执行。
  8. 如权利要求7所述的一种基于Quartz的分布式任务调度框架及其应用，其特征在于：所述告警的机制流程如下所示：
    当所述任务流运行时，若运行成功，则结束所述告警的机制流程；
    若运行失败，则导致实例异常，可触发所述告警，利用quartz定期分布式调度任务进行上报实例异常状态到pushgateway，然后promethus定期拉取数据，计算告警规则，推送告警数据到alertmanager，发送给告警接收人，实现告警流程；
    此外所述任务流任务在执行过程中，运行成功失败的情况均会进行实时持久化，用户在页面上可以观测到所述任务流任务的运行情况。
  9. 一种计算机设备，其特征在于：包括，
    存储器，用于存储指令；
    处理器，用于执行所述指令，使得所述设备执行实现如权利要求1-8中任一项所述的一种基于Quartz的分布式任务调度框架及其应用。
  10. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于：该计算机程序被执行时，实现如权利要求1-8中任一项所述的一种基于Quartz的分布式任务调度框架及其应用。
PCT/CN2024/136480 2023-12-15 2024-12-03 一种基于Quartz的分布式任务调度框架及其应用 Pending WO2025124229A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202311722774.0 2023-12-15
CN202311722774.0A CN117850998A (zh) 2023-12-15 2023-12-15 一种基于Quartz的分布式任务调度框架及其应用

Publications (2)

Publication Number Publication Date
WO2025124229A1 true WO2025124229A1 (zh) 2025-06-19
WO2025124229A9 WO2025124229A9 (zh) 2025-09-12

Family

ID=90528039

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/136480 Pending WO2025124229A1 (zh) 2023-12-15 2024-12-03 一种基于Quartz的分布式任务调度框架及其应用

Country Status (2)

Country Link
CN (1) CN117850998A (zh)
WO (1) WO2025124229A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117850998A (zh) * 2023-12-15 2024-04-09 天翼云科技有限公司 一种基于Quartz的分布式任务调度框架及其应用
CN118331708A (zh) * 2024-04-28 2024-07-12 广州简知信息科技有限公司 一种动态队列调度方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113377518A (zh) * 2021-07-05 2021-09-10 四川新网银行股份有限公司 一种分布式任务定时调度方法和装置
CN113778614A (zh) * 2021-08-03 2021-12-10 科大国创云网科技有限公司 一种面向企业服务总线的集群异常监控告警系统及方法
CN115421898A (zh) * 2022-11-07 2022-12-02 杭州比智科技有限公司 一种基于quartz框架的大数据任务调度管理系统及方法
CN115794344A (zh) * 2022-11-24 2023-03-14 浙江桢数科技有限公司 一种基于Quartz框架的多级任务调度方法
CN117850998A (zh) * 2023-12-15 2024-04-09 天翼云科技有限公司 一种基于Quartz的分布式任务调度框架及其应用

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112363812B (zh) * 2020-11-17 2022-09-06 浪潮云信息技术股份公司 基于任务分类的数据库连接队列管理方法及存储介质
KR102653309B1 (ko) * 2021-03-03 2024-03-29 주식회사 카카오뱅크 스케쥴링 장치 및 방법
CN114546348A (zh) * 2022-03-15 2022-05-27 河钢数字技术股份有限公司 一种全流程支持拖拉拽的自动化分布式任务流调度系统
CN115809133A (zh) * 2022-12-13 2023-03-17 北京领雁科技股份有限公司 分布式调度系统、方法、电子设备和计算机可读介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113377518A (zh) * 2021-07-05 2021-09-10 四川新网银行股份有限公司 一种分布式任务定时调度方法和装置
CN113778614A (zh) * 2021-08-03 2021-12-10 科大国创云网科技有限公司 一种面向企业服务总线的集群异常监控告警系统及方法
CN115421898A (zh) * 2022-11-07 2022-12-02 杭州比智科技有限公司 一种基于quartz框架的大数据任务调度管理系统及方法
CN115794344A (zh) * 2022-11-24 2023-03-14 浙江桢数科技有限公司 一种基于Quartz框架的多级任务调度方法
CN117850998A (zh) * 2023-12-15 2024-04-09 天翼云科技有限公司 一种基于Quartz的分布式任务调度框架及其应用

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZHANG YONGGANG, ZHUANG WEIJIN, MINGYANG SUN, WU YI, HAIBING ZHU: "Architectural design of distributed intelligent alarm application for equipment monitoring in the "large operation" mode of State Grid", DIANLI XITONG BAOHU YU KONGZHI/POWER SYSTEM PROTECTION AND CONTROL, vol. 44, no. 22, 16 November 2016 (2016-11-16), pages 148 - 153, XP093322727, ISSN: 1674-3415, DOI: 10.7667/PSPC151985 *

Also Published As

Publication number Publication date
WO2025124229A9 (zh) 2025-09-12
CN117850998A (zh) 2024-04-09

Similar Documents

Publication Publication Date Title
WO2025124229A9 (zh) 一种基于Quartz的分布式任务调度框架及其应用
CN112416581B (zh) 定时任务的分布式调用系统
US8412984B2 (en) Debugging in a cluster processing network
US8789058B2 (en) System and method for supporting batch job management in a distributed transaction system
CA3168286A1 (en) Data flow processing method and system
CN114090198A (zh) 分布式任务调度方法、装置、电子设备及存储介质
CN110895488B (zh) 任务调度方法及装置
CN110888719A (zh) 一种基于web服务的分布式任务调度系统及方法
CN112667383B (zh) 一种任务执行及调度方法、系统、装置、计算设备及介质
CN107168779A (zh) 一种任务管理方法及系统
CN108089915B (zh) 基于消息队列的业务控件化处理的方法及系统
CN109710416B (zh) 资源调度方法及装置
CN110798339A (zh) 一种基于分布式任务调度框架的任务容灾方法
CN115309531B (zh) 基于实时任务队列的高并发多任务调度管理方法
CN109582459A (zh) 应用的托管进程进行迁移的方法及装置
US20210256593A1 (en) Coordination process restart device and coordination process restart method
CN115421898A (zh) 一种基于quartz框架的大数据任务调度管理系统及方法
CN113032110A (zh) 一种基于分布式对等架构设计的高可用任务调度方法
CN113867911A (zh) 一种任务调度方法、设备及微服务系统
US20230315604A1 (en) Using a task identifier to identify processing services that have processed a task
CN111522630B (zh) 基于批次调度中心的计划任务执行方法以及系统
CN111880947B (zh) 一种数据传输方法及装置
CN112214323B (zh) 一种资源回收方法、装置及计算机可读存储介质
CN112328403B (zh) 一种SparkContext的配置方法、装置及服务端
CN115080199A (zh) 任务调度方法、系统、设备、存储介质及程序产品

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24902650

Country of ref document: EP

Kind code of ref document: A1