Timed task execution method, electronic equipment, storage medium and program product
By using aspect-oriented programming and distributed lock mechanisms in scheduled tasks, the problem of data corruption caused by concurrent execution of single-process scheduled tasks in clustered deployments is solved, achieving zero-intrusion task management and efficient utilization of lock resources.
Patent Information
- Application Number
- CN202511049386.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-29
- Publication Date
- 2025-11-14
AI Technical Summary
In a clustered deployment environment, the concurrent execution of single-process scheduled tasks can lead to data corruption and result distortion, especially when triggered internally, multiple deployment units running the same task simultaneously can cause data chaos.
Aspect-oriented programming is used to intercept the main thread of the scheduled task. A distributed lock mechanism is used to ensure that only one deployment unit acquires the lock. The main thread executes the business logic and the child thread updates the lock's heartbeat time. The lock is actively released after the task is completed, thus achieving distributed single-node execution.
It effectively avoids data corruption and result distortion, reduces access costs, achieves zero-intrusion task management, and ensures timely recovery of lock resources and serial execution of tasks.
Smart Images
Figure CN120950271A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a method for executing a timed task, an electronic device, a storage medium, and a program product. Background Technology
[0002] In a clustered deployment context, each cluster contains numerous servers or container groups as deployment units. For large information systems, in addition to tasks that normally provide online services, there are also scheduled tasks that perform fallback checks on system data, resources, and business operations. These scheduled tasks can be triggered by external systems or by the cluster itself. When a scheduled task is triggered by an external system, such as... Figure 3a As shown, a scheduled task triggering platform needs to be built outside the cluster, and an internal gateway needs to be deployed for the cluster. The external platform sends scheduled task triggering requests to the cluster, and the cluster's internal gateway forwards the requests to the corresponding deployment units for execution. When a scheduled task is triggered from within the cluster, as follows... Figure 3b As shown, there is no need to deploy an internal gateway in the cluster. After the triggering conditions required for the scheduled task are met, each deployment unit in the cluster will automatically start the scheduled task at the same time, and the same task will be executed by multiple deployment units at the same time.
[0003] For scheduled tasks with short time intervals, such as minutes or even seconds, an internal triggering method is generally used to avoid frequent requests from external systems to the cluster, increase the burden on the internal gateway of the cluster, and address the uncertainty caused by network fluctuations.
[0004] When triggered internally, all deployment units within the cluster will run the same task simultaneously. However, some scheduled tasks can only be executed by a single process. Concurrent execution can lead to data corruption or distorted results. For example, a task that periodically scans and reports erroneous data in a database may, under concurrent conditions, scan and report the same data multiple times, causing data corruption on the receiving end. Summary of the Invention
[0005] This invention provides a method for executing scheduled tasks, an electronic device, a storage medium, and a program product, which can avoid data corruption and result distortion caused by parallel execution of single-process scheduled tasks.
[0006] In a first aspect, the method for executing a scheduled task provided in the embodiments of the present invention is applied to a target deployment unit within a cluster, and includes:
[0007] After the scheduled task starts, the main thread is started, and aspect-oriented programming is used to intercept the main thread to execute the business logic methods of the scheduled task.
[0008] The main thread uses aspect-oriented programming to execute a scheduled task to request a distributed lock from a preset database.
[0009] If the distributed lock is successfully acquired, start the child thread;
[0010] The business logic method of the scheduled task is executed using the main thread, and the heartbeat time of the distributed lock is updated using a child thread during the execution of the scheduled task.
[0011] After the scheduled task is completed, control the child thread to stop updating the heartbeat time of the distributed lock, and control the aspect program to request the release of the distributed lock from the preset database.
[0012] Secondly, the timed task execution device provided in the embodiments of the present invention is applied to a target deployment unit within a cluster, and includes:
[0013] The intercept module is used to start the main thread after the scheduled task starts, and to use aspect-oriented programming to intercept the business logic methods of the main thread that execute the scheduled task.
[0014] The application module is used to use aspect-oriented programming to execute a scheduled task on the main thread to apply for a distributed lock from a preset database.
[0015] The startup module is used to start a child thread if the distributed lock is successfully acquired.
[0016] The processing module is used to execute business logic methods of scheduled tasks using the main thread, and to update the heartbeat time of the distributed lock using a child thread during the execution of the scheduled tasks.
[0017] The control module is used to control the child thread to stop updating the heartbeat time of the distributed lock after the scheduled task is completed, and to control the aspect program to request the release of the distributed lock from the preset database.
[0018] Thirdly, the electronic device provided in the embodiments of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the execution method of a timed task as in any embodiment of the present invention.
[0019] Fourthly, the computer-readable storage medium provided in the embodiments of the present invention stores a computer program thereon, which, when executed by a processor, implements the execution method of a timed task as in any embodiment of the present invention.
[0020] Fifthly, embodiments of the present invention provide a computer program product, which includes a computer program that, when executed by a processor, implements a method for executing a timed task as described in any embodiment of the present invention.
[0021] In this embodiment of the invention, aspect-oriented programming (AOP) automatically intercepts business logic before execution, encapsulating all cross-cutting logic such as lock acquisition, heartbeat maintenance, and lock release within the aspect. The scheduled task code itself requires no modification to achieve distributed single-node capabilities, reducing integration costs and realizing zero-intrusion task management. AOP uniformly handles lock requests, avoiding omissions of lock contention logic in manual coding, ensuring that only one of multiple deployment units can acquire the lock at any given time. This naturally transforms concurrent tasks into serial tasks, eradicating data corruption caused by concurrent task execution. The main thread focuses on business execution, unaffected by lock maintenance, while child threads are dedicated to heartbeat updates, providing continuous lock liveness assurance for long tasks and preventing lock retention due to node deadlock. The closed loop of "heartbeat renewal - task execution - proactive lock release" allows child threads to continuously update heartbeats, and the aspect proactively releases the lock upon task completion. Explicitly stopping child threads avoids wasting resources with invalid heartbeats and proactively releasing distributed locks ensures timely recovery of lock resources for other nodes. Attached Figure Description
[0022] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 This is a flowchart illustrating a method for executing a timed task provided in an embodiment of the present invention;
[0024] Figure 2a This is another flowchart illustrating the method for executing a timed task provided in an embodiment of the present invention;
[0025] Figure 2b This is an example diagram of a method for executing a timed task provided in an embodiment of the present invention;
[0026] Figure 3a This is an example diagram of an external system triggering a scheduled task;
[0027] Figure 3b This is an example diagram of a scheduled task being triggered within a cluster;
[0028] Figure 4 This is a schematic diagram of a timed task execution device provided in an embodiment of the present invention;
[0029] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. 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 comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0032] Before introducing the embodiments of the present invention, let's first introduce the relevant terms involved in the embodiments of the present invention:
[0033] Distributed locks are synchronization mechanisms used in distributed systems to control access to shared resources, preventing data inconsistencies or duplicate executions caused by multiple nodes operating on the same resource simultaneously. In distributed systems, multiple nodes may attempt to access or modify shared resources concurrently. Distributed locks provide a mutual exclusion mechanism to ensure that only one node can perform a specific operation at a time.
[0034] A cluster is a group of independent computer systems interconnected by a network to form a loosely coupled multiprocessor system that works together to complete computational tasks. This aggregate can provide higher computing speed, reliability, and performance than a single computer.
[0035] Deployment Unit: The smallest unit in a cluster system used for deploying and managing applications or services. It typically comprises a group of servers, nodes, or containers organized together to achieve a specific function or service. A deployment unit can be a physical server, virtual machine, container instance, or other form of computing resource, depending on the cluster's architecture and design. In this embodiment of the invention, each deployment unit deploys a complete system function and operates independently of the others.
[0036] Single-process scheduled tasks: Scheduled tasks that can only be executed by a single process to avoid errors. If multiple processes run this task simultaneously, the final execution result will be disordered, failing to meet the requirement of correct execution. The scheduled tasks in this embodiment of the invention are all single-process scheduled tasks, which can only be executed by one deployment unit and do not support simultaneous execution by multiple deployment units.
[0037] Aspect-Oriented Programming (AOP) is a programming paradigm that aims to improve code modularity and maintainability by separating cross-cutting concerns (such as logging, transaction management, and permission verification) from business logic. An aspect is the core concept of AOP; it defines the implementation of cross-cutting concerns and allows these concerns to be dynamically inserted into different execution points of the program.
[0038] Figure 1 This is a flowchart illustrating a method for executing a scheduled task according to an embodiment of the present invention. This method is applicable to scenarios where scheduled tasks are triggered within a cluster. The execution method can be performed by a scheduled task execution device provided in this embodiment, which can be implemented in software and / or hardware. In a specific embodiment, this device can be integrated into an electronic device, such as a computer, server, or container group. The electronic devices constitute a cluster, which can be understood as a deployment unit within the cluster. The following embodiment uses the integration of the scheduled task execution device into a target deployment unit within the cluster as an example. The target deployment unit can be any deployment unit within the cluster. (See also...) Figure 1 The method for executing a scheduled task in this embodiment may include the following steps:
[0039] Step 101: After the scheduled task starts, start the main thread and use aspect-oriented programming to intercept the main thread to execute the business logic method of the scheduled task.
[0040] A scheduled task is a processing logic that is automatically triggered at a preset time or period. In this embodiment, the scheduled task is a single-process scheduled task. The main thread is the default worker thread that executes the business logic code of the scheduled task. An aspect is a piece of interception logic based on the AOP (Aspect-Oriented Programming) mechanism, which runs automatically before / after the main thread enters the actual business logic method. The business logic method is the core functional code that the scheduled task actually needs to complete, such as "scanning error data and reporting it".
[0041] When a scheduled task is triggered, the system first starts the main thread to run the task. However, before the main thread actually executes the business logic method, it is intercepted by a predefined aspect, which automatically weaves in the subsequent common control logic such as "acquiring distributed locks, maintaining heartbeats, and releasing locks" without modifying the business code itself.
[0042] Step 102: Use aspect-oriented programming to execute a scheduled task on the main thread to request a distributed lock from the preset database.
[0043] A distributed lock is a cross-process, cross-node mutual exclusion mechanism that ensures that only one node can execute a specific code segment at any given time in a distributed environment. The pre-defined database, in this embodiment, specifically refers to a pre-created relational database table used to store distributed lock records (including fields such as lock name, environment, state, and heartbeat).
[0044] Once the main thread is started, the aspect program will initiate an atomic update operation on the preset database before it actually executes the business method, changing the lock state of the corresponding record from "released" to "occupied". Only after the current node successfully completes this preemption action will the main thread continue to execute the scheduled task, thereby ensuring that only one deployment unit in the entire cluster obtains the right to execute the task once.
[0045] Step 103: If the distributed lock is successfully acquired, start the child thread.
[0046] A child thread can be a worker thread explicitly created by the main thread, used to process auxiliary tasks in parallel. In this embodiment, it is dedicated to "renewing the heartbeat".
[0047] Once the main thread successfully acquires the distributed lock, it immediately creates and starts a child thread. The responsibility of this child thread is to periodically update the "heartbeat time" to the preset database during task execution to prevent the lock from being mistakenly acquired by other nodes due to timeout, thereby ensuring that the main thread has exclusive access to the lock resource throughout the entire task cycle.
[0048] Step 104: Execute the business logic method of the scheduled task using the main thread, and update the heartbeat time of the distributed lock using a child thread during the execution of the scheduled task.
[0049] The heartbeat time of a distributed lock is a field that records the last active moment of the lock. By continuously refreshing this time, the lock can be prevented from being automatically released by the system due to a preset timeout.
[0050] While the main thread is running the specific business logic of the scheduled task, an additional sub-thread is started. This sub-thread sends update requests to the database at fixed intervals to refresh the heartbeat time of the distributed lock to the current time, thereby ensuring that the lock remains valid throughout the entire task execution and will not be preempted by other nodes due to timeout.
[0051] Step 105: After the scheduled task is completed, control the child thread to stop updating the heartbeat time of the distributed lock, and control the aspect program to request the release of the distributed lock from the preset database.
[0052] Releasing a distributed lock can be achieved by changing the lock record's state from "occupied" back to "released," allowing other nodes to preempt the lock again.
[0053] Once the business logic of the scheduled task is completed in the main thread, the child thread is stopped from updating the heartbeat time through a predetermined mechanism. Then, the aspect program is triggered to initiate an atomic operation to the preset database, resetting the record state of the corresponding distributed lock to "release", thus officially ending the current exclusive execution and allowing other nodes to compete normally for the next round of tasks.
[0054] In this embodiment, aspect-based programming automatically intercepts business logic before execution, encapsulating all cross-cutting logic such as lock acquisition, heartbeat maintenance, and lock release within the aspect. The scheduled task code itself requires no modification to achieve distributed single-node capabilities, reducing integration costs and realizing zero-intrusion task management. Using aspect-based programming to uniformly handle lock requests avoids overlooking lock contention logic in manual coding, ensuring that only one of multiple deployment units can acquire the lock at any given time. This naturally transforms concurrent tasks into serial tasks, eradicating data corruption caused by concurrent task execution. The main thread focuses on business execution, unaffected by lock maintenance, while child threads are dedicated to heartbeat updates, providing continuous lock liveness assurance for long tasks and preventing lock stagnation caused by node deadlock. The closed loop of "heartbeat renewal - task execution - proactive lock release" allows child threads to continuously update heartbeats, and the aspect proactively releases the lock upon task completion. Explicitly stopping child threads avoids wasting resources with invalid heartbeats and proactively releasing distributed locks ensures timely reclamation of lock resources for other nodes.
[0055] The following further explains the execution method of the scheduled task provided in this embodiment of the invention. In this embodiment, a distributed lock component is designed, which includes a distributed lock abstract class and aspect processing logic for this abstract class. The abstract class implements methods such as preemption, release, and heartbeat update for the distributed lock. The scheduled task execution method is set as an abstract method, which is implemented by the scheduled task after inheriting from this abstract class. Scheduled tasks initiated within the cluster need to reference this component and implement the distributed lock abstract class in the component. That is, when the scheduled task starts, the program first goes through the aspect program inside the component, where the distributed lock is acquired and the heartbeat of the distributed lock is updated in real time. If the distributed lock is acquired in the aspect program, the scheduled task continues to be called; otherwise, the program exits and waits for the next initiation of the scheduled task.
[0056] like Figure 2a As shown, the method in this embodiment includes:
[0057] Step 201: Determine whether the triggering condition for starting the scheduled task has been met. If it has, proceed to step 202; otherwise, proceed to step 207.
[0058] Triggering conditions are pre-defined time or event rules used to determine when to start this scheduled task (e.g., reaching the hour, a fixed period, or when dependent data is ready). Before actually starting the main thread, the system checks whether the pre-defined triggering conditions for the scheduled task have been met; only when the conditions are met will the subsequent process continue, otherwise it remains silent and waits for the next round of checks.
[0059] Step 202: Start the scheduled task. After the scheduled task starts, start the main thread and use aspect-oriented programming to intercept the main thread to execute the business logic method of the scheduled task.
[0060] In this embodiment, the distributed lock abstract class is used as the entry point. The aspect program intercepts the business logic method of the main thread executing the scheduled task, calls the distributed lock acquisition method, and then determines whether the distributed lock has been acquired. If it has not been acquired, the scheduled task is not executed, and the program continues to wait for the next round of scheduled tasks. If the distributed lock has been acquired, the scheduled task is executed, and a child thread is started simultaneously to update the distributed lock heartbeat.
[0061] Step 203: Use aspect-oriented programming to execute a scheduled task on the main thread to request a distributed lock from the preset database.
[0062] In this embodiment, a database (i.e., a pre-defined database) can be used to implement the distributed lock. The pre-defined database can be a pre-created and configured relational database table used to persist the distributed lock records. Assuming the table name of the distributed lock is distributed_lock, the data structure of the distributed lock can be as shown in Table 1:
[0063]
[0064] Table 1
[0065] In practical applications, multiple environments may exist. To ensure that distributed locks in different environments do not interfere with each other, an `environment` field can be added to the distributed lock data structure. This `environment` field, along with the `lock_name` field, jointly identifies a distributed lock. That is, a distributed lock can be created in the pre-defined database based on the task identifier and the environment identifier of the scheduled task's running environment. The `lock_create_time` field is assigned a value when the distributed lock is inserted into the data table, recording its creation time. The `lock_state` field indicates whether the distributed lock has been preempted. This field will also be used for subsequent distributed lock preemption; 0 indicates the distributed lock has been released, and 1 indicates it has been preempted. The `deploy_unit_name` field records the deployment unit currently holding this distributed lock. The `heartbeat_time` field continuously monitors the distributed lock's occupancy. While a deployment unit holds the distributed lock, the heartbeat is continuously updated to indicate that the distributed lock is still occupied, preventing situations where the distributed lock cannot be released normally due to deployment unit downtime. For example, in this embodiment, the distributed lock timeout can be set to 10 seconds. That is, if the interval between the recorded heartbeat time and the current actual time exceeds the set distributed lock timeout, it indicates that the distributed lock can be preempted by other deployment units. The distributed lock release time `unlock_time` is used to release the distributed lock after the deployment unit completes its scheduled task and records the release time.
[0066] Distributed lock acquisition relies on the atomicity of database operations. All deployment units simultaneously initiate competition after the scheduled task starts, with only one side ultimately succeeding. Aspect-oriented programming (AOP) can be used to select a distributed lock from a preset database that meets preset conditions based on task and environment identifiers. These conditions may include a lock state that is released or a lock state that is held, but the heartbeat interval between the current time and the current time exceeds a preset duration. AOP can then be used to update the selected distributed lock's state from released to held, setting the lock's holding identifier to the target deployment unit's identifier, thus enabling the target deployment unit to acquire the distributed lock.
[0067] For example, the preemption operation statement for a distributed lock can be as follows:
[0068] UPDATE distribute_lock;
[0069] SET lock_state = 1;
[0070] deploy_unit_name="xxx";
[0071] heart_beat_time = NOW();
[0072] WHERE lock_name="xxx";
[0073] AND environment="xxx";
[0074] AND(lock_state=0)
[0075] OR TIMESTAMPDIFF(SECOND,heart_beat_time,NOW())>10).
[0076] This statement introduces two mutual exclusion conditions while matching the lock name and the environment:
[0077] lock_state = 0 — The lock is in the released state;
[0078] Heartbeat timeout — The difference between the current time and the last heartbeat exceeds 10 seconds.
[0079] The fact that any of these conditions is met indicates that the lock can be preempted, thus preventing "deadlock" caused by node crashes or network anomalies.
[0080] Before the main thread is about to execute business logic, the aspect program will intercept it and initiate an atomic operation (such as UPDATE) to the preset database in the identity of the main thread, attempting to change the state of the corresponding lock record from "released" to "occupied" by the target deployment unit. Only when the operation returns successfully is it considered to have acquired the distributed lock, and the main thread can continue to enter the actual business method, thereby ensuring that only one node in the cluster executes the same task at the same time.
[0081] Step 204: Determine whether the distributed lock has been successfully acquired. If so, proceed to step 205; otherwise, return to step 201.
[0082] The success of acquiring the distributed lock can be determined by the operation's return code. For example, a return code of 1 indicates that the lock was successfully acquired, while a return code of 0 indicates that the lock was not acquired.
[0083] Step 205: Start the child thread and use the main thread to execute the business logic method of the scheduled task. During the execution of the scheduled task, use the child thread to update the heartbeat time of the distributed lock to the current time according to the preset period.
[0084] The preset period is a fixed time interval (e.g., 5 seconds) specified during development, determining how often the child thread updates its heartbeat. The distributed lock heartbeat time is a timestamp field in the lock record, used to indicate to other nodes that "this lock is still held and has not timed out." Once the main thread successfully acquires the distributed lock, it immediately starts a child thread; subsequently, the main thread continues to execute the business logic of the scheduled task, while the child thread sends data update statements to the database at the preset period (e.g., every 5 seconds), refreshing the heartbeat time of the distributed lock to the current time. This continuously declares the lock's validity throughout the entire task execution, preventing other nodes from mistakenly acquiring it.
[0085] Step 206: After the scheduled task is completed, control the child thread to stop updating the heartbeat time of the distributed lock, and control the aspect program to request the release of the distributed lock from the preset database.
[0086] The completion of a scheduled task means that the main thread has finished processing all the business logic for this scheduled task. Releasing the distributed lock can be done by changing the lock's recorded state from "occupied" to "released," allowing other nodes to re-acquire it. Once the main thread confirms that the scheduled task has been completed, it immediately terminates the heartbeat refresh action of the child threads and initiates an atomic operation to the preset database through an aspect-oriented program, marking the corresponding distributed lock as released. At this point, the current node ends its exclusive hold on the lock, and any node can compete for the task again in the next round.
[0087] Step 207, continue to wait.
[0088] The following example illustrates the method for executing timed tasks provided in embodiments of the present invention, such as... Figure 2b As shown, Figure 2b The three horizontal columns represent three deployment units in the cluster: A, B, and C. The vertical arrows in each column represent the timeline within that deployment unit. The top "Start" arrow points to A, B, and C simultaneously, meaning that when the scheduled task trigger condition is met, the three deployment units start their respective main threads almost simultaneously to prepare for task execution. Only A's "acquire distributed lock" action succeeds; the same actions by B and C fail. Therefore, B and C immediately "end" and stop executing, demonstrating the mutual exclusion effect of the lock. After A acquires the lock, it starts a "heartbeat update sub-thread" to periodically refresh the lock's heartbeat time. The main thread continues to execute the actual business logic (task). When A's business logic is completed, A's aspect executes "release distributed lock," simultaneously stopping the heartbeat sub-thread, and then A also "ends." The entire cycle ends, and the next trigger will begin a new competition.
[0089] The entire diagram uses "three timelines + the success or failure of the lock" to intuitively express the complete closed loop of "lock acquisition - unique execution - heartbeat lifespan - task end - lock release". It highlights that when multiple nodes in the cluster start at the same time, only the node that acquires the lock will successfully execute the task, while the other nodes will exit directly, thus ensuring that the task is executed in a single process.
[0090] in addition, Figure 3a An example diagram is provided for triggering scheduled tasks from an external system. In this example, a scheduled task triggering platform needs to be built outside the cluster, and an internal gateway needs to be deployed for the cluster to ensure that the task is executed by a single deployment unit. Figure 3b An example diagram illustrating the triggering of a scheduled task within a cluster is provided. Without the method of this invention, a single scheduled task would be executed by multiple deployment units, potentially leading to data corruption or distorted results. The method provided in this embodiment of the invention is applied to… Figure 3b The architecture shown can solve the problem of a scheduled task being executed by multiple deployment units, ensuring that a scheduled task is executed by only one deployment unit.
[0091] In this embodiment, aspect-based programming automatically intercepts business logic before execution, encapsulating all cross-cutting logic such as lock acquisition, heartbeat maintenance, and lock release within the aspect. The scheduled task code itself requires no modification to achieve distributed single-node capabilities, reducing integration costs and realizing zero-intrusion task management. Using aspect-based programming to uniformly handle lock requests avoids overlooking lock contention logic in manual coding, ensuring that only one of multiple deployment units can acquire the lock at any given time. This naturally transforms concurrent tasks into serial tasks, eradicating data corruption caused by concurrent task execution. The main thread focuses on business execution, unaffected by lock maintenance, while child threads are dedicated to heartbeat updates, providing continuous lock liveness assurance for long tasks and preventing lock stagnation caused by node deadlock. The closed loop of "heartbeat renewal - task execution - proactive lock release" allows child threads to continuously update heartbeats, and the aspect proactively releases the lock upon task completion. Explicitly stopping child threads avoids wasting resources with invalid heartbeats and proactively releasing distributed locks ensures timely reclamation of lock resources for other nodes.
[0092] This invention targets scheduled tasks, maintaining an internal triggering method. It eliminates the need for external platforms or gateways, yet solves concurrency issues at extremely low cost (requiring only a single lock table and AOP aspects). This saves resources and is suitable for high-frequency tasks operating on a minute or even second-level scale. This invention relies solely on existing databases and AOP programs; scheduled task code can be integrated simply by inheriting an abstract class, resulting in virtually zero intrusion into existing business logic. Furthermore, the lock granularity is precise down to the task name + environment, using the task identifier and environment identifier as a composite primary key. This naturally supports lock isolation between test, pre-production, and production environments, preventing interference between environments.
[0093] Figure 4This is a schematic diagram of a timed task execution device provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the device includes:
[0094] Interception module 401 is used to start the main thread after the scheduled task starts, and to use aspect-oriented programming to intercept the business logic methods of the main thread executing the scheduled task.
[0095] Request module 402 is used to request a distributed lock from a preset database by executing a timed task on the main thread using aspect-oriented programming.
[0096] Startup module 403 is used to start a child thread if the distributed lock is successfully acquired;
[0097] Processing module 404 is used to execute the business logic method of the scheduled task using the main thread, and to update the heartbeat time of the distributed lock using the child thread during the execution of the scheduled task.
[0098] The control module 405 is used to control the child thread to stop updating the heartbeat time of the distributed lock after the scheduled task is completed, and to control the aspect program to request the release of the distributed lock from the preset database.
[0099] In one embodiment, the distributed lock is created in a preset database based on the task identifier of the scheduled task and the environment identifier of the scheduled task's running environment.
[0100] In one embodiment, the distributed lock has a lock state and an identifier of the holding object. The application module 402 uses an aspect-oriented programming approach to execute a timed task on the main thread to apply for and acquire the distributed lock from a preset database, including:
[0101] The aspect-oriented programming method selects distributed locks that meet preset conditions from a preset database based on task identifiers and environment identifiers. The preset conditions include that the lock is in a released state.
[0102] Aspect-oriented programming is used to update the lock state of the selected distributed lock from the released state to the occupied state, and the identifier of the occupying object of the distributed lock is set as the unit identifier of the target deployment unit.
[0103] In one embodiment, the distributed lock also has a heartbeat time, and the preset conditions also include that the lock state is occupied, but the interval between the heartbeat time and the current time exceeds a preset duration.
[0104] In one embodiment, the processing module 404 updates the heartbeat time of the distributed lock using a sub-thread, including:
[0105] The heartbeat time of the distributed lock is updated to the current time using a child thread at a preset period.
[0106] In one embodiment, before starting the main thread, the interception module 401 is further configured to:
[0107] Determine whether the triggering conditions for starting the scheduled task have been met;
[0108] The scheduled task will start when the trigger conditions for starting the scheduled task are met.
[0109] In one embodiment, after the application module 402 uses aspect-oriented programming to execute a timed task on the main thread to apply for a distributed lock from a preset database, the method further includes:
[0110] If the distributed lock is not successfully acquired, the interception module returns 401 to determine whether the triggering condition for the scheduled task to start has been met.
[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0112] The device in this invention automatically intercepts business logic before execution using aspect-oriented programming (AOP). It encapsulates all cross-cutting logic, such as lock acquisition, heartbeat maintenance, and lock release, within the aspect. The scheduled task code itself requires no modification to achieve distributed single-node capabilities, reducing integration costs and realizing zero-intrusion task management. By using AOP to uniformly handle lock requests, it avoids overlooking lock contention logic in manual coding, ensuring that only one of multiple deployment units can acquire the lock at any given time. This naturally transforms concurrent tasks into serial tasks, eradicating data corruption caused by concurrent task execution. The main thread focuses on business execution, unaffected by lock maintenance, while child threads are dedicated to heartbeat updates, providing continuous lock liveness assurance for long tasks and preventing lock stagnation caused by node deadlock. The closed loop of "heartbeat renewal - task execution - proactive lock release" allows child threads to continuously update heartbeats, and the aspect proactively releases the lock upon task completion. Explicitly stopping child threads avoids wasting resources with invalid heartbeats and proactively releasing distributed locks ensures timely recovery of lock resources for other nodes.
[0113] This invention targets scheduled tasks, maintaining an internal triggering method. It eliminates the need for external platforms or gateways, yet solves concurrency issues at extremely low cost (requiring only a single lock table and AOP aspects). This saves resources and is suitable for high-frequency tasks operating on a minute or even second-level scale. This invention relies solely on existing databases and AOP programs; scheduled task code can be integrated simply by inheriting an abstract class, resulting in virtually zero intrusion into existing business logic. Furthermore, the lock granularity is precise down to the task name + environment, using the task identifier and environment identifier as a composite primary key. This naturally supports lock isolation between test, pre-production, and production environments, preventing interference between environments.
[0114] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system 500 suitable for implementing an electronic device according to embodiments of the present invention. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.
[0115] like Figure 5 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.
[0116] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.
[0117] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined above in the system of this invention.
[0118] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, 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 device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.
[0119] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.
[0120] The modules and / or units described in the embodiments of the present invention can be implemented in software or hardware. The described modules and / or units can also be housed in a processor; for example, a processor can be described as including an interception module, an application module, a startup module, a processing module, and a control module. The names of these modules do not necessarily limit the module itself.
[0121] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include:
[0122] After the scheduled task starts, the main thread is started, and the aspect program intercepts the main thread to execute the business logic method of the scheduled task. The aspect program is used to execute the scheduled task of the main thread to request a distributed lock from the preset database. If the distributed lock is successfully acquired, a child thread is started. The main thread executes the business logic method of the scheduled task, and during the execution of the scheduled task, the child thread updates the heartbeat time of the distributed lock. After the scheduled task is completed, the child thread is controlled to stop updating the heartbeat time of the distributed lock, and the aspect program is controlled to request the release of the distributed lock from the preset database.
[0123] The technical solution of this invention utilizes aspect-oriented programming (AOP) to automatically intercept business logic before execution, encapsulating all cross-cutting logic such as lock acquisition, heartbeat maintenance, and lock release within the aspect. The scheduled task code itself requires no modification to achieve distributed single-node capabilities, reducing integration costs and realizing zero-intrusion task management. AOP handles lock requests uniformly, avoiding omissions of lock contention logic in manual coding, ensuring that only one of multiple deployment units can acquire the lock at any given time, naturally transforming concurrent tasks into serial tasks and eradicating data corruption caused by concurrent task execution. The main thread focuses on business execution, unaffected by lock maintenance, while child threads are dedicated to heartbeat updates, providing continuous lock liveness assurance for long tasks and preventing lock retention due to node deadlock. The closed loop of "heartbeat renewal - task execution - proactive lock release" allows child threads to continuously update heartbeats, and the aspect proactively releases the lock upon task completion. Explicitly stopping child threads avoids wasting resources with invalid heartbeats, and proactively releasing distributed locks ensures timely reclamation of lock resources for other nodes.
[0124] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the method for executing a timed task as provided in any embodiment of this invention.
[0125] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof. Programming languages include object-oriented programming languages as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0126] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.
[0127] It should be noted that the collection, use, storage, sharing, and transfer of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations, and require notification to the user and obtaining the user's consent or authorization. Where applicable, user personal information has undergone de-identification and / or anonymization and / or encryption technical processing. In addition, a corresponding operation entry is provided for the user to choose to agree to or reject the automated decision result; if the user chooses to reject, the process proceeds to the expert decision-making process.
[0128] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.
Claims
1. A method for executing a scheduled task, applied to a target deployment unit within a cluster, characterized in that, The method includes: After the scheduled task starts, the main thread is started, and aspect-oriented programming is used to intercept the main thread to execute the business logic methods of the scheduled task. The main thread uses aspect-oriented programming to execute a scheduled task to request a distributed lock from a preset database. If the distributed lock is successfully acquired, start the child thread; The business logic method of the scheduled task is executed using the main thread, and the heartbeat time of the distributed lock is updated using a child thread during the execution of the scheduled task. After the scheduled task is completed, control the child thread to stop updating the heartbeat time of the distributed lock, and control the aspect program to request the release of the distributed lock from the preset database.
2. The method according to claim 1, characterized in that, The distributed lock is created in the preset database based on the task identifier of the scheduled task and the environment identifier of the scheduled task's running environment.
3. The method according to claim 2, characterized in that, Distributed locks have lock states and possessing object identifiers. Aspect-oriented programming (AOP) is used by the main thread to execute a scheduled task to request a distributed lock from a pre-defined database, including: The aspect-oriented programming method selects distributed locks that meet preset conditions from a preset database based on task identifiers and environment identifiers. The preset conditions include that the lock is in a released state. Aspect-oriented programming is used to update the lock state of the selected distributed lock from the released state to the occupied state, and the identifier of the occupying object of the distributed lock is set as the unit identifier of the target deployment unit.
4. The method according to claim 3, characterized in that, Distributed locks also have a heartbeat timer. The preset conditions also include that the lock is in an occupied state, but the interval between the heartbeat time and the current time exceeds a preset duration.
5. The method according to claim 4, characterized in that, Updating the heartbeat time of the distributed lock using a child thread includes: The heartbeat time of the distributed lock is updated to the current time using a child thread at a preset period.
6. The method according to claim 1, characterized in that, Before starting the main thread, the following is also included: Determine whether the triggering conditions for starting the scheduled task have been met; The scheduled task will start when the trigger conditions for starting the scheduled task are met.
7. The method according to claim 6, characterized in that, After using aspect-oriented programming to execute a scheduled task on the main thread to request a distributed lock from a preset database, it also includes: If the distributed lock is not successfully acquired, wait and return to determine whether the triggering condition for the scheduled task to start has been met.
8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes a program to implement the method for executing a timed task as described in any one of claims 1 to 7.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the execution method of the timed task as described in any one of claims 1 to 7.
10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the execution method of the timed task as described in any one of claims 1 to 7.