Distributed timed task management method and device, equipment and storage medium

Abstract

The invention relates to the technical field of distributed system management and the field of financial science and technology, and discloses a distributed timed task management method, which is used for creating a project based on Spring Boot, configuring Redis to carry out task storage and management, and defining a timed task base class to realize a timed task scheduling function. And setting a task execution plan by using the (at) Scheduled annotation, configuring an execution range and a thread number of a task, generating a unique identifier, and recording task state information, including execution time and execution frequency. Before the task is executed, the task is intercepted through the aspect, whether the task is executed or not is judged according to the state information, and task execution information is generated in the execution process and updated to Redis in real time. After task execution is finished, the execution process information is integrated into final execution state information, and the final execution state information is synchronized to the Redis. Task state sharing and consistency management are realized among a plurality of nodes by means of Redis. According to the invention, the phenomenon of repeated execution or missed execution of the task is effectively avoided, and the execution efficiency of the distributed task and the stability of the system are improved.

Description

Technical Field

[0001] The present invention relates to the field of distributed system management technology and financial technology, and in particular to a distributed scheduled task management method, device, equipment and storage medium. Background Art

[0002] With the rapid development of financial industry business and the expansion of service applications, the number of scheduled tasks in the backend service cluster of financial institutions has increased from a few to dozens or even hundreds. In order to meet business needs, the distributed management of scheduled tasks has become particularly important. However, traditional scheduled task management systems, such as ElasticJob, have gradually exposed their shortcomings in scalability and performance.

[0003] In the financial system, ElasticJob was widely used to implement distributed scheduled task scheduling, relying on Zookeeper for node management and task coordination. However, as the number of tasks increased, the solution faced the following key problems:

[0004] There are too many object initialization categories: There are too many different scheduled task object initialization categories, which increases the complexity of the system during task initialization.

[0005] Loading time and memory consumption issues: As the number of scheduled tasks increases, the system takes too long to start and load tasks, and consumes a lot of memory resources, affecting system performance.

[0006] Dependency issues: ElasticJob and Zookeeper have close dependencies and strict version requirements, which makes the project too complicated and bloated during development and deployment.

[0007] Therefore, current financial institutions have put forward higher requirements for scheduled task management solutions. Not only do they need to solve the scalability problem of task scheduling, but they must also optimize the efficiency of task loading and reduce the occupation of system resources. In addition, it is necessary to find a lighter-weight distributed task management solution to reduce the system's excessive dependence on middleware such as Zookeeper and ElasticJob, and achieve more flexible task scheduling and management. Summary of the invention

[0008] The main purpose of the present invention is to provide a distributed scheduled task management method, device, equipment and storage medium, aiming to solve the technical problems that the prior art is difficult to ensure the consistency of tasks between multiple nodes in distributed scheduled task management, and is prone to repeated execution or missed execution.

[0009] To achieve the above object, the present invention provides a distributed scheduled task management method, comprising:

[0010] Create a project based on Spring Boot, configure Redis to store and manage distributed scheduled tasks, and define the scheduled task base class to enable the scheduled task scheduling function;

[0011] In the scheduled task base class, the @Scheduled annotation is used to define the execution plan of the task, establish a task management mechanism, configure the execution scope and thread number of the task, and generate a unique identifier for each distributed scheduled task;

[0012] Record the task status information of each distributed scheduled task, including the task execution time, execution frequency and unique identifier;

[0013] Define a task execution method in a scheduled task base class, and trigger the task based on the execution time and the execution frequency;

[0014] Intercept the execution process of distributed scheduled tasks through aspect programming, and determine the execution conditions based on task status information before the task is executed;

[0015] During the task execution process, the task execution information is generated and recorded, and updated to Redis to reflect the progress of the task;

[0016] When the task is completed, the task execution process information is integrated into the final execution status information and updated to Redis to record the execution status of the task.

[0017] In one embodiment, a task management mechanism is established to configure the execution scope and thread number of the task, including:

[0018] Create a custom annotation RedisJob to mark scheduled tasks that require distributed management;

[0019] Set the distributed execution attribute of the task in the RedisJob annotation to determine whether the task needs to be coordinated and executed among multiple nodes;

[0020] Configure the execution scope of the task in the RedisJob annotation to determine the resources or target services used when executing the task;

[0021] Specify the thread number of the task in the RedisJob annotation to control the execution order of tasks in multiple threads;

[0022] In the RedisJob annotation, set whether the task is executed on a single node;

[0023] During the task scheduling process, the distributed execution mode of the task is determined according to the configuration information in the RedisJob annotation, and the distributed scheduled tasks are assigned to the set nodes or threads for execution according to the distributed execution mode.

[0024] In one embodiment, the execution process of the distributed scheduled task is intercepted by aspect programming, including:

[0025] Use Aspect to implement the surround interception method and intercept the distributed scheduled tasks annotated with RedisJob;

[0026] Store BaseScheduleObject information in Redis and ScheduleHashmap data in the local service;

[0027] Through the intercepted RedisJob annotated method name, the task execution parameters are extracted from BaseScheduleObject and ScheduleObject, and the execution mode of distributed scheduled tasks is managed according to the extracted execution parameters;

[0028] Execute distributed scheduled tasks based on the extracted execution parameters.

[0029] In one embodiment, a scheduled task base class is defined to start the scheduled task scheduling function, including:

[0030] Create a scheduled task base class and inject it into the application context as a Spring Bean to manage and execute distributed scheduled tasks;

[0031] Add the @EnableScheduling annotation to the scheduled task base class to enable the scheduled task scheduling function so that the task is executed according to the predetermined time period;

[0032] If the task needs to be executed in parallel in multiple threads, add the @EnableAsync annotation to the scheduled task base class to enable the asynchronous execution function.

[0033] In one embodiment, the task status information of each distributed scheduled task is recorded, including:

[0034] Define the basic task status object BaseScheduleObject to store the basic information of distributed scheduled tasks;

[0035] When the Spring Boot application is initialized, the basic task state object BaseScheduleObject is associated with the scheduled task scheduling function;

[0036] Configure the task attributes including the task execution time, execution status and execution node in the basic task status object BaseScheduleObject;

[0037] Create an extended task status object ScheduleObject, and inherit the structure of BaseScheduleObject through ScheduleObject;

[0038] Configure the execution parameters of the distributed task in the extended task state object ScheduleObject;

[0039] Bind the extended task status object ScheduleObject to the scheduled task scheduling function;

[0040] Adjust the task configuration information in the extended task status object ScheduleObject to be consistent with the task execution process.

[0041] In one embodiment, the execution process of the distributed scheduled task is intercepted by aspect programming, including:

[0042] When a scheduled task is triggered by the @Scheduled annotation, the execution of the distributed scheduled task with the RedisJob annotation is intercepted through the aspect;

[0043] The aspect extracts the execution conditions of the distributed scheduled tasks from the RedisJob annotation and reads the current status of the distributed scheduled tasks from Redis;

[0044] Based on the current state and execution condition of the distributed scheduled task, determine whether the distributed scheduled task needs to continue to be executed;

[0045] If the distributed scheduled task meets the execution conditions, the distributed scheduled task will be executed. If the distributed scheduled task fails to execute, it will be decided whether to re-execute according to the retry configuration of the distributed scheduled task, and the execution result of the distributed scheduled task will be recorded;

[0046] If the distributed scheduled task does not meet the execution conditions, it will be skipped.

[0047] In one embodiment, a project is created based on Spring Boot, and Redis is configured to store and manage distributed scheduled tasks, including:

[0048] Create a Spring Boot project and introduce dependencies that support scheduled task scheduling and Redis storage;

[0049] In the project configuration file, define the Redis connection parameters, including the host address, port number, and authentication information;

[0050] Initialize the Redis tool class to store and read task status in a distributed environment;

[0051] Before the task is executed, the current execution status of the task is read from Redis to determine whether the task meets the execution conditions. After the task is executed, the latest execution status of the task is updated;

