Distributed cluster timed task scheduling method, device and program product

Abstract

The invention provides a distributed cluster timed task scheduling method and device and a program product, and relates to the technical field of computers. The method comprises the steps of traversing timed task scheduling configuration when a service process is started; for each timed task scheduling configuration, trying to obtain a distributed lock through a database shared by the current service cluster according to the timed task name; if the distributed lock is obtained, applying for a thread resource from a service process, registering a timed task by using a scheduler, and recording the registered timed task after registration succeeds; if the distributed lock is not obtained, the service process is reminded that the current timed task is registered by other processes. According to the embodiment of the invention, on the premise of not depending on an independent scheduling center, it can be ensured that the timed task is only executed by one node, repeated task scheduling is avoided, and meanwhile system complexity and resource overhead are reduced.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a distributed cluster timed task scheduling method, device, and program product. Background Technology

[0002] In modern distributed systems and microservice architectures, scheduled tasks are a crucial component supporting automated business operations, widely used in periodic or delayed operations such as data cleaning, report generation, resource scheduling, and state synchronization. Traditional scheduled task implementations typically rely on single-machine-level scheduling mechanisms, such as JDK built-in tools like Timer or ScheduledExecutorService provided by the Java platform. While these solutions can meet basic requirements in single-node deployment environments, they exhibit significant limitations in distributed cluster scenarios.

[0003] When the same business application is deployed on multiple nodes, the timers running independently on each node may simultaneously trigger the same task logic, causing the same task to be executed repeatedly. This not only wastes computing resources but may also lead to serious problems such as data inconsistency, duplicate processing, and idempotency violations, severely impacting system stability and the correctness of business logic. Furthermore, because such schedulers only have a local view and cannot perceive the status of other nodes in the cluster, they lack global coordination capabilities, making it difficult to guarantee the uniqueness and orderliness of task execution.

[0004] To address these issues, the industry commonly employs centralized scheduling frameworks, such as Quartz cluster mode, XXL-JOB, and Elastic-Job, which introduce an independent scheduling center to uniformly manage task triggering and allocation. However, these solutions require the additional deployment and maintenance of dedicated scheduling services, increasing system architecture complexity, operational costs, and network dependencies. Furthermore, the scheduling center itself can become a single point of failure (SPOF); a failure in this center will impact the execution of scheduled tasks across the entire cluster, reducing system availability and disaster recovery capabilities. Summary of the Invention

[0005] This disclosure provides a method, device, and program product for scheduling distributed cluster timed tasks, which at least to some extent improves the problems of high resource consumption, complex architecture, and single point of failure in related technologies for distributed timed task scheduling.

[0006] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0007] According to one aspect of this disclosure, a distributed cluster scheduled task method is provided. The method is executed by a software package or component integrated into a business application. The method includes: when the business process starts, traversing the scheduled task scheduling configurations; for each scheduled task scheduling configuration, attempting to acquire a distributed lock based on the scheduled task name through the database shared by the current business cluster; if the distributed lock is acquired, requesting a thread resource from the business process and registering a scheduled task using the scheduler; after successful registration, recording the registered scheduled task; if the distributed lock is not acquired, notifying the business process that the current scheduled task has already been registered by another process.

[0008] In one embodiment of this disclosure, for each scheduled task configuration, a distributed lock is acquired from the database shared by the current business cluster based on the scheduled task name. This includes: for each scheduled task configuration, after a first period of silence, acquiring a distributed lock from the database shared by the current business cluster based on the scheduled task name, wherein the expiration time of the distributed lock is N seconds; the method further includes: after each attempt to acquire the distributed lock, a second period of silence is performed, wherein the second period is a random value within a preset range.

[0009] In one embodiment of this disclosure, the first duration is N. 1.6 seconds.

[0010] In one embodiment of this disclosure, the second duration is a random value greater than or equal to 0 and less than or equal to 1000 milliseconds.

[0011] In one embodiment of this disclosure, the method further includes: after completing the configuration traversal of all scheduled tasks, if there is a distributed lock successfully registered by the current business process, then request another thread resource from the business process and register a first scheduled task; wherein the first scheduled task includes a scheduled task distributed lock that has been successfully renewed.

