A timing task processing method and device, electronic equipment and storage medium

Abstract

The application provides a timing task processing method and device, electronic equipment and storage medium, comprising: in response to a trigger event of a timing task, obtaining a distributed lock from a shared distributed storage service based on a distributed lock acquisition program embedded in the timing task in advance; in response to a result of successful acquisition of the distributed lock, executing a business program corresponding to the timing task; and in response to a result of failed acquisition of the distributed lock, skipping the execution of the business program corresponding to the timing task. By directly embedding the distributed lock acquisition logic in the timing task method body and using the shared distributed storage service as a coordination intermediary, the application ingeniously solves the problem of repeated execution of timing tasks in a micro-service multi-instance environment. Without introducing any external components, the application realizes lightweight and maintains the simplicity and low operation and maintenance cost of the original architecture.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a method, apparatus, electronic device, and storage medium for timed task processing. Background Technology

[0002] In a microservices architecture, to improve system availability, multiple instances of the same application service are typically deployed. These instances are configured identically and all contain the same monolithic scheduled task logic. Because each instance is isolated and runs independently, when the monolithic scheduled task is triggered, all instances will execute the same business operation simultaneously. For example, if the scheduled task is used by a vehicle networking platform to send payment notifications to users, the same user may receive multiple duplicate SMS messages. Such duplicate execution not only severely impacts user experience but also wastes computing resources and incurs additional operating costs. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a method, apparatus, electronic device and storage medium for processing timed tasks, so as to avoid the repeated execution of timed tasks.

[0004] Firstly, a method for handling scheduled tasks is provided, applicable to multiple service instances executing the same application service, wherein the multiple service instances are isolated from each other and configured with the same scheduled task; the method includes: In response to the triggering event of a scheduled task, a distributed lock is obtained from a shared distributed storage service based on the distributed lock acquisition program pre-embedded in the scheduled task; the distributed lock represents the permission credential for the scheduled task to execute. In response to the successful acquisition of the distributed lock, the business program corresponding to the scheduled task is executed. In response to the failure to acquire the distributed lock, skip the execution of the business program corresponding to the scheduled task.

[0005] Optionally, sending a request to acquire a distributed lock to the shared distributed storage service includes: Send a first instruction containing a lock identifier and a unique request identifier to the shared distributed storage service. The first instruction instructs the distributed storage service to create a key-value pair associated with the lock identifier and return a successful retrieval response if it determines that the lock identifier is not occupied; otherwise, it returns a failed retrieval response.

[0006] Optionally, the first instruction is an atomic operation instruction provided by the distributed storage service, used to complete the determination of the lock's occupancy status and the setting of key-value pairs in a single indivisible operation.

[0007] Optionally, the method also includes: In response to the completion of the business program execution, a second instruction containing a lock identifier and a unique request identifier is sent to the distributed storage service based on the distributed lock release procedure pre-embedded in the scheduled task. The second instruction instructs the distributed storage service to delete the key-value pair when verifying that the value currently associated with the lock identifier is consistent with the unique request identifier.

[0008] Optionally, the first instruction also includes the lock's validity period, which is longer than the estimated execution time of the business program corresponding to the scheduled task. This is used to automatically invalidate the distributed lock if the service instance holding the distributed lock encounters an exception and is unable to actively release the lock.

[0009] Optionally, the method also includes: In response to the detection that the remaining validity period of the distributed lock is less than a preset threshold and the business program of the scheduled task is still executing, a third instruction is sent to the distributed storage service, which instructs the distributed service to extend the validity period of the key-value pair associated with the lock identifier.

[0010] Optionally, the method also includes: If the initial acquisition operation returns a failure response, the distributed lock is reacquired until the preset maximum number of retries is reached or a success response is received.