[0052] The Redis consistency mechanism is used to synchronize the execution status of tasks among multiple nodes.

[0053] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a distributed scheduled task management device, which includes a memory, a processor, and a distributed scheduled task management program stored in the memory and executable on the processor, and the distributed scheduled task management program, when executed by the processor, implements the steps of the distributed scheduled task management method as described above.

[0054] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer storage medium, on which a distributed scheduled task management program is stored, and when the distributed scheduled task management program is executed by a processor, the steps of the distributed scheduled task management method as described above are implemented.

[0055] Beneficial effects: The present invention relates to a distributed scheduled task management method, which creates a project based on Spring Boot, configures Redis to store and manage tasks, and defines a scheduled task base class to implement the scheduled task scheduling function. Use the @Scheduled annotation to set the task execution plan, configure the execution scope and thread number of the task, generate a unique identifier, and record the task status information, including the execution time and execution frequency. Before the task is executed, the task is intercepted by the aspect, and whether to execute is determined based on the status information. During the execution process, the task execution information is generated and updated to Redis in real time. After the task is executed, the execution process information is integrated into the final execution status information and synchronized to Redis. Among multiple nodes, task status sharing and consistency management are achieved with the help of Redis. The present invention effectively avoids the phenomenon of repeated execution or missed execution of tasks, and improves the execution efficiency of distributed tasks and the stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0057] Figure 1 A schematic diagram of a flow chart of an embodiment of a distributed scheduled task management method of the present invention;

[0058] Figure 2 A schematic diagram of functional modules of a preferred embodiment of a distributed timed task management device of the present invention;

[0059] Figure 3It is a structural diagram of the device hardware operating environment involved in the embodiment of the distributed timed task management device of the present invention. DETAILED DESCRIPTION

[0060] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0061] With the rapid development of financial industry business and the expansion of service applications, the number of scheduled tasks in the backend service cluster of financial institutions has increased from a few to dozens or even hundreds. In order to meet business needs, the distributed management of scheduled tasks has become particularly important. However, traditional scheduled task management systems, such as ElasticJob, have gradually exposed their shortcomings in scalability and performance.

[0062] In the financial system, ElasticJob was widely used to implement distributed scheduled task scheduling, relying on Zookeeper for node management and task coordination. However, as the number of tasks increased, the solution faced the following key problems:

[0063] There are too many object initialization categories: There are too many different scheduled task object initialization categories, which increases the complexity of the system during task initialization.

[0064] Loading time and memory consumption issues: As the number of scheduled tasks increases, the system takes too long to start and load tasks, and consumes a lot of memory resources, affecting system performance.

[0065] Dependency issues: ElasticJob and Zookeeper have close dependencies and strict version requirements, which makes the project too complicated and bloated during development and deployment.

[0066] Therefore, current financial institutions have put forward higher requirements for scheduled task management solutions. Not only do they need to solve the scalability problem of task scheduling, but they must also optimize the efficiency of task loading and reduce the occupation of system resources. In addition, it is necessary to find a lighter-weight distributed task management solution to reduce the system's excessive dependence on middleware such as Zookeeper and ElasticJob, and achieve more flexible task scheduling and management.

[0067] See also Figure 1 , Figure 1 This is a flow chart of an embodiment of a distributed scheduled task management method provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0068] like Figure 1As shown, the distributed scheduled task management method proposed by the present invention includes the following steps:

[0069] S10, create a project based on Spring Boot, configure Redis to store and manage distributed scheduled tasks, and define the scheduled task base class to start the scheduled task scheduling function;

[0070] In this embodiment, the Spring Boot framework is used to create a project. Spring Boot provides a way to quickly build microservices and applications. Automatic configuration, dependency management, and rich extension functions can reduce development complexity. During the project creation process, developers can select multiple modules including Web, Redis, and scheduled task scheduling. Through Spring Boot's automatic configuration, the project startup and dependency loading steps are simplified.

[0071] Developers can create projects through tools such as Spring Initializr, and select appropriate dependencies when generating projects, such as scheduled task scheduling and Redis, and the system automatically configures and introduces dependency packages. Dependency management is performed through Maven or Gradle, and the project is initialized as a scalable distributed task management system.

[0072] Redis is a high-performance distributed storage system. As a tool for storing the task status and execution information of distributed scheduled tasks, it can ensure that the task status is shared among multiple nodes. Redis's key-value storage model allows information such as the task execution status and execution time to be stored in the form of key-value pairs, so that each node can read and update the task status in real time to ensure consistency.

[0073] In the Spring Boot project, set the Redis connection parameters through the configuration file, including host, port and other information, and use RedisTemplate or other data access components to store the task status information in Redis. By using the distributed lock function of Redis, avoid repeated execution or missed execution of tasks on multiple nodes.

[0074] The scheduled task base class is the core of scheduled task management. It defines the execution plan and scheduling mechanism of the task. Use Spring's @Scheduled annotation to set the execution time and frequency of the task so that the task can be triggered and executed at the set time point. The scheduled task base class is also responsible for managing the basic information of the task, such as the execution scope, thread number, etc., to ensure that the distributed task is executed at the correct node and time.

[0075] Developers create a scheduled task base class and use the @Scheduled annotation to define the task scheduling logic. The base class inherits other common task scheduling functions, such as task initialization, state management, etc. The functions of the base class can be extended as needed, such as adding distributed execution logic for tasks.

[0076] In one specific implementation, in a financial payment system, a large number of transaction records need to be cleared and settled regularly. Tasks must be executed across multiple nodes and the consistency of execution of each node must be ensured. In this scenario, the storage object of Redis adds relevant metadata and status information of the transaction records, and the task base class extends the retry logic for failed tasks. The project is quickly built through Spring Boot, and Redis is configured to store the status of transaction clearing tasks, including the execution time and execution status of each transaction. The scheduled task base class contains task allocation logic and adds a distributed lock function to ensure that a single task is only executed by one node at the same time to prevent concurrency conflicts. During the execution of the task, if node A fails to complete the task, the system automatically switches to node B to continue execution to ensure the fault tolerance of task execution.

[0077] By using Redis to store and manage task status information and combining it with a distributed timed task scheduling mechanism, we can achieve cross-node consistency management of tasks and avoid duplicate or missed execution of tasks. In practical applications, we can improve the fault tolerance and scalability of the distributed task scheduling system, and effectively improve the stability of the system and the efficiency of task execution.

[0078] S20, using the @Scheduled annotation in the scheduled task base class to define the execution plan of the task, establish a task management mechanism, configure the execution scope and thread number of the task, and generate a unique identifier for each distributed scheduled task;

[0079] In this embodiment, the @Scheduled annotation is a common annotation used in the Spring framework to define scheduled tasks. By using this annotation in the scheduled task base class, you can set the scheduling strategy such as the execution time and frequency of the task. This provides flexible configuration options for the automated execution of tasks, and supports the execution of tasks at fixed time intervals, specified date and time, or dynamic time parameters. In the scheduled task base class, the @Scheduled annotation is used to set specific scheduling rules for each task. Scheduling rules can be customized through cron expressions to implement more complex time control logic, such as executing tasks at a certain time point every day, or at regular intervals.

[0080] The task management mechanism refers to the overall architecture used to control the life cycle, allocation, execution, and status monitoring of tasks. The task management mechanism covers the initialization, scheduling, and execution control of tasks. It coordinates the distributed execution of tasks on multiple nodes to ensure that tasks are executed correctly within the specified time and avoid task conflicts or duplications. In the system, the task management mechanism tracks the execution progress and status information of each task to ensure that the information during the task execution process can be updated to Redis in a timely manner. Before the task starts to execute, the management mechanism first checks the execution conditions of the task and determines whether the task needs to be executed or skipped.

[0081] The execution scope is the definition of which node or service a task is assigned to in a distributed environment. Different tasks can be assigned to specific nodes for execution based on demand to optimize resource utilization and task execution efficiency.