[0012] In one embodiment of this disclosure, the execution cycle of the first timed task is N / 3 seconds.

[0013] In one embodiment of this disclosure, the method further includes: during the life of the business process, periodically executing a registered scheduled task; when the user stops the business process, the business process releases all thread resources, and the database releases the distributed lock after the distributed lock expires.

[0014] In one embodiment of this disclosure, the method further includes: during the business application development phase, configuring a scheduled task for tasks that require scheduled execution, wherein the scheduled task configuration includes the task name, execution period, and execution content.

[0015] According to another aspect of this disclosure, a distributed cluster timed task scheduling system is provided, which is set in a business application. The device includes a task reading module, a lock acquisition module, and a scheduling registration module.

[0016] The task reading module is used to iterate through the scheduled task configuration when the business process starts. The lock acquisition module is used to schedule and configure each scheduled task, and based on the scheduled task name, attempt to acquire a distributed lock through the database shared by the current business cluster. The scheduling and registration module is used to request a thread resource from the business process if a distributed lock is acquired, and to register a scheduled task using the scheduler. After successful registration, the registered scheduled task is recorded. If the distributed lock is not acquired, the business process is notified that the current scheduled task has been registered by another process.

[0017] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory for storing instructions; and a processor for calling the instructions stored in the memory to implement the above-described distributed cluster timed task scheduling method.

[0018] According to another aspect of this disclosure, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the above-described distributed cluster timed task scheduling method.

[0019] According to another aspect of this disclosure, a computer program product is provided, which stores instructions that, when executed by a computer, cause the computer to implement the above-described distributed cluster timed task scheduling method.

[0020] According to another aspect of this disclosure, a chip is provided, including at least one processor and an interface; the interface is used to provide program instructions or data to the at least one processor; the at least one processor is used to execute the program instructions to implement the above-described distributed cluster timed task scheduling method.

[0021] The distributed cluster timed task scheduling method, device, and program products provided in this disclosure utilize a shared database to obtain a distributed lock based on the task name, ensuring that only one node successfully registers and executes the same task, guaranteeing the uniqueness of task execution and data consistency, and effectively solving the problem of repeated execution of timed tasks in a distributed environment. The scheduling logic is integrated into the business process as an embedded software package or component, eliminating the need to deploy a separate centralized scheduling service, significantly reducing system architecture complexity and operation and maintenance costs, and avoiding resource overhead and single point of failure risks caused by introducing additional scheduling middleware (such as Quartz, XXL-Job). When a node fails, its distributed lock will be automatically released after expiration, and other nodes can take over the task, achieving natural failover and improving the availability and elasticity of business applications. In addition, by centrally handling task registration and lock contention during the process startup phase, combined with on-demand application of thread resources, resource utilization efficiency is optimized and runtime contention overhead is reduced.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0024] Obviously, the accompanying drawings described below are merely some embodiments of this disclosure. Those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0025] Figure 1 This diagram illustrates a flowchart of a distributed cluster timed task scheduling method according to an embodiment of the present disclosure. Figure 2 This diagram illustrates a lock-up renewal process in an embodiment of the present disclosure. Figure 3 This document shows flowcharts corresponding to different business processes in embodiments of this disclosure; Figure 4 This diagram illustrates the scheduling configuration flowchart in an embodiment of the present disclosure. Figure 5 This diagram illustrates another distributed cluster timed task scheduling method in an embodiment of the present disclosure. Figure 6 This diagram illustrates a distributed cluster timed task scheduling device according to an embodiment of the present disclosure. Figure 7 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0026] To facilitate understanding of the technical solutions of this disclosure, the disclosure will be further described below with reference to the accompanying drawings.

[0027] The terms "first" and "second," etc., in this disclosure, claim, and drawings are used only to distinguish different objects and not to describe a particular order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0028] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this disclosure. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0029] In this disclosure, "at least one (item)" means one or more, "more than" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. "Or" indicates that there can be two relationships, such as only A exists and only B exists; when A and B are not mutually exclusive, it can also mean that there are three relationships, such as only A exists, only B exists, and A and B exist simultaneously. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c".