[0011] Secondly, a scheduled task processing apparatus is provided, applied to multiple service instances executing the same application service, wherein the multiple service instances are isolated from each other and configured with the same scheduled task; the apparatus includes: The sending unit, in response to the triggering event of the scheduled task, sends a request to the shared distributed storage service to acquire the distributed lock based on the distributed lock acquisition program pre-embedded in the scheduled task; the distributed lock represents the permission credential that the scheduled task can execute. The execution unit is used to execute the business program corresponding to the scheduled task in response to the successful acquisition of the distributed lock. The skip unit is used to skip the business program corresponding to the scheduled task in response to the failure to acquire the distributed lock.

[0012] Thirdly, an electronic device is provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements any of the methods of the first aspect.

[0013] Fourthly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements any of the methods of the first aspect.

[0014] This invention provides a method, apparatus, electronic device, and storage medium for handling scheduled tasks. In response to a scheduled task trigger event, it acquires a distributed lock from a shared distributed storage service based on a distributed lock acquisition program pre-embedded in the scheduled task. Upon successful acquisition of the distributed lock, it executes the business program corresponding to the scheduled task; upon failure to acquire the distributed lock, it skips the execution of the business program. This invention cleverly solves the problem of repeated execution of scheduled tasks in a microservice multi-instance environment by directly embedding the distributed lock acquisition logic within the scheduled task method body and utilizing the shared distributed storage service as a coordination intermediary. Furthermore, it eliminates the need for any external components, achieving lightweight design and maintaining the simplicity and low maintenance costs of the original architecture.

[0015] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments 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.

[0017] Figure 1 A flowchart of a timed task processing method provided by an embodiment of the present invention is shown; Figure 2 A flowchart of another timed task processing method provided by an embodiment of the present invention is shown; Figure 3 A schematic diagram of the structure of a timed task processing device provided in an embodiment of the present invention is shown; Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present invention is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0019] In a microservices architecture, to improve system availability, multiple instances of the same application service are typically deployed. These instances are configured identically, all containing the same monolithic scheduled task logic. Because each instance is isolated and runs independently, when the monolithic scheduled task is triggered, all instances will execute the same business operation simultaneously. For example, if the scheduled task is used by a vehicle networking platform to send payment notifications to users, the same user may receive multiple duplicate SMS messages. Such duplicate execution not only severely impacts user experience but also wastes computing resources and incurs additional operating costs.

[0020] Based on this, embodiments of the present invention provide a method and apparatus for processing timed tasks, which are described below through embodiments.

[0021] This invention provides a method for processing scheduled tasks, applied to multiple service instances executing the same application service, wherein the multiple service instances are isolated from each other and configured with the same scheduled tasks; for example... Figure 1 As shown, it includes the following steps: Step S101: In response to the triggering event of the scheduled task, obtain a distributed lock from the shared distributed storage service based on the distributed lock acquisition program pre-embedded in the scheduled task.

[0022] In this embodiment of the invention, when the microservice cluster is built using the Spring framework, scheduled tasks are written using the `@Scheduled` annotation. The triggering event for the scheduled task refers to the task startup signal generated by the Spring framework based on the cron expression or fixed delay configuration in the `@Scheduled` annotation. For example, `@Scheduled(cron="002...` The message "?" will be triggered once a day at 2 AM.

[0023] This embodiment does not rely on external components, such as rebuilding a distributed framework, to solve the problem of recurring scheduled tasks, as that would be too costly. Instead, it embeds a distributed lock acquisition program into the scheduled task in advance, requiring only two lines of code to acquire and release the distributed lock in the @Scheduled annotation. This embedded control flow ensures that the entire solution does not require changing existing development habits, only adding a small amount of coordination code, achieving tight coupling with business logic while maintaining a lightweight architecture.

[0024] Shared distributed storage services refer to third-party middleware that can be accessed by all service instances, such as Redis and Memcached. Their core function is to provide a globally consistent coordination space.

[0025] The distributed lock is represented here as a permission credential, meaning that only instances that successfully obtain this credential from the storage service are allowed to continue executing subsequent business operations.