[0082] The thread number is the thread identifier assigned to each task during task scheduling, which is used to control the parallel execution of tasks in the system. By assigning a specific thread number to each task, it can ensure that the tasks are executed in the set order to avoid resource competition or concurrency conflicts.

[0083] In order to ensure the uniqueness of tasks and scheduling consistency in a distributed environment, a unique identifier needs to be generated for each task. This identifier is used to identify the status, execution results, and node information of each task. During the task execution process, the unique identifier is used to query the status of the task and determine whether the task has been executed by other nodes to avoid repeated execution. The system generates a unique task ID for each distributed task, usually using UUID or other algorithms to generate the identifier. The task ID is stored in Redis as part of the task status and is used to synchronize the execution information of the task across nodes.

[0084] In one specific implementation, in financial data clearing, the execution frequency of tasks depends not only on fixed time intervals, but may also be triggered by external events (such as interbank settlement). By introducing an external event monitoring mechanism and combining it with the @Scheduled annotation, clearing task scheduling based on specific events or timetables is achieved.

[0085] In addition, clearing tasks require processing a large amount of transaction data in parallel on multiple nodes at the same time. The dynamic thread allocation mechanism can be used to dynamically adjust the thread number and execution scope of the task according to the load of the current node to ensure that tasks can be evenly distributed when the system is under high load.

[0086] By using the @Scheduled annotation to define the execution plan of the task, setting up a task management mechanism, and configuring the execution scope and thread number of the task, the scheduling consistency of distributed scheduled tasks between multiple nodes can be ensured to avoid repeated or missed execution of tasks. Generating a unique identifier ensures the independence of each task, enhances the accuracy and scalability of task management, and improves the overall performance and stability of the system.

[0087] S30, recording the task status information of each distributed scheduled task, including the execution time, execution frequency and unique identifier of the task;

[0088] In this embodiment, task status information is important data for tracking and managing task execution in a distributed system. By recording the status information of each task, the system can monitor the execution progress, status and results of the task. This information is usually stored in a distributed storage system such as Redis so that multiple nodes can share and access it in real time to ensure the consistency of task status in a distributed environment.

[0089] Task execution time refers to the time when the task actually starts or ends. Recording the task execution time can help the system track the specific execution time of the task, which is convenient for subsequent task auditing, scheduling optimization and other operations. The task execution time record can be stored in Redis in the form of a timestamp to ensure that all nodes can access the data at the same time point.

[0090] The execution frequency is the period or interval at which a task is scheduled, which defines when the task is triggered again. By recording the execution frequency, the system can automatically schedule tasks without manual intervention. For example, some tasks may need to be executed every 5 minutes. After recording the execution frequency, the system can schedule the task execution according to this rule.

[0091] A unique identifier is an identifier of a task in a distributed environment, usually generated by a UUID or other algorithm. It is used to ensure the uniqueness of tasks on different nodes and prevent repeated execution or confusion of tasks. Each task has its own unique identifier to distinguish between different tasks and to play a role in subsequent queries or tracking of task status.

[0092] In one specific implementation, the task status information is not updated through scheduled checks or polling, but based on an event-driven mechanism. When the task status changes, the event-driven mechanism will immediately trigger the task status update and push the latest status information to Redis to ensure the status synchronization between multiple nodes. The event-driven mechanism improves the real-time and response speed of the task status, avoids the delay problem caused by the traditional polling mechanism, and ensures that the task status update is more accurate.

[0093] By recording the execution time, execution frequency and unique identifier of the task, the execution progress of the task can be effectively monitored in the distributed system to prevent repeated or missed execution of the task. The real-time sharing and synchronization of task status information improves the stability of the system and the accuracy of task scheduling, especially in high-concurrency and multi-node scenarios, ensuring the consistency of task execution and the reliability of the system.

[0094] S40, defining a task execution method in a scheduled task base class, and triggering the task based on the execution time and the execution frequency;

[0095] In this embodiment, the scheduled task base class is the basic class of the entire task scheduling, which encapsulates the core logic of task execution. Each specific task will inherit the scheduled task base class and complete the business logic of the specific task by overwriting or extending the execution method. The core functions of the execution method include: trigger conditions for scheduling tasks, specific business processing procedures, data updates and other operations. This method provides a unified entry for task execution to ensure that all tasks can be executed correctly during scheduling.

[0096] The task status information includes data such as the execution time and execution frequency of each task. This information determines when and how often the task is triggered. Based on this status information, the system uses @Scheduled or a custom scheduling mechanism to trigger the execution of the task within the set time. The execution time refers to the actual triggering moment of the task, while the execution frequency is the interval period for repeated execution of the task. For example, the last execution time can be recorded through the task status, and the next execution time can be calculated based on the frequency to ensure that the task is triggered according to the predetermined plan.

[0097] In one specific implementation, the task status information automatically adjusts the execution frequency of the task according to the system load. When the task is executed, the system will dynamically adjust the task frequency according to the current load information. For example, the execution interval is extended when the load is high, and the execution interval is shortened when the load is low. The task status information records the current load situation and the task execution frequency to adapt to different execution scenarios. It is suitable for resource-sensitive systems, and the task execution frequency can be dynamically adjusted according to the system load to ensure the rational use of system resources.

[0098] By defining the execution method of tasks in the scheduled task base class, the execution logic of distributed tasks can be managed uniformly. Tasks are triggered based on execution time and execution frequency, ensuring automatic scheduling and flexible execution of tasks, avoiding delays or repeated scheduling of tasks.

[0099] S50, intercepting the execution process of the distributed scheduled task through aspect programming, and determining the execution condition according to the task status information before the task is executed;

[0100] In this embodiment, aspect programming (AOP, aspect-oriented programming) is a technology for dynamically intercepting method execution by separating cross-cutting concerns (such as logging, transaction management) from business logic. Using AOP to intercept the execution process of distributed scheduled tasks allows additional processing or judgment before and after task execution. By intercepting the execution of scheduled tasks, the behavior of the task can be controlled, such as recording the start and completion time of the task, or deciding whether to execute the task based on the status of the task. Aspects can be applied to the method of task execution by using SpringAOP or AspectJ. The aspect intercepts method calls when the task is executed, and decides whether to continue executing the task based on predefined logic (such as task status). Through AOP, additional functions such as logging, permission control, task status checking, etc. can be added without modifying the business logic code.

[0101] Task status information includes the current execution status, last execution time, execution frequency, and other information of the task. These data are used to determine whether the task meets the execution conditions. By reading the task status information before the task is executed, the system can determine whether the current task should be executed to avoid repeated execution of the task or execution at the wrong time. In the AOP aspect, before the task actually starts executing, the system reads the task status information from the storage (such as Redis). Based on this information (such as the last execution time and current status of the task), it is determined whether the task meets the execution conditions. If the task meets the conditions, the task is allowed to execute; if the conditions are not met, the task is skipped or delayed.

[0102] In one specific implementation, the aspect intercepts the execution of each distributed scheduled task and reads the last execution time in the task status before the task is executed. If the time interval between the task and the current one is less than the set execution frequency, the aspect will prevent the task from being executed to ensure that the task is not triggered repeatedly. Ensure that the task is executed at the specified time interval to avoid over-scheduling of tasks when system resources are busy. For example, if the task is required to be executed every 10 minutes, the aspect will prevent it from being executed before the execution time.

[0103] By intercepting the execution process of distributed scheduled tasks through aspect programming, the execution behavior of tasks can be effectively controlled. Before the task is executed, the system determines whether the task should be executed based on the task status information, avoiding repeated execution of tasks and unnecessary scheduling operations. The introduction of aspect programming makes the execution of tasks more flexible. The system can dynamically adjust the execution conditions and order of tasks, improving the flexibility of task scheduling and the utilization efficiency of system resources. At the same time, the task retry mechanism further enhances the reliability of task execution.