[0030] Scheduled tasks are a common requirement in daily business development, typically used to periodically execute certain critical operations, such as data cleanup, report generation, or resource allocation. Traditional implementations usually rely on Java JDK built-in timers (such as ScheduledExecutorService or Timer) for task scheduling. However, in a distributed cluster environment, this approach has significant limitations.

[0031] Because the JDK's built-in timers can only detect the state of the currently running node, when a business system is deployed across multiple distributed nodes, each node will independently trigger the same scheduled task. This can lead to the following problems: Task duplication: The same task may run simultaneously on multiple nodes, resulting in a waste of computing resources and potentially causing data consistency issues.

[0032] Unexpected Business Decisions: Business logic typically requires scheduled tasks to execute at fixed time intervals or times, but repeated scheduling in a distributed environment can disrupt this expectation.

[0033] Lack of global coordination capability: JDK timers cannot perceive the status of other nodes in the cluster, thus failing to achieve unified scheduling and management of tasks.

[0034] To address the aforementioned issues, a common alternative is to introduce a separate, centralized scheduling service (such as Quartz, XXL-Job, etc.) to avoid duplicate execution by centrally managing task scheduling across the entire cluster. However, this approach also has the following drawbacks: Increased resource costs: The need to deploy and maintain dedicated scheduling services increases machine resources and operational costs.

[0035] Increased system complexity: Introducing new components may lead to a more complex system architecture, increasing the difficulty of development and debugging.

[0036] Single point of failure risk: If the centralized scheduling service fails, it may affect the task scheduling capability of the entire cluster and reduce the availability of the system.

[0037] In summary, existing solutions either fail to meet the uniqueness and reliability requirements of task scheduling in distributed scenarios, or incur significant resource and complexity costs. Therefore, there is an urgent need for a method that can guarantee the accuracy of task scheduling while also considering resource efficiency and system simplicity, in order to better meet business needs in distributed environments.

[0038] The following detailed description of this exemplary implementation method is provided in conjunction with the accompanying drawings and embodiments.

[0039] First, this disclosure provides a distributed cluster timed task scheduling method, which can be executed by software packages or components integrated into a business application. It should be noted that the aforementioned software packages or components can also be referred to as third-party packages. Second-party packages typically refer to software packages or components developed and maintained by an internal team within the company or by partners with direct business dealings with the company (i.e., second parties). These software packages or components are usually custom-developed to solve specific business needs, rather than being developed by completely independent third-party entities like "third-party libraries."

[0040] The distributed cluster timed task scheduling method provided in this disclosure is applicable to a wide range of application scenarios, and is especially suitable for enterprises or organizations that need to execute timed tasks in a distributed environment and have high requirements for resource utilization efficiency.

[0041] Figure 1 This diagram illustrates a flowchart of a distributed cluster timed task scheduling method according to an embodiment of the present disclosure, as follows: Figure 1 As shown, the distributed cluster timed task scheduling method provided in this embodiment includes S101-S104.

[0042] In S101, when starting a business process, the scheduled task configuration is iterated.

[0043] When a business process starts, the system automatically loads a pre-configured list of scheduled tasks and iterates through these tasks one by one. This step is the core of the scheduling initialization process, ensuring that each task to be executed can participate in the scheduling competition within the cluster.

[0044] In S102, for each scheduled task, based on the scheduled task name, a distributed lock is attempted to be acquired through the database shared by the current business cluster.

[0045] For each scheduled task encountered during the current iteration, the system uses its "task name" as a unique key and attempts to acquire a distributed lock through a database shared by the business cluster, such as Redis. This lock is used to coordinate the execution rights of multiple nodes for the same task globally, ensuring that at most one node can successfully acquire the lock at any given time, thereby preventing the task from being registered and executed repeatedly.

[0046] In S103, if a distributed lock is acquired, a thread resource is requested from the business process, and a scheduled task is registered using the scheduler. After successful registration, the registered scheduled task is recorded.

[0047] If the current node successfully acquires the distributed lock, it indicates that it has obtained the qualification to execute the task. At this time, the system requests a thread resource from the business process and registers the execution logic of the task using a JDK built-in scheduler (such as ScheduledExecutorService), so that it runs according to the set period. After registration, the system records that the task has been registered on this node, which facilitates subsequent management and renewal operations.