[0026] Step S102: In response to the successful acquisition of the distributed lock, execute the business program corresponding to the scheduled task.

[0027] Continuing from the previous example, once the service instance successfully acquires the distributed lock (i.e. obtains the license credential) in step S101, it enters the business execution phase.

[0028] The business procedure here refers to the core functional logic code that the task was originally supposed to complete, such as querying the database for all users who have overdue payments and calling the SMS gateway API to send payment reminders to each of them.

[0029] In this embodiment of the invention, the execution of this step is controlled, provided that the execution qualification of the current instance has been verified by a distributed lock.

[0030] Step S103: In response to the failure to acquire the distributed lock, skip the execution of the business program corresponding to the scheduled task.

[0031] It should be noted that not all instances can successfully acquire the distributed lock. For service instances that fail to acquire the lock in step S101, the behavior is clear: the current scheduled task method exits immediately without executing any business logic.

[0032] This step is crucial to preventing duplicate execution. For example, if three instances A, B, and C simultaneously trigger a task at 2 AM, assuming only instance A successfully acquires the lock, instances B and C will directly terminate the method call and silently exit when they reach step S103. The user will only receive one SMS message from instance A, thus effectively avoiding the problem of duplicate notifications.

[0033] This embodiment cleverly solves the problem of repetitive execution of scheduled tasks in a microservice multi-instance environment by directly embedding the distributed lock acquisition logic within the scheduled task method body and utilizing a shared distributed storage service as a coordination intermediary. Furthermore, it eliminates the need for any external components, achieving lightweight design and maintaining the simplicity and low maintenance costs of the original architecture.

[0034] Based on the above embodiments, sending a request to acquire a distributed lock to the shared distributed storage service includes: Step S101A: Send a first instruction containing a lock identifier and a unique request identifier to the shared distributed storage service.

[0035] The first instruction tells the distributed storage service to create a key-value pair associated with the lock identifier and return a successful retrieval response if it determines that the lock identifier is not occupied; otherwise, it returns a failed retrieval response.

[0036] For example, this step can be implemented using the RedisTemplate provided by SpringDataRedis, by calling its opsForValue().setIfAbsent(lockKey,requestId,TimeUnit.SECONDS) method.

[0037] Here, lockKey is a preset lock identifier (such as "lock:sendOverdueNotice"), and requestId is a unique request identifier generated by the current instance (such as UUID).

[0038] This operation sends a setup command to the distributed storage service. If the specified lockKey does not exist, it creates the key-value pair and returns true (successful acquisition); otherwise, it returns false (acquisition failed). In this way, only one of multiple concurrent requests will successfully obtain the license credential.

[0039] Although locks are acquired by sending commands to a shared distributed storage service, if the command itself is not atomic—that is, if checking for lock existence and setting the lock are split into two independent operations—then in high-concurrency scenarios, multiple instances may simultaneously determine that the lock does not exist and attempt to set it, ultimately leading to a race condition where multiple instances believe they have acquired the lock. To completely eliminate this risk, it is essential to ensure that the lock acquisition process is an indivisible, holistic operation.

[0040] Therefore, based on the above embodiments, the first instruction is an atomic operation instruction provided by the distributed storage service, which is used to complete the determination of the occupancy status of the lock identifier and the setting of the key-value pair in an indivisible operation.

[0041] In this embodiment of the invention, Redis is used as an example of a distributed storage service, and the command is SET keyvalueNXEX seconds.

[0042] The NX parameter means "set only if the key does not exist" (NoteXists), and the EX parameter is used to set the key's expiration time (Expire). This single command is executed internally by Redis as an atomic operation, combining the actions of "checking if the key exists" and "setting the key-value pair" into an indivisible step.

[0043] For example, when service instances A and B send this command almost simultaneously, the Redis service processes the two requests serially. The first request will find that the key does not exist, successfully create the key-value pair, and return success; when the second request arrives, the key already exists, so it will return failure directly.