[0104] S60, during the task execution process, generating and recording the task execution information, and updating it to Redis to reflect the progress of the task;

[0105] In this embodiment, the execution information of a task refers to the relevant data and status generated during the execution of the task. It includes the start time, execution time, execution result (success or failure), consumed resources, etc. of the task. By generating this information, the system can track the progress of the task and perform status updates and monitoring after the task is executed. Task execution information is not only used for auditing and logging, but also helps with subsequent task scheduling and optimization. When a task starts to execute, the system generates a set of task execution information. This information can be generated by calling the corresponding recording function in the task execution method. Each time a task is executed, the information will be updated in real time to record the current execution status, whether the task is successful, etc. The generated task execution information will be saved in the memory and submitted to the storage system when the task is completed.

[0106] After the task execution information is generated, it needs to be synchronized to a distributed storage system (such as Redis). Redis is an efficient distributed key-value storage that can store the execution status of tasks in real time and share this information among multiple nodes. By storing the execution information of tasks in Redis, the system can update the progress of tasks in real time and ensure that all nodes can access the latest task status.

[0107] During the task execution process, the system will update the task execution information (such as execution time, status, etc.) to Redis. Every time the task status changes, the system will send an update request to Redis to synchronize the latest execution information to the storage. In this way, multiple distributed nodes can obtain the latest task execution progress and prevent problems such as repeated task execution or inconsistent status.

[0108] In one specific implementation, during the task execution process, the task execution information can be first stored in the local memory, and then the information can be updated to Redis in batches when the task execution is completed. This method reduces the frequent update operations of Redis and is suitable for scenarios where the task execution time is short and there is no need to update the status in real time. It is suitable for situations where real-time task status is not required, reducing the writing pressure on Redis, but all the status of the task will be updated at once when the task execution is completed.

[0109] By generating and recording the execution information of tasks during the execution of tasks, real-time monitoring and progress tracking of task execution status can be achieved. Updating the execution information of tasks to Redis ensures that multiple nodes can share the latest task status and avoid duplicate execution or omission of tasks. The execution information recording of tasks is helpful for subsequent scheduling optimization and system monitoring, enhancing the controllability and reliability of task management and improving the task scheduling efficiency of the system.

[0110] S70, when the task is completed, the execution process information of the task is integrated into the final execution status information, and updated to Redis to record the execution status of the task.

[0111] In this embodiment, the execution process information of the task includes all the status and operation records of the task from the beginning to the completion, including the start time of the task, the execution time, whether the task is successful or not, the reason for failure, etc. These process information will be integrated into a simplified and final execution status information when the task is completed. The status information usually includes whether the task is successful, the execution time, the final result, etc. The purpose of this step is to generate a concise status report by integrating the information during the execution process, which is convenient for system monitoring and log management.

[0112] During the task execution, the system will continuously record the task status and logs. At the end of the task execution, the system will integrate this information and generate a final execution status report, including the task result (success or failure), execution time, resource consumption, etc. This final status information is the summary information of the task, which is used for subsequent monitoring and auditing.

[0113] After the task is completed, the system will update the integrated task execution status information to the Redis database through the Redis API. The status information is stored as a key-value pair, including the unique identifier of the task and the corresponding status data. Other modules or nodes of the system can understand the final result of the task by reading this status information, and use it for task scheduling, retrying or auditing.

[0114] Update the final execution status information of the task to Redis to ensure that the task execution information can be shared and queried. As an efficient distributed key-value storage, Redis can store the final execution status of the task and allow multiple nodes to access this information. Ensure that the execution results of the task are recorded in the system for easy query and subsequent processing. Multiple nodes can access these records through Redis to understand the execution results and status of the task.

[0115] In one specific implementation, after the task is executed, the system will store different task status information in different namespaces of Redis according to the type and priority of the task. For example, the execution status of critical tasks is stored in the high-priority namespace, and ordinary tasks are stored in the regular namespace. This classified storage method helps to give priority to accessing the information of critical tasks under high load and improve the access efficiency of task status. It is suitable for scenarios where task execution information needs to be classified and managed, and helps the system obtain key information more efficiently when querying tasks.

[0116] By integrating the task execution process information into the final execution status information when the task is completed and updating it to Redis, efficient recording and sharing of task execution results are achieved. The system can quickly understand the execution status of the task through this status information, ensuring that the complete execution record of the task can be tracked and queried. Synchronizing status information to Redis improves the transparency of task scheduling and monitoring, helps prevent repeated execution of tasks or status loss, and further enhances the stability of the system and the accuracy of task scheduling.

[0117] The present invention relates to a distributed scheduled task management method. A project is created based on Spring Boot, Redis is configured to store and manage tasks, and a scheduled task base class is defined to implement a scheduled task scheduling function. The @Scheduled annotation is used to set a task execution plan, configure the execution scope and thread number of the task, generate a unique identifier, and record task status information, including execution time and execution frequency. Before the task is executed, the task is intercepted by a section, and whether to execute is determined based on the status information. During the execution process, task execution information is generated and updated to Redis in real time. After the task is executed, the execution process information is integrated into the final execution status information and synchronized to Redis. Among multiple nodes, task status sharing and consistency management are implemented with the help of Redis. The present invention effectively avoids the phenomenon of repeated execution or missed execution of tasks, and improves the execution efficiency of distributed tasks and the stability of the system.

[0118] In one embodiment, in the above S20, a task management mechanism is established to configure the execution scope and thread number of the task, including:

[0119] S201, create a custom annotation RedisJob to mark scheduled tasks that require distributed management;

[0120] S202, setting the distributed execution attribute of the task in the RedisJob annotation to determine whether the task needs to be coordinated and executed among multiple nodes;

[0121] S203, configuring the execution scope of the task in the RedisJob annotation, and determining the resources or target services used when executing the task;

[0122] S204, specifying the thread number of the task in the RedisJob annotation to control the execution order of the task in multiple threads;

[0123] S205, setting whether the task is executed on a single node in the RedisJob annotation;

[0124] S206, during the task scheduling process, the distributed execution mode of the task is determined according to the configuration information in the RedisJob annotation, and the distributed scheduled task is assigned to the set node or thread for execution according to the distributed execution mode.

[0125] In this embodiment, RedisJob is a custom annotation used to mark specific tasks as requiring distributed execution. By using annotations, developers can clearly identify which tasks need to be coordinated across multiple nodes, thereby simplifying the configuration process of distributed tasks. This annotation provides an intuitive way to mark and manage distributed tasks.

[0126] Developers write custom annotations @RedisJob and apply them to scheduled tasks that require distributed execution. The annotations themselves can contain additional metadata, such as distributed execution attributes, execution scope, and thread number, which are read and processed by the system during task scheduling.

[0127] The distributed execution attribute is used to determine whether a task needs to be executed collaboratively on multiple nodes. For example, a task may need to be coordinated between different physical nodes, or only executed on a single node. By setting the distributed execution attribute, the system can determine the execution method of the task based on this attribute when scheduling the task.

[0128] Add an attribute field to the custom annotation RedisJob, allowing developers to set the distributed execution attributes of the task (such as whether to enable distributed execution, multi-node coordination strategy, etc.). The task scheduling system will parse this attribute when reading the annotation and determine the distributed execution strategy of the task accordingly.

[0129] The execution scope of a task determines which resources or target services the task will be executed on. For example, some tasks may only run on specific servers, databases, or service nodes. By configuring the execution scope, the system can allocate appropriate resources according to the requirements of the task to ensure that the task is executed in the intended environment. Defining the execution scope attribute of a task in an annotation allows developers to specify the execution environment or node range of the task. When scheduling tasks, the system will allocate resources based on this scope to ensure that the task is scheduled and executed within the specified scope.

[0130] The thread number of a task is used to control the order in which tasks are executed in parallel. By specifying the thread number, the system can determine the priority or order in which tasks are executed in multiple threads, ensuring that there will be no resource conflicts or concurrency issues in the execution of tasks. Add the thread number field to the RedisJob annotation. The system reads the thread number when scheduling tasks and assigns the tasks to the corresponding thread pool for scheduling. The use of thread numbers helps control the parallelism of tasks and prevents multiple tasks from competing for resources at the same time.