[0048] In S104, if the distributed lock is not acquired, the business process is notified that the current scheduled task has been registered by another process.

[0049] If acquiring the lock fails, it means that the same task has already been preempted and registered by another node in the cluster. In this case, the system does not perform local registration but instead sends a notification to the business process, informing it that the task has already been executed by another process, thus avoiding resource waste and duplicate processing. This mechanism achieves task deduplication without centralized coordination, ensuring the uniqueness and consistency of scheduling.

[0050] In some embodiments, after reading the scheduled task configuration in S101, a first period of silence can be maintained before executing S102. That is, for each scheduled task configuration, acquiring a distributed lock based on the scheduled task name and the database shared by the current business cluster includes: for each scheduled task configuration, after a first period of silence, acquiring a distributed lock based on the scheduled task name and the database shared by the current business cluster, where the distributed lock expires in N seconds. In some embodiments, after each attempt to acquire the distributed lock, a second period of silence is maintained, where the second period is a random value within a preset range.

[0051] This disclosure significantly improves the stability and reliability of scheduled tasks in a distributed environment by introducing a dual-silence mechanism. First, after reading the configuration, a first silence period (e.g., N×1.6 seconds) effectively avoids concentrated competition among multiple nodes during startup, mitigating the "thundering herd effect" and reducing network congestion and database pressure caused by simultaneous lock contention. This design is particularly suitable for scenarios involving batch service restarts or scaling up / down, preventing a large number of nodes from initiating lock requests simultaneously.

[0052] In some embodiments, the first duration is N. 1.6 seconds.

[0053] In some embodiments, the second duration is a random value greater than or equal to 0 and less than or equal to 1000 milliseconds.

[0054] In this embodiment, a backoff strategy is introduced by randomly pausing for 0 to 1000 milliseconds after each attempt to acquire the distributed lock, further reducing the probability of multiple nodes repeatedly competing for the same lock. Since the delay is random, the operation rhythm of each node is naturally disrupted, improving the success rate and fairness of lock allocation and avoiding "livelocks" or prolonged contention.

[0055] By combining the distributed lock expiration time of N seconds with an initial duration of N × 1.6 seconds, the system ensures that even if some nodes start registering slightly later, they will not miss task preemption due to insufficient waiting time, thus balancing system response speed and scheduling fairness. The overall solution, without requiring central coordination, enhances the system's robustness and fault tolerance through a simple and effective timing control strategy, reduces the instantaneous load on shared resources (such as Redis), and improves the execution efficiency and success rate of the task registration phase.

[0056] In some embodiments, the above-described distributed cluster timed task scheduling method further includes Figure 2 S201 is shown.

[0057] In S201, after completing the configuration traversal of all scheduled tasks, if there is a distributed lock successfully registered by the current business process, then another thread resource is requested from the business process, and a first scheduled task is registered; the first scheduled task includes the distributed lock of the scheduled task that has been successfully renewed.

[0058] This disclosure effectively ensures the continuity and stability of distributed scheduled tasks by introducing a lock renewal mechanism. In a multi-node cluster, if a node successfully acquires a distributed lock but the lock expires during task execution, other nodes may misjudge the situation and preempt the task, leading to duplicate execution. Therefore, this solution, after task registration, starts an independent "first scheduled task" if a successfully registered task already exists, periodically renewing the held distributed lock.

[0059] In some embodiments, the execution cycle of the first scheduled task is N / 3 seconds, ensuring that the validity period is refreshed in time before the lock expires, avoiding accidental release of the lock due to network latency, GC pauses, or processing time. Taking N=30 seconds as an example, renewing the lock every 10 seconds provides sufficient safety buffer and significantly improves the fault tolerance of the system.

[0060] This disclosed embodiment achieves automatic lock maintenance without manual intervention, and it only starts on nodes where tasks have been registered, avoiding resource waste. Combined with the design of automatic thread release upon process exit, lock renewal naturally stops after a node crashes, and the lock eventually expires automatically, allowing other nodes to take over the task and achieving smooth failover. The overall solution enhances the system's high availability and self-management capabilities while ensuring unique task execution, providing key technical support for lightweight, decentralized scheduling.