[0044] This mechanism fundamentally guarantees that only one instance can successfully acquire the lock under any circumstances. Continuing from the previous example, this atomicity guarantee is the cornerstone of the reliability of the entire distributed lock scheme. It allows upper-layer applications to disregard the underlying concurrency details, relying solely on the execution result of the atomic instruction. By enforcing the use of atomic operation instructions, concurrency security vulnerabilities caused by non-atomic operations are completely eliminated, ensuring the absolute correctness of the distributed lock acquisition logic.

[0045] Based on the above embodiments, such as Figure 2 As shown, the method also includes: Step S104: In response to the event that the business program has completed execution, a second instruction containing a lock identifier and a unique request identifier is sent to the distributed storage service based on the distributed lock release procedure pre-embedded in the scheduled task.

[0046] The second instruction directs the distributed storage service to delete the key-value pair when verifying that the value currently associated with the lock identifier matches the unique request identifier.

[0047] In this embodiment of the invention, the unique request identifier is generated when the lock is acquired in step S101A and stored as a key value in the distributed storage service.

[0048] When releasing the lock, the service instance sends the same unique request identifier used when acquiring the lock, along with the lock identifier, to the distributed storage service.

[0049] Specifically, Lua scripts can be used because Redis executes Lua scripts atomically. The script's logic is as follows: first, it retrieves the value corresponding to the lock identifier; then, it compares this value with the passed-in unique request identifier; only if the two match exactly, does it perform the delete operation.

[0050] For example, a Lua script could be expressed as: "If redis.call('get',KEYS[1]) equals ARGV[1], then return redis.call('del',KEYS[1]), otherwise return 0". In this way, it is possible to prevent one instance from accidentally releasing a lock held by another instance.

[0051] For example, even if instance A's lock has expired, when it attempts to release it, the deletion operation will be rejected because its unique request identifier does not match the value of the current key (which belongs to instance B).

[0052] This embodiment greatly enhances the security of the distributed lock release process by introducing a holder identity verification mechanism, effectively avoiding concurrency out-of-control problems caused by accidentally deleting someone else's lock, and ensuring the long-term stable operation of the system.

[0053] In the aforementioned embodiments, despite the existence of a secure release mechanism, if the service instance holding the lock experiences a serious failure while executing business logic (such as process crash or server downtime), it will never be able to execute the code to release the lock. This results in the distributed lock existing indefinitely, preventing any subsequent scheduled tasks from being executed by any instance, and the system enters a deadlock state.

[0054] Therefore, based on the above embodiments, the first instruction also includes the lock's effective duration, which is longer than the estimated execution duration of the business program corresponding to the scheduled task, and is used to make the distributed lock automatically invalidate when the service instance holding the distributed lock encounters an anomaly and cannot actively release the lock.

[0055] In this embodiment of the invention, the effective duration is set when the first instruction is sent in step S101A.

[0056] This time value needs to be carefully evaluated and should be slightly longer than the maximum execution time of the business process under normal circumstances. For example, if the task of sending a payment reminder SMS usually takes less than 10 seconds, then the effective duration can be set to 30 seconds.

[0057] As mentioned earlier, this can be achieved through Redis's EX parameter. Once the lock is created, Redis starts a countdown timer; once the timer reaches zero, the key-value pair will be automatically deleted regardless of whether the holder actively releases it.

[0058] Continuing from the previous example, even if instance A suddenly crashes while executing a task, the lock will automatically disappear after 30 seconds. When the next scheduled task is triggered (such as at 2 a.m. the next day), other instances (B or C) can successfully acquire the new lock and execute the task.

[0059] This embodiment effectively prevents permanent deadlocks caused by abnormal service instance crashes by introducing a mandatory timeout mechanism, ensuring the sustainability of scheduled tasks and the high availability of the system.