[0131] The single-node execution attribute determines whether the task can only be executed on one node, preventing the task from being executed repeatedly on multiple nodes. Some tasks have a high execution cost or have strict consistency requirements on data. These tasks can only be executed on one node to avoid data conflicts or inconsistencies. By setting the single-node execution attribute in the RedisJob annotation, the system will check this attribute when scheduling tasks and ensure that the task is only run on one node. If the task is found to be scheduled on other nodes, the system will prevent it from being executed to avoid repeated scheduling.

[0132] When scheduling tasks, the system determines how to execute the task based on the configuration information in the RedisJob annotation (such as execution scope, thread number, distributed execution attributes, etc.). This includes determining whether the task needs to be executed collaboratively between multiple nodes or only on a single node. The task scheduler will first read the configuration information in the RedisJob annotation each time it schedules a task, and then determine the distributed execution mode of the task based on this information. The scheduler can choose to distribute tasks between multiple nodes, or control the parallel execution of tasks based on thread numbers.

[0133] Once the system determines the distributed execution mode of the task, it will assign the task to the corresponding node or thread for execution according to the mode. Tasks may be assigned to multiple nodes for parallel execution, or they may be executed sequentially on a single node according to the specified thread number. The scheduler schedules tasks to appropriate nodes or threads based on the configuration of the RedisJob annotation. Through the distributed nature of Redis, the execution status of tasks can be shared among multiple nodes to ensure smooth execution and status consistency of tasks.

[0134] This embodiment implements flexible scheduling and distributed execution of tasks by setting up a task management mechanism, configuring the execution scope and thread number of tasks, and combining the configuration in the RedisJob annotation. The system can schedule tasks among multiple nodes according to the distributed properties of tasks, avoiding repeated execution of tasks or unnecessary resource contention. At the same time, the execution scope and thread number configuration of tasks enable efficient scheduling of tasks under different resource conditions, improving the reliability of task scheduling and the scalability of the system.

[0135] In one embodiment, in the above S50, intercepting the execution process of the distributed scheduled task through aspect programming includes:

[0136] S501, use Aspect to implement the surround interception method and intercept the distributed scheduled tasks annotated with RedisJob;

[0137] S502, storing the BaseScheduleObject information in Redis and storing the ScheduleHashmap data in the local service;

[0138] S503, extracting the execution parameters of the task from BaseScheduleObject and ScheduleObject through the intercepted RedisJob annotated method name, and managing the execution mode of the distributed scheduled task according to the extracted execution parameters;

[0139] S504: Execute the distributed scheduled task according to the extracted execution parameters.

[0140] In this embodiment, Aspect aspect programming intercepts tasks annotated with RedisJob through around advice (AroundAdvice). Around advice can insert custom processing logic before and after the method is executed. Through AOP technology, distributed scheduled tasks annotated with RedisJob can be intercepted, the execution process of the task can be captured and specific operations can be performed, such as parameter checking, logging or task status control. In the system, by defining a class annotated with @Aspect, around advice is configured to intercept methods annotated with @RedisJob. Before the method is executed, the aspect will check the status information or other conditions of the task to decide whether to continue executing the task.

[0141] BaseScheduleObject contains the basic execution information of the task, such as the execution time of the task, the status of the task, etc. This information needs to be stored in Redis so that it can be shared among multiple nodes in a distributed system. At the same time, ScheduleHashmap contains more detailed configurations of the task, such as the task execution scope, distributed properties, etc. These data are stored in the local service, reducing frequent remote access and optimizing performance. When the task is executed, the system will write the basic status information of the task to the Redis storage through the RedisAPI to ensure that this information can be accessed by other nodes. At the same time, ScheduleHashmap will be saved in the local memory or cache for the task scheduling of the current node to speed up the reading of task configuration information during task execution.

[0142] The execution parameters of a task determine how the task is scheduled and executed. By intercepting methods annotated with RedisJob, the system can extract these execution parameters from BaseScheduleObject (basic task information) and ScheduleObject (extended task information). These parameters may include the execution time, thread number, execution node, etc. of the task, helping the system decide how to schedule and execute the task. Before the task is executed, the aspect will read the BaseScheduleObject from Redis and get the ScheduleObject from the local cache to extract the execution parameters of the task. These parameters will be used for subsequent task scheduling to ensure that the task is executed according to the correct configuration.

[0143] The extracted execution parameters can include the distributed properties of the task, the execution scope, the thread number, etc. These parameters determine the execution mode of the task. Based on these parameters, the system will decide whether the task is executed on a single node or multiple nodes, and control the execution order and resource allocation of the task. By managing these parameters, the system can flexibly control the execution mode of the task and ensure the reliability and consistency of task execution. Before the task is executed, the system makes scheduling decisions for the task based on the parameters extracted from BaseScheduleObject and ScheduleObject. For example, if the task is set to distributed execution, the system will assign the task to multiple nodes according to the configuration; if the task is executed on a single node, it will ensure that the task runs on only one node.

[0144] After extracting the execution parameters of the task, the system will start executing the distributed scheduled task according to these parameters. The execution parameters not only control which node or thread the task runs on, but also determine the scheduling priority, execution conditions, etc. of the task. With these parameters, the system can ensure that the task is executed in the distributed environment in the best way. Once the execution parameters of the task are determined, the system will start the actual execution of the task according to these parameters. For example, the system will select the appropriate execution node and thread, and run the task according to the scheduling policy. During the execution of the task, the status information will be continuously updated and synchronized to Redis after the task is completed to ensure the consistency of the task status.

[0145] This embodiment intercepts the execution process of distributed scheduled tasks through aspect programming, and realizes flexible control and scheduling of task execution. The system can check the execution conditions before task execution, extract execution parameters from BaseScheduleObject and ScheduleObject, and flexibly adjust the execution mode of the task according to these parameters. By synchronizing the task status to Redis, the system ensures the consistency of task status among multiple nodes, effectively avoids the problem of repeated or missed execution of tasks, and improves the stability and efficiency of distributed task scheduling.

[0146] In one embodiment, in the above S10, defining a scheduled task base class to start a scheduled task scheduling function includes:

[0147] S101, create a scheduled task base class and inject it into the application context as a Spring Bean to manage and execute distributed scheduled tasks;

[0148] S102, adding @EnableScheduling annotation in the scheduled task base class to enable the scheduled task scheduling function so that the task is executed according to a predetermined time period;

[0149] S103, if the task needs to be executed in parallel in multiple threads, add @EnableAsync annotation in the scheduled task base class to enable the asynchronous execution function.

[0150] In this embodiment, the scheduled task base class is a common class for all distributed scheduled tasks. By injecting it into the context of the application as a Spring Bean, instances of this class can be managed and scheduled in the Spring container. This base class provides a framework for defining common functions of distributed scheduled tasks, such as scheduling, execution, and state management. The developer creates a scheduled task base class and registers it as a Spring Bean using the @Component or @Bean annotation. The Spring container automatically manages the life cycle of the class and injects it into the context when the application starts. In this way, the task management logic in the base class can be called and reused throughout the application, ensuring unified scheduling and management of distributed tasks.

[0151] The @EnableScheduling annotation is used to enable Spring's scheduled task scheduling feature, allowing applications to automatically execute tasks according to a specified time period. This annotation enables the task scheduler so that tasks in the scheduled task base class can be scheduled according to a predetermined schedule. Add the @EnableScheduling annotation at the class level of the scheduled task base class, and the Spring container will automatically configure the task scheduler. Developers can use the @Scheduled annotation in the base class to define the execution time and frequency for each task, thereby ensuring that the task is automatically executed according to the predetermined time period. The task scheduler is responsible for calling the task's execution method at the correct time.