[0061] In some embodiments, the above-described distributed cluster timed task scheduling method further includes Figure 3 S301-S302 are shown.

[0062] In S301, during the lifetime of a business process, registered scheduled tasks are executed periodically.

[0063] This ensures that registered scheduled tasks can be executed stably according to the set cycle during normal business processes, guaranteeing the continuity and reliability of task scheduling.

[0064] In S302, when the user stops the business process, the business process releases all thread resources, and the database releases the distributed lock after the distributed lock expires.

[0065] When a process terminates, all thread resources are proactively released, including those used for task execution and lock renewal, ensuring timely resource reclamation and preventing memory leaks and waste. At this point, because lock renewal has stopped, the distributed lock will automatically expire within N seconds and can be reacquired by other nodes without manual intervention, achieving smooth task transfer and high-availability switching.

[0066] In some embodiments, the above-described distributed cluster timed task scheduling method may further include, before S101, the following: Figure 4 S401 is shown.

[0067] In S401, during the business application development phase, scheduled task scheduling configuration is performed for tasks that require timed scheduling. The scheduled task scheduling configuration includes the task name, execution cycle, and execution content.

[0068] Task Name: As a unique identifier for the task, it must be unique throughout the entire distributed cluster. It is used to subsequently request distributed locks by name to ensure mutual exclusion of task execution. Execution cycle: Supports defining task trigger time rules (such as "every minute", "1 a.m. every day") using Cron expressions and other methods, providing flexible scheduling strategies; Execution content: Specifies the specific logic of the task, usually bound at the method level, such as calling the cleanup or calculation method of a business service.

[0069] This step implements declarative configuration and decoupled design for task scheduling. By completing the configuration during the development phase, the system can automatically complete scheduling initialization at runtime, improving maintainability; the global uniqueness of task names provides the foundation for a distributed locking mechanism, ensuring the uniqueness of task execution within the cluster; support for Cron expressions enhances scheduling flexibility and adapts to diverse business scenarios; and method-level execution content definition reduces integration costs and facilitates business code integration. Overall, this configuration mechanism provides data support and flexibility guarantees for subsequent automated and decentralized scheduling.

[0070] This disclosure utilizes a distributed locking mechanism (such as a Redis-based lock) to ensure that even in a multi-node distributed environment, each scheduled task is executed by only a single node, effectively preventing duplicate task scheduling and guaranteeing the uniqueness and accuracy of task execution. Unlike traditional centralized scheduling services, this disclosure's solution is directly integrated into business applications as a third-party package, tightly integrating the scheduled task scheduling logic with business code. This eliminates the need for additional dedicated scheduling processes or services, simplifying the system architecture and reducing operational costs. Since no separate scheduling service is required, this solution significantly reduces the need for additional hardware resources, improves the utilization of existing resources, and alleviates the overall system burden, providing a more cost-effective solution for businesses. It supports flexible task configuration options, including custom task names, cron expressions defining execution cycles, and method-level execution content, meeting diverse business needs and easily adaptable and expandable to meet future requirements.

[0071] In some embodiments, the execution entity of this distributed cluster scheduled task scheduling method can be a distributed cluster scheduled task scheduling system. This system is provided to business applications as a third-party package. Business applications that need to use this system must integrate the third-party package into their own projects and configure scheduled task scheduling according to the requirements of the third-party package, such as... Figure 5 As shown, the system execution flow is as follows: During the development phase, users need to configure the tasks to be scheduled according to requirements, supporting the simultaneous configuration of multiple scheduled tasks. The configuration content includes: Task name: must be unique within the current cluster; Execution cycle: Supports corn expressions; Execution content: Method level.