[0060] In the aforementioned embodiments, while the timeout mechanism can prevent deadlocks, it presents new challenges for long tasks with uncertain execution times or those that may exceed the preset validity period. If the actual execution time of the task exceeds the lock's validity period, the lock will expire prematurely. At this time, other instances may acquire the lock and begin execution, causing the task to be executed repeatedly.

[0061] Therefore, based on the above embodiments, the method further includes: Step S105: In response to detecting that the remaining validity period of the distributed lock is lower than a preset threshold and the business program of the scheduled task is still executing, a third instruction is sent to the distributed storage service.

[0062] The third instruction instructs the distributed service to extend the validity period of the key-value pair associated with the lock identifier.

[0063] In this embodiment of the invention, after a service instance successfully acquires the lock and begins executing a long-running task, it starts a background daemon thread (or watchdog thread). This thread periodically (e.g., every 10 seconds) checks whether the current task is still running and queries the remaining validity period of the distributed lock.

[0064] When the remaining time is less than a preset safety threshold (such as 5 seconds), the daemon thread will send a third instruction to the distributed storage service, namely an instruction to update the expiration time.

[0065] For example, in Redis, you can use the PEXPIRE or EXPIRE command to reset the TTL (TimeToLive) of a key.

[0066] For example, as long as the business logic of the scheduled task has not ended, the daemon thread will continue to extend the lock's life, ensuring that it remains valid throughout the entire task execution. Once the business logic is completed, the daemon thread will be notified to stop, and will no longer perform renewal operations. The lock will then expire naturally after the validity period following the last renewal.

[0067] This embodiment perfectly resolves the contradiction between long task execution and fixed lock timeout through a dynamic renewal mechanism, ensuring that the task is not interrupted while maintaining the security of the lock, thus greatly expanding the applicability of the present invention.

[0068] In the aforementioned embodiments, if a service instance fails to acquire the lock on its first attempt, it immediately abandons execution. However, in some scenarios, there may be momentary network jitter or brief resource contention, causing an instance that should have successfully acquired the lock to fail due to millisecond-level latency.

[0069] Therefore, in order to improve the system's resilience and the success rate of tasks, based on the above embodiments, the method further includes: Step S106: In response to the failure response returned by the first acquisition operation, retry the acquisition operation.

[0070] The retry operation includes: after a preset waiting time, reacquiring the distributed lock from the distributed service until the preset maximum number of retries is reached or a successful response is received.

[0071] In this embodiment of the invention, the preset waiting time is usually a very short interval, such as 100 milliseconds, to avoid excessive consumption of resources.

[0072] The maximum number of retries should also be set to a small value, such as 3, to prevent the scheduled task thread from being blocked for a long time.

[0073] For example, after service instance B fails to acquire the lock on its first attempt, it will not exit immediately but will wait 100 milliseconds before trying again. During these 100 milliseconds, instance A, which holds the lock, may have already completed its task and released the lock, so instance B may succeed on its second attempt.

[0074] This strategy is particularly effective for tasks that are executed at extremely high speeds.

[0075] This embodiment enhances the system's tolerance to transient failures and improves the robustness and reliability of scheduled tasks by introducing lightweight retry logic.

[0076] Based on the same inventive concept, this embodiment provides a timed task processing device, applied to multiple service instances executing the same application service, wherein the multiple service instances are isolated from each other and configured with the same timed task; such as Figure 3 As shown, the device includes: The sending unit 301 is used to respond to the triggering event of the scheduled task and send a request to the shared distributed storage service to acquire the distributed lock based on the distributed lock acquisition program pre-embedded in the scheduled task; the distributed lock represents the permission credential that the scheduled task can be executed. Execution unit 302 is used to execute the business program corresponding to the scheduled task in response to the successful acquisition of the distributed lock; Skip Unit 303 is used to skip the business program corresponding to the scheduled task in response to the failure to acquire the distributed lock.

[0077] Based on the same technical concept, embodiments of the present invention also provide an electronic device, such as... Figure 4As shown, it includes a processor 401, a communication interface 402, a memory 403, and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404.