[0152] The @EnableAsync annotation is used to enable asynchronous task execution, allowing tasks to be executed in parallel in multiple threads. Through asynchronous execution, the system can handle multiple tasks at the same time without blocking the main thread of the entire application due to a single task. This is particularly important in a high-concurrency environment and can improve the system's task processing capabilities. Add the @EnableAsync annotation to the scheduled task base class, and Spring will configure the asynchronous executor so that the tasks defined in this class can be executed asynchronously in a separate thread pool. If a task takes a long time to execute, asynchronous execution can ensure that other tasks are not delayed. Developers can also further configure the thread pool size and task queue to meet specific task concurrency requirements.

[0153] This embodiment implements the unified scheduling and management of distributed scheduled tasks by defining a scheduled task base class and enabling the @EnableScheduling and @EnableAsync annotations. The automated management of the Spring container enables tasks to be executed in a predetermined cycle or in parallel, improving the task processing efficiency of the system. The asynchronous execution function further ensures the stability and performance of tasks in a high-concurrency environment, avoids the problem of task blocking or delay, and enhances the scalability of the system and the flexibility of task scheduling.

[0154] In one embodiment, in the above S30, recording the task status information of each distributed scheduled task includes:

[0155] S301, define a basic task state object BaseScheduleObject, which is used to store basic information of distributed scheduled tasks;

[0156] S302, when the Spring Boot application is initialized, the basic task state object BaseScheduleObject is associated with the scheduled task scheduling function;

[0157] S303, configuring the task attributes including the task execution time, execution status and execution node in the basic task status object BaseScheduleObject;

[0158] S304, creating an extended task status object ScheduleObject, and inheriting the structure of BaseScheduleObject through ScheduleObject;

[0159] S305, configuring the execution parameters of the distributed task in the extended task state object ScheduleObject;

[0160] S306, binding the extended task state object ScheduleObject to the scheduled task scheduling function;

[0161] S307: Adjust the task configuration information in the extended task status object ScheduleObject to be consistent with the task execution process.

[0162] In this embodiment, BaseScheduleObject is the basic data structure of task status, which is used to store key information of distributed scheduled tasks, such as the execution time of the task, whether the task has been completed, and the execution node of the task. It provides a unified storage structure for each task, so that the system can easily read and update the status of the task. The developer defines a BaseScheduleObject class, which contains basic information fields for task execution, such as executionTime (execution time), status (execution status), node (execution node), etc. These fields will be updated during the execution of the task to reflect the status of the task.

[0163] When a Spring Boot application starts, the system associates the BaseScheduleObject with the scheduled task scheduler so that the status of each distributed task can be managed by the scheduler. This process ensures that the task status information can be correctly initialized and managed when the application starts. During the startup of a Spring Boot application, the developer registers the BaseScheduleObject with the scheduler through a configuration class or initialization method. In this way, the scheduler can automatically associate the status information of each task when managing tasks, and read or update the task status through the BaseScheduleObject.

[0164] Each task status information object contains the core attributes of the task, such as execution time, current status of the task (such as executing, completed, etc.) and execution node (that is, the specific server or resource where the task is executed in the distributed system). These attributes help track the execution process of the task and ensure the uniqueness of the task in a multi-node environment. Fields in the BaseScheduleObject class, such as executionTime and status, are assigned or updated before, during, and after the task is executed, respectively, to ensure that the status of the task is recorded at each stage and can be read by the scheduler.

[0165] ScheduleObject inherits from BaseScheduleObject. In addition to storing basic information, it also adds more parameters related to task execution. Through the inheritance mechanism, ScheduleObject can use the common information of the base class and expand additional configurations for specific distributed tasks. Developers create a ScheduleObject class that inherits BaseScheduleObject and add parameters related to distributed tasks to ScheduleObject, such as the distributed execution strategy of the task, the number of retries, and the task priority.

[0166] The execution parameters in ScheduleObject are used to determine how tasks are scheduled in a distributed environment. These parameters can include the number of execution threads for a task, the execution range (such as which nodes execute the task), and the execution frequency. Through these parameters, the system can flexibly control the scheduling and execution behavior of tasks. A series of fields related to task scheduling are defined in the ScheduleObject class, and developers can set the values ​​of these fields based on the characteristics of the task. For example, the threadNumber field can control the parallel execution of tasks, and the executionRange field can define which nodes or servers the task runs on.

[0167] To ensure that the system can read the extended status information of the task when scheduling the task, ScheduleObject needs to be bound to the scheduled task scheduling function. When the task is executed, the scheduler will read and manage the execution parameters of the task through ScheduleObject, and ensure that the task is correctly scheduled according to these parameters. Developers bind ScheduleObject to the scheduler through the scheduler's registration mechanism. When the task scheduler calls the task execution method, it automatically reads the parameters in ScheduleObject and executes the task scheduling according to these parameters.

[0168] During the execution of a task, the status and configuration of the task may change, such as the execution status of the task, the execution time of the task, etc. In order to ensure the real-time and accuracy of the task status, the system needs to dynamically update the task configuration information in ScheduleObject according to the execution status of the task. At each stage of the task, the system will update the status information in ScheduleObject according to the actual execution status of the task. For example, when the task starts, the executionTime will be updated to the current time, and when the task is completed, the status will be updated to completed.

[0169] This embodiment achieves transparent and accurate management of task execution by recording the task status information of each distributed scheduled task. The system can update the status information in real time according to the execution status of the task, ensuring that the task is correctly scheduled in the distributed environment. The status information of the task is dynamically managed by the system, ensuring the accuracy of task execution and avoiding the risk of repeated scheduling or lost execution of the task.

[0170] In one embodiment, in the above S50, intercepting the execution process of the distributed scheduled task through aspect programming includes:

[0171] S505, when the scheduled task is triggered by the @Scheduled annotation, the execution of the distributed scheduled task with the RedisJob annotation is intercepted by the aspect;

[0172] S506, the aspect extracts the execution conditions of the distributed scheduled task from the RedisJob annotation, and reads the current status of the distributed scheduled task from Redis;

[0173] S507, based on the current state and execution condition of the distributed scheduled task, determining whether the distributed scheduled task needs to continue to be executed;

[0174] S508, if the distributed scheduled task meets the execution conditions, the distributed scheduled task is executed; if the distributed scheduled task fails to execute, whether to re-execute is determined according to the retry configuration of the distributed scheduled task, and the execution result of the distributed scheduled task is recorded;

[0175] S509: If the distributed scheduled task does not meet the execution conditions, the execution is skipped.

[0176] In this embodiment, the @Scheduled annotation is used to schedule the execution of the task. When the task is triggered, the aspect programming technology intercepts the execution process of the task. Distributed scheduled tasks with RedisJob annotations are identified and intercepted, allowing the system to check the status, conditions, and execution configuration of the task before the task is actually executed. When the scheduled task is triggered by @Scheduled, the AOP aspect captures the execution method of the task and applies custom logic before execution, such as checking the conditions of the task, reading the task status, etc. In this way, the system flexibly controls the execution of tasks and ensures that the task continues to execute only when certain conditions are met.

[0177] The core of aspect programming is the ability to intervene before and after method execution. By reading the RedisJob annotation, the system can extract the execution conditions of the task, which determine whether the task should be executed. At the same time, the current status information of the task is stored in Redis, and the aspect will read the status information of the task from Redis, such as whether the task has been executed, the number of executions, etc., to determine whether the task continues to execute. When the task is triggered, the aspect will first extract the conditional parameters for task execution (such as time, frequency, number of executions, etc.) from the RedisJob annotation, and then read the current status information of the task (such as the last execution time, task status) through the RedisAPI, so as to make execution judgments based on this information.