[0072] When starting the business process, the third-party package will actively read the user-provided scheduled task configuration: The second-party package will first remain silent for a period of time (the first duration mentioned above), the silence time being N. 1.6 seconds; After the silence is completed, the third-party package begins to traverse the scheduled task configuration, and for each scheduled task configuration: Based on the scheduled task name, obtain a distributed lock from a database shared by the current business cluster, such as Redis, with a lock expiration time of N seconds; If the distributed lock is acquired, the third-party package will request a thread resource from the business process and register a scheduled task using the JDK's built-in scheduler. After successful registration, the registered scheduled task will be recorded. If the distributed lock is not acquired, the third-party package will notify the business process that the current scheduled task has been registered by another process. Subsequently, the second-party packet will remain silent for 0-1000 milliseconds (the second duration mentioned above).

[0073] After completing the configuration traversal of all scheduled tasks, if there is a distributed lock successfully registered by the current business process, the third-party package will request another thread resource from the business process and register a scheduled task: execute once every N / 3 seconds to renew the successfully registered scheduled task distributed lock.

[0074] During the lifespan of the business process, the scheduled tasks registered by the third-party package will be executed periodically. When the user stops the business process, the business process will release all thread resources, including the thread that renewed the distributed lock for the registered scheduled task. Then the database will automatically release the distributed lock after it expires, waiting for the next registration of the scheduled task.

[0075] It should also be noted that the scheduled task configuration allows users to configure scheduled tasks in detail during the development phase, including key information such as task name, execution cycle, and execution content.

[0076] Distributed lock mechanism: A distributed lock is implemented using a database (such as Redis) shared by the current business cluster. This is used to control that only one business process can execute a specific scheduled task at the same time, preventing the task from being registered repeatedly and thus scheduled repeatedly.

[0077] Silent mechanism: A silent mechanism is introduced to reduce potential conflicts when multiple business processes start simultaneously, such as N during the initialization phase. A 1.6-second silence period and a random silence of 0-1000 milliseconds after the traversal is completed.

[0078] Thread resource management: Reasonably allocate and release thread resources to ensure that scheduled tasks can be executed on time during the life of the business process, and that related resources can be properly cleaned up when the process terminates.

[0079] Lock renewal mechanism: For successfully registered scheduled tasks, a dedicated thread is set up to periodically extend the validity period of their distributed locks, ensuring that long-running tasks are not mistakenly re-registered by other processes due to lock expiration.

[0080] This disclosure provides a scheduled task service via a third-party package, enabling convenient integration and use by business applications, enhancing code modularity and reusability. It utilizes distributed locks (such as Redis) to ensure the unique execution of scheduled tasks in a cluster environment, avoiding the risk of duplicate execution and improving the reliability and accuracy of task execution. It supports configuring execution cycles and method-level execution content using corn expressions, providing users with flexible task scheduling configuration methods to meet the needs of different business scenarios. The system design includes a distributed lock mechanism for automatically renewing registered scheduled tasks, ensuring the stability and continuity of long-running tasks. Simultaneously, it effectively releases resources when business processes stop, ensuring system robustness.

[0081] Based on the same inventive concept, this disclosure also provides a distributed cluster timed task scheduling system, such as... Figure 6 As shown, the distributed cluster timed task scheduling system includes a task reading module 601, a lock acquisition module 602, and a scheduling registration module 603.

[0082] The task reading module 601 is used to traverse the scheduled task configuration when the business process starts. The lock acquisition module 602 is used to attempt to acquire a distributed lock based on the name of each scheduled task and the database shared by the current business cluster, according to the scheduled task's configuration. The scheduling registration module 603 is used to request a thread resource from the business process if a distributed lock is acquired, and to register a scheduled task using the scheduler. After successful registration, the registered scheduled task is recorded. If the distributed lock is not acquired, the business process is notified that the current scheduled task has been registered by another process.

[0083] In some embodiments, the lock acquisition module 602 is configured to acquire a distributed lock based on the name of the scheduled task and the database shared by the current business cluster after a first period of silence, for each scheduled task. The expiration time of the distributed lock is N seconds.

[0084] The distributed cluster timed task scheduling system also includes a random silent module.

[0085] The random silence module is used to silence for a second duration after each attempt to acquire the distributed lock. The second duration is a random value within a preset range.

[0086] In some embodiments, the first duration is N. 1.6 seconds.

[0087] In some embodiments, the second duration is a random value greater than or equal to 0 and less than or equal to 1000 milliseconds.