[0078] Memory 403 is used to store computer programs; The processor 401 is used to implement the steps of the timed task processing method when executing the program stored in the memory 4003.

[0079] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0080] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0081] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0082] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0083] In another embodiment of the present invention, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described timed task processing methods. Specific implementation details can be found in the method embodiments and will not be repeated here.

[0084] The timed task processing apparatus provided in this embodiment of the invention can be specific hardware on a device or software or firmware installed on the device. The implementation principle and technical effects of the apparatus provided in this embodiment of the invention are the same as those in the foregoing method embodiments. For the sake of brevity, any parts not mentioned in the apparatus embodiments can be referred to the corresponding content in the foregoing method embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, apparatuses, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0085] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and method can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] In addition, the functional units in the embodiments provided by the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0088] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0090] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. All should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for processing timed tasks, characterized in that, The method is applied to multiple service instances that execute the same application service, wherein the multiple service instances are isolated from each other and configured with the same scheduled task; the method includes: In response to the triggering event of the scheduled task, a distributed lock is obtained from the shared distributed storage service based on the distributed lock acquisition program pre-embedded in the scheduled task; the distributed lock represents the license credential that the scheduled task can be executed. In response to the successful acquisition of the distributed lock, the business program corresponding to the scheduled task is executed. In response to the failure to acquire the distributed lock, the execution of the business program corresponding to the scheduled task is skipped.

2. The method according to claim 1, characterized in that, Sending a request to acquire a distributed lock to a shared distributed storage service includes: A first instruction containing a lock identifier and a unique request identifier is sent to the shared distributed storage service. The first instruction instructs the distributed storage service to create a key-value pair associated with the lock identifier and return a successful retrieval response if it determines that the lock identifier is not occupied; and to return a failed retrieval response if it determines that the lock identifier is occupied.

3. The method according to claim 2, characterized in that, The first instruction is an atomic operation instruction provided by the distributed storage service, used to complete the determination of the occupancy status of the lock identifier and the setting of the key-value pair in an indivisible operation.

4. The method according to claim 2, characterized in that, The method further includes: In response to the completion of the business program execution, based on the distributed lock release procedure pre-embedded in the scheduled task, a second instruction containing the lock identifier and the unique request identifier is sent to the distributed storage service. The second instruction instructs the distributed storage service to delete the key-value pair when verifying that the value currently associated with the lock identifier is consistent with the unique request identifier.

5. The method according to claim 2, characterized in that, The first instruction also includes the lock's validity period, which is longer than the estimated execution time of the business program corresponding to the scheduled task. This is used to automatically invalidate the distributed lock if the service instance holding the distributed lock encounters an anomaly and is unable to actively release the lock.

6. The method according to claim 5, characterized in that, The method further includes: In response to detecting that the remaining validity period of the distributed lock is less than a preset threshold and the business program of the scheduled task is still executing, a third instruction is sent to the distributed storage service, the third instruction instructing the distributed service to extend the validity period of the key-value pair associated with the lock identifier.

7. The method according to claim 1, characterized in that, The method further includes: If the initial acquisition operation returns a failure response, the distributed lock is reacquired until the preset maximum number of retries is reached or a success response is received.

8. A timed task processing device, characterized in that, A device is used to execute multiple service instances of the same application service, wherein the multiple service instances are isolated from each other and configured with the same scheduled task; the device includes: A sending unit is configured to, in response to a triggering event of the scheduled task, acquire a distributed lock from a shared distributed storage service based on a distributed lock acquisition program pre-embedded in the scheduled task; the distributed lock represents a license credential that allows the scheduled task to execute. The execution unit is used to execute the business program corresponding to the scheduled task in response to the successful acquisition of the distributed lock. The skip unit is used to skip the execution of the business program corresponding to the scheduled task in response to the failure of the distributed lock acquisition.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes the program stored in the memory, it implements the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images