[0178] The system compares the execution conditions extracted from the RedisJob annotation with the current state information. If the current state meets the execution conditions in the annotation, the task will continue to execute; otherwise, the task will be skipped. This mechanism ensures that tasks are only executed when the conditions are met, avoiding unnecessary task scheduling or resource waste. The system uses logic to determine whether the execution conditions match the current task state. For example, if the last execution time and the current time interval of the task are less than the set execution frequency, the system will skip the execution of the task. If all conditions are met, the task will continue to execute.

[0179] If the task status and execution conditions meet, the system will continue to execute the task and record the execution result of the task (such as success, failure, execution time, etc.). If the task fails, the system will decide whether to re-execute it based on the task's retry strategy. The retry configuration usually includes parameters such as the number of retries and the retry interval to ensure that the failed task has a chance to be re-executed. When a task fails, the aspect will read the task's retry configuration (for example, a maximum of 3 retries, each with an interval of 10 minutes) and decide whether to try to execute the task again. The result of each task execution is recorded, including the success or failure status of the task, and is updated synchronously to Redis.

[0180] If the system determines that the current state of a task does not meet the execution conditions, the task will be skipped and no actual execution will be performed. This prevents tasks from being triggered at inappropriate times, and prevents repeated execution or unnecessary resource consumption. When the task state does not match the execution conditions, the aspect will prevent the task from continuing to execute, and the system will record the reason for skipping the execution (for example, the frequency does not meet the requirements or the task has been completed). This mechanism ensures that the system's task scheduling resources can be reasonably allocated and reduces ineffective task scheduling.

[0181] This embodiment intercepts the execution process of distributed timed tasks through aspect programming, and can flexibly control the scheduling and execution of tasks. Before the task is executed, the system checks the execution conditions and current status of the task to ensure that the task will be executed only when the conditions are met, thereby avoiding repeated scheduling of tasks. At the same time, the task retry mechanism improves the reliability of task execution and prevents the task from being interrupted due to accidental failure. Finally, the execution results of the task are recorded and managed in real time, and the system can efficiently monitor the status of the task, ensuring the accuracy of task scheduling and the rational use of system resources.

[0182] In one embodiment, in the above S10, a project is created based on Spring Boot, and Redis is configured to store and manage distributed scheduled tasks, including:

[0183] S104, create a Spring Boot project and introduce dependencies to support scheduled task scheduling and Redis storage;

[0184] S105, in the project configuration file, define Redis connection parameters, including host address, port number and authentication information;

[0185] S106, initializing a Redis tool class for storing and reading task status in a distributed environment;

[0186] S107, before the task is executed, read the current execution status of the task from Redis, determine whether the task meets the execution conditions, and update the latest execution status of the task after the task is executed;

[0187] S108, synchronize the execution status of the task among multiple nodes through the Redis consistency mechanism.

[0188] In this embodiment, by creating a project based on the Spring Boot framework, the system can easily configure and manage scheduled tasks. The project introduces dependency libraries that support scheduled task scheduling (such as spring-boot-starter-schedule) and Redis storage dependency libraries (such as spring-boot-starter-data-redis). These dependencies allow developers to manage scheduled tasks and communicate with Redis through simple configuration. Add dependencies to the project's pom.xml file or build.gradle file to ensure that the project has the ability to schedule tasks and interact with Redis. These dependencies include Spring's scheduling tasks and Redis integration libraries, making the configuration of scheduled tasks and Redis storage operations simple and efficient.

[0189] In order to communicate with the Redis server, the system needs to define the relevant parameters for connecting to Redis in the Spring Boot configuration file. These parameters include the host address (IP) of the Redis server, the port number, and authentication information (such as password) to ensure that the system can correctly connect to the Redis server for data reading and writing operations. You can define the Redis connection information in the application.properties or application.yml configuration file, such as: spring.redis.host = localhost; spring.redis.port = 6379; spring.redis.password = yourpassword. The system will automatically load these parameters and establish a connection with the Redis server when it starts.

[0190] The Redis tool class is an encapsulation of Redis operations, which is used to simplify the interaction with Redis. In a distributed environment, multiple nodes may need to share task status information. Through the Redis tool class, the system can efficiently read and write task status information in a distributed environment to ensure the consistency of status between nodes. Create a Redis tool class that contains methods for interacting with Redis, such as storing task status, reading task status, etc. The tool class will encapsulate the details of Redis operations, such as storing task status through key-value pairs, setting expiration time, etc. Developers can easily implement distributed management of task status by calling methods in the tool class.

[0191] Before executing a task, the system needs to read the execution status of the current task from Redis. By checking the task status information (such as the last execution time, execution times, etc.), determine whether the task meets the execution conditions. The task will only be scheduled for execution if certain conditions are met (such as sufficient interval time and normal status). Before each task is executed, the system will query the task status information (such as the last execution time, whether the execution is successful, etc.) from Redis. According to the preset conditions (such as task frequency, retry strategy, etc.), determine whether the task can be executed. If the conditions are met, the task will be executed, otherwise it will be skipped.

[0192] After the task is completed, the system needs to update the task's execution status information, such as whether the task was successful, failed, and how long it took to execute. By updating this information to Redis, the system ensures that other nodes can obtain the latest task status to avoid duplicate execution or task loss. When the task is completed, the system will update the latest status of the task (such as success / failure, execution time) to Redis through the Redis tool class. The updated status information will overwrite the old status, ensuring that the execution history and current status of the task can be shared by all nodes.

[0193] In a distributed environment, multiple nodes may try to schedule the same task at the same time. Through Redis's consistency mechanism, the system can ensure that the task status is synchronized between multiple nodes to prevent duplicate execution or omission of tasks. Redis's consistency guarantee makes the task execution process consistent across multiple nodes, ensuring the stability of the distributed system. Through Redis's distributed locks, transaction mechanisms, or optimistic locking, the system can ensure that only one node can modify the task status during the task execution process. When other nodes detect that the task is already being executed, they will wait for or skip the task to avoid duplicate execution.

[0194] This embodiment creates a project based on Spring Boot and configures Redis to store and manage distributed scheduled tasks, thus achieving distributed management and sharing of task status. The system can read and update task status from Redis before and after task execution, ensuring the execution consistency of tasks across multiple nodes and avoiding duplicate scheduling or omission of tasks. Redis's distributed consistency mechanism ensures reliable execution of tasks and improves the efficiency and stability of task scheduling in a distributed environment.

[0195] The present invention also provides a distributed timed task management device, referring to Figure 2 , Figure 2 This is a functional module diagram of a preferred embodiment of a distributed scheduled task management device of the present invention. The distributed scheduled task management device comprises:

[0196] The project initialization and configuration module is used to create a project based on Spring Boot, configure Redis to store and manage distributed scheduled tasks, and define the scheduled task base class to enable the scheduled task scheduling function;

[0197] The task scheduling and management module is used to define the execution plan of the task using the @Scheduled annotation in the scheduled task base class, establish a task management mechanism, configure the execution scope and thread number of the task, and generate a unique identifier for each distributed scheduled task;

[0198] The task status recording module is used to record the task status information of each distributed scheduled task, including the task execution time, execution frequency and unique identifier;

[0199] A task execution module, used to define a task execution method in a scheduled task base class, and trigger a task based on the execution time and the execution frequency;

[0200] Aspect interception module, which is used to intercept the execution process of distributed scheduled tasks through aspect programming, and judge the execution conditions according to the task status information before the task is executed;

[0201] The task progress recording module is used to generate and record the execution information of the task during the task execution process, and update it to Redis to reflect the progress of the task;

[0202] The task status update module is used to integrate the task execution process information into the final execution status information when the task is completed, and update it to Redis to record the execution status of the task.

[0203] The specific implementation of the distributed scheduled task management device of the present invention is basically the same as the above-mentioned distributed scheduled task management method embodiments, and will not be repeated here.