[0088] In some embodiments, the distributed cluster timed task scheduling system further includes a lock renewal module.

[0089] The lock renewal module is used to request another thread resource from the business process and register a first scheduled task after completing the configuration traversal of all scheduled tasks. If there is a distributed lock that has been successfully registered by the current business process, the first scheduled task includes renewing the distributed lock that has been successfully registered.

[0090] In some embodiments, the execution cycle of the first scheduled task is N / 3 seconds.

[0091] In some embodiments, during the lifetime of a business process, registered scheduled tasks are executed periodically; the distributed cluster scheduled task scheduling system also includes a resource release module.

[0092] The resource release module is used to release all thread resources of the business process when the user stops the business process, and the database releases the distributed lock after the distributed lock expires.

[0093] In some embodiments, the distributed cluster timed task scheduling system further includes a scheduling configuration module.

[0094] The scheduling configuration module is used during the business application development phase to configure scheduled tasks for tasks that require timed scheduling. The scheduled task scheduling configuration includes the task name, execution period, and execution content.

[0095] The concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to define the order of functions performed by these devices, modules or units or their interdependencies.

[0096] Regarding the distributed cluster timed task scheduling system in the above embodiments, the specific methods by which each module performs operations have been described in detail in the embodiments related to the distributed cluster timed task scheduling method, and will not be elaborated here.

[0097] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0098] Some of the block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0099] The following reference Figure 7 This describes the electronic device provided in the embodiments of this disclosure. Figure 7 The electronic device 700 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0100] Figure 7 This diagram illustrates the architecture of an electronic device 700 provided in an embodiment of the present invention. Figure 7 As shown, the electronic device 700 includes, but is not limited to, at least one processor 710 and at least one memory 720.

[0101] Memory 720 is used to store instructions.

[0102] In some embodiments, memory 720 may include a readable medium in the form of volatile memory cells, such as random access memory (RAM) 7201 and / or cache 7202, and may further include read-only memory (ROM) 7203.

[0103] In some embodiments, the memory 720 may also include a program / utility 7204 having a set (at least one) program module 7205, such program module 7205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0104] In some embodiments, the memory 720 may store an operating system. This operating system may be a real-time operating system (RTX), such as Linux, UNIX, Windows, or OS X.

[0105] In some embodiments, the memory 720 may also store data.

[0106] As an example, processor 710 can read data stored in memory 720, which may be stored at the same memory address as the instruction, or the data may be stored at a different memory address than the instruction.

[0107] The processor 710 is configured to invoke instructions stored in the memory 720 to implement the steps described in the "Exemplary Methods" section above, based on various exemplary embodiments of this disclosure. For example, the processor 710 can execute the steps of the above-described embodiments of the distributed cluster timed task scheduling method.

[0108] It should be noted that the processor 710 described above can be a general-purpose processor or a special-purpose processor. The processor 710 may include one or more processing cores, and the processor 710 executes various functional applications and data processing by running instructions.

[0109] In some embodiments, processor 710 may include a central processing unit (CPU) and / or a baseband processor.

[0110] In some embodiments, the processor 710 may determine an instruction based on the priority identifier and / or function category information carried in each control instruction.

[0111] In this disclosure, the processor 710 and memory 720 can be configured separately or integrated together. As an example, the processor 710 and memory 720 can be integrated on a single board or a system-on-chip (SOC).

[0112] like Figure 7 As shown, the electronic device 700 is embodied in the form of a general-purpose computing device. The electronic device 700 may also include a bus 730.

[0113] Bus 730 can represent one or more of several types of bus structures, including a memory bus or memory controller, peripheral bus, graphics acceleration port, processor, or a local bus using any of the various bus structures.

[0114] Electronic device 700 can also communicate with one or more external devices 740 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 700, and / or with any device that enables electronic device 700 to communicate with one or more other computing devices (e.g., router, modem, etc.). Such communication can be performed through input / output (I / O) interface 750.

[0115] Furthermore, the electronic device 700 can also communicate with one or more networks (such as local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via the network adapter 760.

[0116] like Figure 7As shown, the network adapter 760 communicates with other modules of the electronic device 700 via the bus 730.

[0117] It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 700, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0118] It is understood that the structure illustrated in the embodiments of this disclosure does not constitute a specific limitation on the electronic device 700. In other embodiments of this disclosure, the electronic device 700 may include more than Figure 7 This may involve more or fewer components, or combining certain components, or splitting certain components, or different component arrangements. Figure 7 The components shown can be implemented in hardware, software, or a combination of both.

[0119] This disclosure also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, implement the distributed cluster timed task scheduling method described in the above method embodiments.

[0120] In this disclosure, the computer-readable storage medium is one capable of sending, propagating, or transmitting computer instructions for use by or in connection with an instruction execution system, apparatus, or device. As an example, the computer-readable storage medium is a non-volatile storage medium.

[0121] In some embodiments, more specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, USB flash drives, portable hard drives, or any suitable combination of the foregoing.

[0122] In this embodiment of the disclosure, the computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, wherein computer instructions (readable program code) are carried.

[0123] In some examples, computational instructions contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0124] This disclosure also provides a computer program product storing instructions that, when executed by a computer, cause the computer to implement the distributed cluster timed task scheduling method described in the above-described method embodiments. The instructions may be program code. In specific implementations, the program code may be written using any combination of one or more programming languages. The program code may execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0125] This disclosure also provides a chip, including at least one processor and an interface; the interface is used to provide program instructions or data to at least one processor; the at least one processor is used to execute program instructions to implement the distributed cluster timed task scheduling method described in the above method embodiments.

[0126] In some embodiments, the chip may further include a memory for storing program instructions and data, the memory being located within or outside the processor.

[0127] Those skilled in the art will understand that all or part of the steps of the above embodiments can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which can be collectively referred to as "circuit", "module" or "system".

[0128] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein.

[0129] This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A distributed cluster timed task scheduling method, characterized in that, The method is executed by a software package or component integrated into a business application, and the method includes: When starting the business process, iterate through the scheduled task configuration; For each scheduled task configuration, based on the scheduled task name, attempt to acquire a distributed lock through the database shared by the current business cluster; If a distributed lock is acquired, request a thread resource from the business process and register a scheduled task using the scheduler. After successful registration, record the registered scheduled task. If the distributed lock is not acquired, the business process is notified that the scheduled task has already been registered by another process.

2. The method according to claim 1, characterized in that, The configuration for each scheduled task involves obtaining a distributed lock from the database shared by the current business cluster based on the scheduled task name, including: For each scheduled task configuration, after a first period of silence, a distributed lock is obtained from the database shared by the current business cluster based on the scheduled task name. The expiration time of the distributed lock is N seconds. The method further includes: After each attempt to acquire the distributed lock, remain silent for a second period of time, which is a random value within a preset range.

3. The method according to claim 2, characterized in that, The first duration is N 1.6 seconds.

4. The method according to claim 2, characterized in that, The second duration is a random value that is greater than or equal to 0 and less than or equal to 1000 milliseconds.

5. The method according to claim 2, characterized in that, The method further includes: After completing the configuration traversal of all scheduled tasks, if there is a distributed lock successfully registered by the current business process, then request another thread resource from the business process and register a first scheduled task. The first scheduled task includes a distributed lock for a scheduled task that has been successfully renewed.

6. The method according to claim 5, characterized in that, The execution cycle of the first timed task is N / 3 seconds.

7. The method according to claim 2, characterized in that, The method further includes: During the lifetime of the business process, the registered scheduled tasks are executed periodically. When the user stops the business process, the business process releases all thread resources, and the database releases the distributed lock after the distributed lock expires.

8. The method according to claim 1, characterized in that, The method further includes: During the business application development phase, scheduled task scheduling configuration is performed for tasks that require timed scheduling. The content of the scheduled task scheduling configuration includes the task name, execution cycle, and execution content.

9. An electronic device, characterized in that, include: Memory, used to store instructions; A processor is used to invoke instructions stored in the memory to implement the distributed cluster timed task scheduling method as described in any one of claims 1-8.

10. A computer program product, characterized in that, The computer program product stores instructions that, when executed by a computer, cause the computer to implement the distributed cluster timed task scheduling method according to any one of claims 1-8.

Images