[0204] The present invention also provides a distributed timed task management device, such as Figure 3 As shown, the distributed timed task management device may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or it may be a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0205] Those skilled in the art will understand that Figure 3 The hardware structure of the distributed scheduled task management device shown in the figure does not constitute a limitation on the distributed scheduled task management device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0206] like Figure 3 As shown, the memory 1005 as a storage medium may include an operating system, a network communication module, a user interface module, and a distributed timed task management program. Among them, the operating system is a program for managing and controlling distributed timed task management devices and software resources, supporting the operation of the network communication module, the user interface module, the distributed timed task management program, and other programs or software; the network communication module is used to manage and control the network interface 1004; the user interface module is used to manage and control the user interface 1003.

[0207] exist Figure 3In the hardware structure of the distributed scheduled task management device shown, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the client and communicate data with the client; the processor 1001 can call the distributed scheduled task management program stored in the memory 1005 and perform the same operations as the distributed scheduled task management method.

[0208] The specific implementation of the distributed scheduled task management device of the present invention is basically the same as the above-mentioned distributed scheduled task management method embodiments, and will not be repeated here.

[0209] In addition, an embodiment of the present invention further provides a computer storage medium on which a distributed scheduled task management program is stored. When the distributed scheduled task management program is executed by a processor, the steps of the distributed scheduled task management method described above are implemented.

[0210] The specific implementation of the computer storage medium of the present invention is basically the same as the above-mentioned distributed scheduled task management method embodiments, and will not be repeated here.

[0211] It should be noted that if software tools or components other than those of our company appear in the embodiments of the present application, they are only used for illustrative purposes and do not represent actual use.

Claims

1. A distributed scheduled task management method, characterized in that: The following steps are involved: Create a project based on Spring Boot, configure Redis to store and manage distributed scheduled tasks, and define the scheduled task base class to enable the scheduled task scheduling function; In the scheduled task base class, the @Scheduled annotation is used to define the execution plan of the task, establish a task management mechanism, configure the execution scope and thread number of the task, and generate a unique identifier for each distributed scheduled task; Record the task status information of each distributed scheduled task, including the task execution time, execution frequency and unique identifier; Define a task execution method in a scheduled task base class, and trigger the task based on the execution time and the execution frequency; Intercept the execution process of distributed scheduled tasks through aspect programming, and determine the execution conditions based on task status information before the task is executed; During the task execution process, the task execution information is generated and recorded, and updated to Redis to reflect the progress of the task; When the task is completed, the task execution process information is integrated into the final execution status information and updated to Redis to record the execution status of the task.

2. The distributed scheduled task management method according to claim 1, characterized in that: Establish a task management mechanism and configure the execution scope and thread number of the task, including: Create a custom annotation RedisJob to mark scheduled tasks that require distributed management; Set the distributed execution attribute of the task in the RedisJob annotation to determine whether the task needs to be coordinated and executed among multiple nodes; Configure the execution scope of the task in the RedisJob annotation to determine the resources or target services used when executing the task; Specify the thread number of the task in the RedisJob annotation to control the execution order of tasks in multiple threads; In the RedisJob annotation, set whether the task is executed on a single node; During the task scheduling process, the distributed execution mode of the task is determined according to the configuration information in the RedisJob annotation, and the distributed scheduled tasks are assigned to the set nodes or threads for execution according to the distributed execution mode.

3. The distributed scheduled task management method as described in claim 1, characterized in that: Intercept the execution process of distributed scheduled tasks through aspect programming, including: Use Aspect to implement the surround interception method and intercept the distributed scheduled tasks annotated with RedisJob; Store BaseScheduleObject information in Redis and ScheduleHashmap data in the local service; Through the intercepted RedisJob annotated method name, the task execution parameters are extracted from BaseScheduleObject and ScheduleObject, and the execution mode of distributed scheduled tasks is managed according to the extracted execution parameters; Execute distributed scheduled tasks based on the extracted execution parameters.

4. The distributed scheduled task management method according to claim 1, characterized in that: Define the scheduled task base class to enable the scheduled task scheduling function, including: Create a scheduled task base class and inject it into the application context as a Spring Bean to manage and execute distributed scheduled tasks; Add the @EnableScheduling annotation to the scheduled task base class to enable the scheduled task scheduling function so that the task is executed according to the predetermined time period; If the task needs to be executed in parallel in multiple threads, add the @EnableAsync annotation to the scheduled task base class to enable the asynchronous execution function.

5. The distributed scheduled task management method according to claim 1, characterized in that: Record the task status information of each distributed scheduled task, including: Define the basic task status object BaseScheduleObject to store the basic information of distributed scheduled tasks; When the Spring Boot application is initialized, the basic task state object BaseScheduleObject is associated with the scheduled task scheduling function; Configure the task attributes including the task execution time, execution status and execution node in the basic task status object BaseScheduleObject; Create an extended task status object ScheduleObject, and inherit the structure of BaseScheduleObject through ScheduleObject; Configure the execution parameters of the distributed task in the extended task state object ScheduleObject; Bind the extended task status object ScheduleObject to the scheduled task scheduling function; Adjust the task configuration information in the extended task status object ScheduleObject to be consistent with the task execution process.

6. The distributed scheduled task management method according to claim 1, characterized in that: Intercept the execution process of distributed scheduled tasks through aspect programming, including: When a scheduled task is triggered by the @Scheduled annotation, the execution of the distributed scheduled task with the RedisJob annotation is intercepted through the aspect; The aspect extracts the execution conditions of the distributed scheduled tasks from the RedisJob annotation and reads the current status of the distributed scheduled tasks from Redis; Based on the current state and execution condition of the distributed scheduled task, determine whether the distributed scheduled task needs to continue to be executed; If the distributed scheduled task meets the execution conditions, the distributed scheduled task will be executed. If the distributed scheduled task fails to execute, it will be decided whether to re-execute according to the retry configuration of the distributed scheduled task, and the execution result of the distributed scheduled task will be recorded; If the distributed scheduled task does not meet the execution conditions, it will be skipped.

7. The distributed scheduled task management method according to claim 1, characterized in that: Create a project based on Spring Boot and configure Redis to store and manage distributed scheduled tasks, including: Create a Spring Boot project and introduce dependencies that support scheduled task scheduling and Redis storage; In the project configuration file, define the Redis connection parameters, including the host address, port number, and authentication information; Initialize the Redis tool class to store and read task status in a distributed environment; Before the task is executed, the current execution status of the task is read from Redis to determine whether the task meets the execution conditions. After the task is executed, the latest execution status of the task is updated; The Redis consistency mechanism is used to synchronize the execution status of tasks among multiple nodes.

8. A distributed scheduled task management device, characterized in that: The distributed scheduled task management device comprises: The project initialization and configuration module is used to create a project based on Spring Boot, configure Redis to store and manage distributed scheduled tasks, and define the scheduled task base class to enable the scheduled task scheduling function; The task scheduling and management module is used to define the execution plan of the task using the @Scheduled annotation in the scheduled task base class, establish a task management mechanism, configure the execution scope and thread number of the task, and generate a unique identifier for each distributed scheduled task; The task status recording module is used to record the task status information of each distributed scheduled task, including the task execution time, execution frequency and unique identifier; A task execution module, used to define a task execution method in a scheduled task base class, and trigger a task based on the execution time and the execution frequency; Aspect interception module, which is used to intercept the execution process of distributed scheduled tasks through aspect programming, and judge the execution conditions according to the task status information before the task is executed; The task progress recording module is used to generate and record the execution information of the task during the task execution process, and update it to Redis to reflect the progress of the task; The task status update module is used to integrate the task execution process information into the final execution status information when the task is completed, and update it to Redis to record the execution status of the task.

9. A distributed scheduled task management device, characterized in that: The distributed scheduled task management device includes a memory, a processor, and a distributed scheduled task management program stored in the memory and executable on the processor. When the distributed scheduled task management program is executed by the processor, the steps of the distributed scheduled task management method as described in any one of claims 1 to 7 are implemented.

10. A computer storage medium, characterized in that: The storage medium stores a distributed scheduled task management program, which, when executed by a processor, implements the steps of the distributed scheduled task management method according to any one of claims 1 to 7.

Images