Periodic task processing method and apparatus

Abstract

The application provides a periodic task processing method and device, and relates to the technical field of automation programs, which comprises the following steps: initializing the day beginning and day ending task triggering logic by analyzing a configuration file, starting a timer and binding a time driving engine, executing a time fault tolerance algorithm in combination with a time jump tolerance threshold, and ensuring continuous generation and pushing of time events to an event engine. Further starting an event processing engine, a timing scheduling engine and a task execution engine to realize decoupling and cooperation of time event receiving, scheduling judgment and task execution. After a periodic task object is loaded from a database, it is distributed by hash according to the task type to realize thread level load balancing. The task execution engine analyzes parameters, completes risk control verification and path selection, and writes the operation results into the database persistently to build a closed loop efficient scheduling processing link. The application can improve the processing efficiency of periodic tasks.

Description

Technical Field

[0001] This application relates to the technical field of automated programs, specifically to a method and apparatus for processing periodic tasks. Background Technology

[0002] Periodic tasks are the fundamental units constituting an automated trading system. Common periodic tasks include, but are not limited to, automated share reduction, automated repurchase, automated reverse repurchase, and automated IPO subscription. These tasks typically require triggering operational instructions and providing results within specific trading sessions according to predetermined rules. Due to the diversity of task types and the highly concentrated triggering times, the system must not only ensure the accuracy of time triggering but also consider the isolation between tasks and the flexibility of execution paths when processing such tasks. Therefore, a high-concurrency, low-latency periodic task processing mechanism is a key foundation for supporting the execution of automated securities trading strategies.

[0003] However, existing technologies in task processing architectures generally suffer from coarse-grained thread resource scheduling and imprecise task classification, lacking a unified thread pool management strategy and a dynamic dispatch mechanism that is aware of task types. This leads to similar tasks easily clustering in the same thread, causing blocking, while different types of tasks cannot be load-balanced. When the number of concurrent tasks in the system increases sharply, task queuing delays worsen, execution failure rates rise, and the predictability and consistency of automated tasks are severely affected, leading to transaction delays, strategy failures, and even compliance risks. To address these issues, there is an urgent need to construct a periodic task processing method based on fine-grained thread pool hierarchical management and a type-driven dispatch mechanism to improve task processing efficiency and system responsiveness.

[0004] Therefore, there is an urgent need for a method to improve the processing efficiency of periodic tasks. Summary of the Invention

[0005] This application provides a method and apparatus for processing periodic tasks, which can improve the processing efficiency of periodic tasks.

[0006] A first aspect of this application provides a method for processing periodic tasks, the method comprising:

[0007] The triggering logic for the beginning and end of the day tasks is initialized by parsing the task time parameters in the preset configuration file.

[0008] Initialize the timer and bind it to the time-driven engine. The timer generates a time factor every second and executes a time fault-tolerant algorithm based on the time jump tolerance threshold. The time factor is encapsulated as a time event and pushed to the event engine to trigger the periodic task scheduling.

[0009] Multiple task processing engines are launched, including an event processing engine for pooling multiple time processing threads, a time-series scheduling engine for listening to the time events and triggering the scheduling of periodic tasks, and a task execution engine for dynamically adjusting the number of execution threads and executing the periodic tasks according to the system load.

[0010] The system loads existing periodic tasks from the database and injects them into the event processing engine. It then performs hash distribution of time events based on task type and updates the status of the existing periodic tasks.

[0011] The task execution engine parses the existing periodic tasks based on their parameters, performs risk control verification, distributes the existing periodic tasks to the target execution service according to the delegation strategy, obtains the execution results, and writes the execution results to the database.

[0012] Based on the above technical solutions, preferably, the step of initializing the triggering logic for the beginning-of-day and end-of-day tasks by parsing the task time parameters in the preset configuration file specifically includes:

[0013] The daily task is triggered at a preset first moment, including reinitializing the timer and multiple task processing engines and reloading periodic task data;

[0014] The end-of-day task is triggered at a preset second time, including destroying multiple instances of the task processing engine and terminating the task scheduling process.

[0015] Based on the above technical solutions, preferably, the step of executing a time-tolerance algorithm based on a time jump tolerance threshold, which encapsulates time factors into time events and pushes them to the event engine, specifically includes:

[0016] Get the reference timestamp of the last successfully triggered task, and call the operating system time interface to get the current timestamp;

[0017] Calculate the time difference between the current timestamp and the reference timestamp;

[0018] The time difference is compared with a preset time jump tolerance threshold. If the time difference is less than or equal to the time jump tolerance threshold and equal to the preset time difference, the current timestamp is encapsulated as the time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp.

[0019] If the time difference is greater than the preset time difference and less than or equal to the time jump tolerance threshold, then the time factor of each missed time point is reissued based on the time difference, and each time factor is encapsulated as a time event and pushed to the event engine in sequence. At the same time, the time factor corresponding to the current timestamp is encapsulated as a time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp.

[0020] If the time difference is greater than the time jump tolerance threshold, the current timestamp is encapsulated as the time event and pushed to the event engine.

[0021] Based on the above technical solutions, preferably, the step of loading existing periodic tasks from the database and injecting them into the event processing engine, and distributing time events by hash based on task type, specifically includes:

[0022] The task management engine connects to the database and retrieves currently active periodic task records based on preset query conditions;

[0023] Each of the aforementioned periodic task records is converted into a standardized periodic task object, which includes a task identifier, task type, scheduling period, status field, and parameter configuration field.

[0024] The periodic task objects are injected one by one into the event processing engine, and the time processing thread obtains the corresponding time events and binds the time events to the periodic task objects.

[0025] A hash algorithm is executed based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object, and the mapping thread is distributed to the corresponding time processing thread.

[0026] Based on the above technical solutions, preferably, after performing a consistent hashing algorithm based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object, and distributing the mapping thread to the corresponding time processing thread, the method further includes:

[0027] In the time processing thread, the timestamp in the time event and the scheduling period field in the periodic task object are parsed to determine whether the periodic task object meets the current scheduling conditions.

[0028] If it is determined that the periodic task object meets the current scheduling conditions, then the state of the periodic task object is updated to the pending execution state;

[0029] The existing periodic tasks corresponding to the periodic task objects in the pending execution state are pushed to the task execution engine;

[0030] If it is determined that the periodic task object does not meet the current scheduling conditions, the state of the periodic task object is maintained unchanged until the subsequent scheduling cycle is determined again.

[0031] Based on the above technical solutions, preferably, the step of executing the hash algorithm based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object specifically includes:

[0032] Construct a hash ring, define the hash space as a preset numerical range, and generate a unique thread identifier for each of the time processing threads;

[0033] Perform a hash calculation on each of the thread identifiers to obtain multiple thread hash values;

[0034] Each thread hash value is registered as a virtual thread node on the hash ring, and each time processing thread may correspond to one or more virtual thread nodes;

[0035] For each of the periodic task objects, the task type field is extracted as a key, and the key is hashed to obtain the corresponding task hash value;

[0036] In the hash ring, starting from the task hash value, the target virtual node of the nearest thread virtual node among the multiple virtual thread nodes is searched in a clockwise direction;

[0037] The time processing thread corresponding to the target virtual node is determined to be the mapping thread after the time event is bound to the periodic task object;

[0038] If it is determined that the hash value of the task is greater than the hash values ​​of all the virtual thread nodes in the hash ring, then the search continues to wrap around to the beginning of the hash ring until the mapped thread is determined.

[0039] After the time event is bound to the periodic task object, it is pushed to the mapping thread for the time processing thread to perform scheduling judgment and status update operations.

[0040] Based on the above technical solutions, preferably, the step of the task execution engine parsing the parameters of the existing periodic tasks, performing risk control verification, distributing the existing periodic tasks to the target execution service according to the delegation strategy, obtaining the execution results, and writing the execution results into the database specifically includes:

[0041] Identify the target task object in the pending execution state among the periodic task objects;

[0042] Output the target task object to the task execution engine, and extract the parameter configuration fields of the target task object, including the target number, operation price parameter, operation quantity parameter, operation mode parameter, and scheduling priority parameter;

[0043] The parameter configuration fields are parsed into a unified format internal execution data structure;

[0044] Load a set of rules that match the parameter configuration fields, and validate the parameter configuration fields through the internal execution data structure. This includes sequentially verifying whether the scheduling priority parameter meets the current operation requirements, whether the target number corresponding to the target is in a valid operation period, whether the operation price parameter is within the floating boundary range, and whether the operation quantity parameter exceeds the defined operation threshold limit.

[0045] If the target task object passes the verification of the rule set, then the corresponding task scheduling path is selected according to the rule set;

[0046] If the task scheduling path is determined to be a policy-driven path, then the policy service interface is invoked and the policy calculation unit generates operation instructions.

[0047] If the task scheduling path is a direct command path, the operation command is sent through the command adaptation unit to the task intermediate dispatch interface.

[0048] The operation instruction is submitted to the target execution service, and the response information returned by the target execution service is received. The response information includes the execution status, processing result, start and end timestamps, and feedback data.

[0049] The response information is written to the database as the execution result, and the write operation is controlled by atomic transactions.

[0050] A second aspect of this application provides a periodic task processing apparatus for performing a periodic task processing method as described in any of the above embodiments. The apparatus includes an acquisition module, a processing module, and an output module, wherein:

[0051] The acquisition module is used to initialize the triggering logic of the beginning-of-day task and the end-of-day task by parsing the task time parameters in the preset configuration file.

[0052] The processing module is used to initialize a timer and bind it to a time-driven engine. The timer generates a time factor every second and executes a time fault-tolerant algorithm based on a time jump tolerance threshold. It encapsulates the time factor into a time event and pushes it to the event engine to trigger the periodic task scheduling.

[0053] The processing module is used to start multiple task processing engines, wherein the event processing engine is used to pool multiple time processing threads, the time scheduling engine is used to listen to the time events and trigger the scheduling of periodic tasks, and the task execution engine dynamically adjusts the number of execution threads according to the system load and executes the periodic tasks.

[0054] The processing module is used to load existing periodic tasks from the database and inject them into the event processing engine, perform hash distribution of time events based on task type, and update the status of the existing periodic tasks.

[0055] The output module is used by the task execution engine to parse the tasks based on the parameters of the existing periodic tasks, perform risk control verification, distribute the existing periodic tasks to the target execution service according to the delegation strategy, obtain the execution results, and write the execution results into the database.

[0056] A third aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.

[0057] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.

[0058] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0059] 1. This application constructs a periodic task scheduling architecture that integrates event-driven and time-driven approaches. It adopts a thread pool hierarchical management mechanism and a task type-driven hash distribution strategy to achieve concurrent isolation and load balancing in task scheduling. It introduces a time-tolerance algorithm and a dynamic jump tolerance threshold to ensure the continuity of time events and the stability of scheduling. Combined with the standardized parsing, rule verification, and path adaptation mechanism of periodic task objects, it improves the flexibility and responsiveness of the task execution chain, thereby effectively reducing the risk of task delay and blocking in high-concurrency scenarios and significantly improving the overall processing efficiency of periodic tasks.

[0060] 2. By introducing a time-tolerance algorithm and combining it with a time jump tolerance threshold to dynamically judge the time difference, the system ensures that missed time events are automatically resent when non-fatal anomalies such as system delays, jitter, or short-term blocking occur. This effectively guarantees the time continuity and stability of periodic task scheduling and improves the accuracy of task triggering in uncertain environments.

[0061] 3. By loading and converting periodic task records in the active state into periodic task objects with a unified structure during the system initialization phase, and then combining time event binding and type-aware hash distribution mechanism, thread-level load balancing and type isolation are achieved in the task injection process, effectively preventing the accumulation of single-type tasks and improving scheduling concurrency performance and task injection efficiency.

[0062] 4. By making precise judgments based on timestamps and scheduling period fields within the time processing thread, only periodic task objects that meet the scheduling conditions are advanced to the task execution stage, while tasks that do not meet the conditions remain unchanged. This achieves precise control over scheduling triggers, avoids resource waste and false triggers, and further enhances the controllability of periodic task execution and the stability of system scheduling.

[0063] 5. By constructing a consistent hash ring, generating virtual thread nodes, and performing hash mapping based on the task type field, type-aware distribution of periodic tasks among time-processing threads is achieved. Combined with clockwise search and wraparound mechanisms, it is ensured that all tasks can be mapped to specific threads, effectively improving the task distribution among threads and the system scalability.

[0064] 6. The task execution engine parses the parameter configuration fields in the periodic task objects to be executed and loads the rule set for multi-dimensional verification. It ensures that the task meets the compliance and policy control requirements before selecting the execution path and generating operation instructions. Combined with the instruction adaptation and result writing mechanism, it achieves high accuracy of task execution and closed-loop control of the entire process, thereby enhancing the system's security, traceability and task processing integrity in the automated policy execution process. Attached Figure Description

[0065] Figure 1 This is a flowchart illustrating a periodic task processing method disclosed in an embodiment of this application;

[0066] Figure 2 This is a time-tolerant state transition diagram disclosed in an embodiment of this application;

[0067] Figure 3 This is a schematic diagram of a module of a periodic task processing device disclosed in an embodiment of this application;

[0068] Figure 4 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0069] Explanation of reference numerals in the attached drawings: 301, acquisition module; 302, processing module; 303, output module; 401, processor; 402, communication bus; 403, user interface; 404, network interface; 405, memory. Detailed Implementation

[0070] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0071] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0072] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0073] In securities trading scenarios, periodic tasks are the foundation for achieving automated strategy execution. However, existing technologies suffer from problems such as coarse thread scheduling granularity, imprecise task classification, and lack of type awareness in the distribution mechanism when handling periodic tasks. This leads to the clustering and blocking of similar tasks and uneven load distribution of dissimilar tasks. In high-concurrency scenarios, this can easily cause task delays and execution failures, seriously affecting the stability and compliance of the trading system. Therefore, there is an urgent need for a periodic task processing method based on fine-grained thread pool hierarchical management and a task type-driven distribution mechanism to improve task processing efficiency and system responsiveness.

[0074] This embodiment discloses a method for processing periodic tasks, referring to... Figure 1 This includes the following steps S110-S150:

[0075] S110 initializes the triggering logic for the beginning and end of the day tasks by parsing the task time parameters in the preset configuration file.

[0076] The periodic task processing method disclosed in this application is applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablets, wearable devices, and PCs (Personal Computers), and can also be a backend server running a periodic task processing method. The server can be implemented using a standalone server or a server cluster composed of multiple servers.

[0077] In one possible implementation, the triggering logic for the beginning-of-day task and the end-of-day task is initialized by parsing the task time parameters in the preset configuration file. Specifically, this includes: triggering the beginning-of-day task at a preset first moment, including reinitializing the timer and multiple task processing engines and reloading the periodic task data; and triggering the end-of-day task at a preset second moment, including destroying instances of multiple task processing engines and terminating the task scheduling process.

[0078] Specifically, a preset trigger condition is established for the first moment, preferably the opening time of the day. A timed scheduling component monitors the trading calendar and time signals. When the time matches the opening time, the initial task flow for the day is triggered. First, the timer is reinitialized. This involves resetting the timer used to generate time factors in the time-driven module, clearing residual state information from the previous trading day, including timestamp caches and event sequence numbers, and restarting the time callback mechanism accurate to the second. This timer, as the core of the time-driven mechanism, generates a time factor every second and will be encapsulated into a time event-driven scheduling process to ensure the integrity and continuity of the time sequence. Subsequently, multiple task processing engines are restarted sequentially, including the event processing engine, the time-series scheduling engine, and the task execution engine. Each engine must complete initialization operations such as resetting the thread pool state, clearing the buffer queue, and restoring thread binding logic to ensure that the task processing context of the previous trading day is completely cleared. For example, the time processing thread in the event processing engine needs to be rebound to the timer callback stream, the time-series scheduling engine needs to reconnect to the time event distribution channel, and the task execution engine needs to rebuild the execution thread resource pool based on the current load. After engine initialization is complete, the task management engine filters periodic task records from the database by "active state," parses them into periodic task objects, and injects them into the event handling engine for subsequent scheduling and execution operations triggered by time events. Reloading periodic task data includes not only reading parameter fields but also synchronizing status fields, calculating scheduling cycles, and resetting initial scheduling positions, ensuring that all periodic tasks enter a unified scheduling process from the initial setup point.

[0079] By synchronizing with the exchange's closing time, the end-of-day task process is triggered when a preset second time point is detected, preferably the daily closing time. First, multiple instances of the task processing engine are destroyed, meaning the thread pool resources, cached data structures, and running status flags maintained by the event processing engine, time-series scheduling engine, and task execution engine are completely released. Specifically, this includes: all time processing threads in the event processing thread pool sequentially exiting their execution loops via interrupt signals and deregistering callbacks with the time-driven components; the time-series scheduling engine ceasing its listening to time events, disconnecting the event input stream, and clearing the task scheduling table; and the task execution engine ceasing to accept new task requests and changing all task objects in the "pending execution" state to the "terminated" state, updating the database to prevent repeated execution the following day. Terminating the task scheduling process also includes resetting status flags in the scheduling controller, suspending event broadcast channels, and closing the logging engine, ensuring the entire scheduling process is frozen after the market closes, no longer responding to external time factors and task input events. To illustrate with an example: After the closing event is triggered at 15:00 each day, the engine shutdown interface will be called sequentially within 15:00:01. On average, the destruction and state migration of all engine resources will be completed within 200 milliseconds, thus providing a clean environment for the re-initialization of the next trading day. This mechanism avoids the contamination of the new round of transaction execution flow by residual task states, effectively ensuring the isolation of the scheduling process and the clarity of the timing rhythm.

[0080] S120 initializes the timer and binds it to the time-driven engine. The timer generates time factors every second and executes a time fault-tolerant algorithm based on the time jump tolerance threshold. It encapsulates the time factors into time events and pushes them to the event engine to trigger periodic task scheduling.

[0081] In one possible implementation, a time-tolerance algorithm is executed based on a time jump tolerance threshold. Time factors are encapsulated as time events and pushed to the event engine. Specifically, this includes: obtaining the reference timestamp of the last successfully triggered task and calling the operation time interface to obtain the current timestamp; calculating the time difference between the current timestamp and the reference timestamp; comparing the time difference with a preset time jump tolerance threshold; if the time difference is less than or equal to the time jump tolerance threshold and equal to the preset time difference, then the current timestamp is encapsulated as a time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp; if the time difference is greater than the preset time difference and less than or equal to the time jump tolerance threshold, then time factors for each missed time point are reissued based on the time difference, and each time factor is encapsulated as a time event and pushed sequentially to the event engine. Simultaneously, the time factor corresponding to the current timestamp is encapsulated as a time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp; if the time difference is greater than the time jump tolerance threshold, then the current timestamp is encapsulated as a time event and pushed to the event engine.

[0082] Specifically, after the timer is initialized, a separate time-driven thread is started. This thread is bound to the operation-level time interface to ensure that the current timestamp can be obtained with second-level precision. This time-driven thread executes a loop once per second. At the beginning of each loop, it reads the reference timestamp of the last successful push from the local state cache and synchronously obtains the current timestamp. The reference timestamp represents the time point when the time event was last successfully generated and pushed, serving as the time base for all scheduling actions; the current timestamp is the current second-level time, derived from the operation call, and possesses high precision and stability. These two timestamps serve as input to the time fault-tolerance algorithm to evaluate whether there are time jumps or missed triggering behaviors.

[0083] The difference between the current timestamp and the reference timestamp is calculated as the time interval difference, in seconds. This time interval difference is used to assess continuity; ideally, the difference should be 1, indicating that time is progressing normally and no events have been lost. When the time interval difference is less than or equal to a preset time jump tolerance threshold, it is considered to be within the tolerable range. The time jump tolerance threshold is a configurable integer value; for example, setting it to 5 seconds means that jumps within 5 seconds can be repaired through retransmission, while jumps exceeding this threshold are considered severe anomalies.

[0084] If the time interval difference is equal to 1, meaning the current timestamp differs from the reference timestamp by exactly one second, it indicates stable time progression and no resending is needed. The current timestamp is then constructed as a standard time factor and encapsulated as a time event. This time event is a structured message containing a timestamp, event identifier, and task scheduling sequence number. It is then delivered to the event engine via the event push interface for scheduling and judgment by the time processing thread. After the push is complete, the reference timestamp is updated to the current timestamp, establishing a new baseline for the next cycle.

[0085] If the time interval difference is greater than 1 but less than or equal to the time jump tolerance threshold, it indicates that one or more time points were missed during this period. A resend time sequence is constructed, encompassing all second-level time points from the reference timestamp plus 1 to the current timestamp minus 1. Each time point is constructed as a time factor and encapsulated as a time event, forming a batch event list. These time events are pushed sequentially to the event engine, ensuring the engine receives them one by one in chronological order to restore the integrity of the time-driven process. Subsequently, the current timestamp is also encapsulated as a time event and appended to the push, forming a joint push operation of a one-time resend and the currently triggered event. After the resend is completed, the reference timestamp is synchronously updated to the current timestamp to maintain the time baseline for the next round.

[0086] If the time interval difference exceeds the time jump tolerance threshold, it is judged as a serious timing anomaly, such as thread pause, restart, or time service interruption. To avoid invalid resending and resource waste, only the current timestamp is encapsulated as a time event and directly pushed to the event engine, abandoning the recovery operation for missed times, and recording an anomaly log for analysis by the monitoring module. This anomaly log records the time interval difference, the current timestamp, the reference timestamp, and the result of the jump cause judgment, for use by operation and maintenance or scheduling auditing.

[0087] In one possible implementation, the time jump tolerance threshold is dynamically adjusted based on the current CPU idle rate, specifically calculated using the following formula:

[0088]

[0089] Used to dynamically adjust the time jump tolerance threshold This ensures that the time-tolerance algorithm maintains responsiveness while also considering processing feasibility and scheduling continuity in high-concurrency task scenarios. The formula dynamically calculates the maximum acceptable resend window at each moment by incorporating current CPU resource usage and task load percentage, thus achieving adaptive optimization of the time-tolerance mechanism. The algorithm's advantages lie in its dynamism and resource sensitivity; it can automatically adjust the resend window based on runtime conditions, achieving a balance between high-frequency resends and stability in the time-tolerance strategy. This significantly improves the responsiveness and throughput stability of periodic task processing under large-scale load scenarios.

[0090] in, This is the preset minimum time jump tolerance threshold, usually set to 1 second, to ensure that even when resources are extremely scarce, a minimum level of fault tolerance is maintained. The maximum time jump tolerance threshold is set to prevent invalid resends due to an excessively large tolerance window. It can be set to 5 seconds or 10 seconds depending on the architecture. The CPU idle rate is the percentage of CPU resources that are not currently occupied. It is collected in real time by the resource monitoring module and ranges from 0 to 100, reflecting the availability of current computing power. Task load percentage is defined as the ratio of the number of currently registered periodic tasks to the maximum supported task capacity.

[0091]

[0092] This indicator reflects the density of business pressure; the higher the value, the busier the workload, and the more cautious one should be in issuing supplementary payments.

[0093] In practice, the current CPU idle rate is checked every second, and the current task load percentage is calculated simultaneously. The ratio is used as a divisor to normalize the idle rate, yielding candidate values ​​for the resource-sensitive resending threshold under the current load. Then, double constraints are applied to ensure the calculated result is not less than... and not greater than This avoids false alarms due to excessively low thresholds or resource congestion due to excessively high thresholds. For example, if the current CPU idle rate is 60%, the current task load is 300, and the maximum supported task load is 1000, then:

[0094]

[0095] Substituting into the formula, we get:

[0096]

[0097] This indicates that current resources are sufficient but task density is high, therefore the maximum resending capacity is maintained to ensure the integrity of scheduled resending. However, if task density is extremely high and CPU idle rate decreases, for example, idle rate is 15% and task load is 90%, then:

[0098]

[0099] Even if the task accounts for a high percentage, it is still allowed to be resent within the maximum threshold to ensure that the integrity of the scheduling is not truncated.

[0100] Reference Figure 2In the initial state (S0), immediately after the startup or day-first task has completed initialization, the time fault tolerance process has not yet received the first valid time event, and is in the initial state waiting for time-driven activation. In the normal trigger state (S1), when a new timestamp is received every second, and the difference between the current timestamp and the reference timestamp Δt = 1, it indicates that time progression is stable, and the system enters the normal scheduling state. The current time factor is directly encapsulated as a time event and pushed to the event engine. In this state, no resending operation is performed; only the reference timestamp is updated, and the loop continues.

[0101] In the S2 resend state, if Δt > 1 and Δt ≤ T (where T is the current time jump tolerance threshold), it indicates that there are a few time jumps but they are still within the resend tolerance range. At this time, the state transitions to the resend state. In this state, all missed time points between the reference timestamp and the current timestamp are constructed into resend time factors and encapsulated as time events, and pushed to the event engine in sequence. After the resend is completed, the reference timestamp is updated and the process returns to S1 to continue scheduling.

[0102] In the S3 anomaly handling state, when Δt > T, meaning the time difference between the current timestamp and the reference timestamp exceeds the maximum tolerance threshold, it is judged as a serious anomaly jump, such as thread pause, blocking, or clock drift. At this point, the state transitions to the anomaly handling state. In this state, no resend operation is performed; only the current time event is triggered, and error logs are recorded and alarm notifications are generated. This state typically requires external monitoring or operations personnel to intervene to determine the source of the anomaly and perform manual intervention. Alternatively, after entering the S3 state, a rollback logic can be manually triggered through external operations (such as operations recovery, task state reset, clock resynchronization, etc.) to reset the current state from S3 back to S1, restoring the normal scheduling path and avoiding prolonged stay in the anomaly state.

[0103] S130: Start multiple task processing engines. Among them, the event processing engine is used to pool multiple time processing threads, the time scheduling engine is used to listen for time events and trigger the scheduling of periodic tasks, and the task execution engine dynamically adjusts the number of execution threads according to the load and executes periodic tasks.

[0104] After the timer is built and the time-driven component is registered during the service initialization phase, multiple task processing engines are started, each undertaking different functional modules such as event reception, scheduling judgment, and task issuance. The engines are connected through thread-safe message channels to form a complete periodic task processing chain.

[0105] The event processing engine is started first, and its function is to perform thread-level reception and preprocessing operations on the time events periodically pushed by the timer. Internally, the event processing engine pools multiple time processing threads through a thread pool mechanism. Each time processing thread has an independent event receiving channel and task buffer, used for parallel processing of time event messages from the timer in high-concurrency scenarios. "Pooling" refers to the pre-creating of a fixed number of thread resources using a thread pool to avoid performance degradation caused by frequent thread creation and destruction when tasks arrive, thus improving resource reuse efficiency and responsiveness. After receiving a time event, the time processing thread matches the event with the corresponding periodic task object according to the bound task type hash mapping strategy and pushes it to the scheduling and judgment stage.

[0106] The timing scheduling engine then starts, its responsibility being to listen for time events and periodic task object pairs pushed by the event processing engine. It combines the scheduling period field in the task object with the current timestamp to determine whether the task object meets the scheduling trigger conditions for this round. The scheduling period field specifies the time interval at which the task should be executed repeatedly, such as every 10 seconds, every minute, etc. The scheduling engine performs a modulo operation or time window comparison between the timestamp and the period field to determine if a scheduling point has been hit. When the scheduling condition is met, the scheduling engine encapsulates the periodic task object into a "task unit to be executed" and delivers it to the task receiving channel of the task execution engine.

[0107] After startup, the task execution engine initializes the task execution thread pool according to the configured minimum number of threads. It then dynamically adjusts the number of threads based on real-time monitoring metrics such as CPU load, task backlog, and response latency. This process is called "dynamic scaling," meaning the thread pool capacity automatically expands as the load increases and automatically reclaims excess thread resources when task density decreases, achieving real-time matching between resource scheduling and processing capacity. Each task execution thread, after obtaining a "task unit to be executed," first parses the task parameter fields (such as target number, operation direction, and operation price), and executes the compliance rule verification module to verify the task's legality. If the verification passes, it determines whether to use the policy service or the instruction adaptation interface to issue instructions based on the operation mode field in the task object, and obtains a receipt as the execution result. Finally, the task execution engine writes the execution result to the database and notifies the task management engine to update the task status, completing a full periodic task execution process.

[0108] The three task processing engines collaborate with each other and decouple their functions to form a closed-loop processing link from time triggering, task identification, scheduling judgment to instruction execution and state persistence, ensuring the efficient and stable execution of periodic tasks in multi-task types, asynchronous event-driven and high-concurrency scenarios.

[0109] S140: Load existing periodic tasks from the database and inject them into the event processing engine. Distribute time events by hash based on task type and update the status of existing periodic tasks.

[0110] In one possible implementation, existing periodic tasks are loaded from the database and injected into the event processing engine. Time events are then hash-distributed based on task type. Specifically, this includes: the task management engine connecting to the database and retrieving currently active periodic task records based on preset query conditions; converting each periodic task record into a standardized periodic task object, which includes a task identifier, task type, scheduling period, status field, and parameter configuration field; injecting each periodic task object into the event processing engine; having the time processing thread retrieve the corresponding time event and bind the time event to the periodic task object; and performing a hash algorithm based on the task type field in the periodic task object to determine the mapping thread after the time event and periodic task object are bound, and then distributing the mapping thread to the corresponding time processing thread.

[0111] Specifically, after initialization or the triggering of tasks at the beginning of the day, the task management engine connects to the database and executes structured query statements (such as SELECT) based on preset query conditions to extract periodic task records that are currently in an "active" state. This state is determined by the status field in the task record; for example, a status field value of "ENABLED" or "READY" indicates that the task should be scheduled within the current trading day. Each periodic task record contains multiple fields, including a task identifier (used to uniquely identify the task instance), a task type (indicating the category to which the task belongs, such as strategy or instruction), a scheduling period (specifying the repetitive triggering interval of the task), a status field (indicating the current scheduling status), and a parameter configuration field (encapsulating execution parameters, such as target number, operation price, etc.). The task management engine performs structured parsing of the above fields to generate standardized periodic task objects. The periodic task object is a runtime instance of the task maintained in memory, possessing a unified field structure and operable attributes.

[0112] Subsequently, the generated periodic task objects are injected into the event processing engine one by one. The event processing engine internally maintains a task receiving buffer queue. Each periodic task object enters a waiting state after injection until its scheduling trigger condition is met. After receiving a time event through the time event broadcast mechanism, the time processing thread retrieves the periodic task object from the buffer queue in the registration order and binds the time event with the periodic task object, forming a time-bound task pair.

[0113] To achieve thread load balancing and task type isolation, a consistent hashing algorithm is used to determine the mapped thread based on the task type field in the periodic task object. Let the task type field in the periodic task object be a string value. For example, "Auto Repurchase" uses a hash function. Perform a hash calculation on the string to obtain the hash value. The hash value space is a closed interval. Construct a virtual hash ring, and assign each time-processing thread identifier to it. One or more virtual nodes mapped to the hash space by a hash function. The hash value of each virtual node is ,in The redundancy factor is numbered, indicating the first redundancy factor. A virtual node.

[0114] Once a periodic task object is bound to a time event, its hash value is... Map to a hash ring and search for the first hash that is greater than or equal to the first hash in a clockwise direction. virtual nodes The thread corresponding to the virtual node This refers to the mapping thread after the time event is bound to a periodic task object. This mapping process can be represented as:

[0115]

[0116] If there is no greater than The virtual nodes are then searched again from the starting point of the hash ring, forming a loop logic to ensure that all tasks can be assigned. After the mapping is completed, the bound time events and periodic task objects are delivered to the event processing channel in the corresponding time processing thread for the thread to perform scheduling judgment and status update.

[0117] Three time processing threads were registered during initialization. Each thread corresponds to three virtual nodes, for a total of nine nodes distributed on the hash ring. A certain periodic task object has a task type of "AutoBuy", and its hash value calculated using MurmurHash3 is... Then find the first hash value on the hash ring that is greater than or equal to virtual nodes The corresponding thread is The task was then assigned to implement.

[0118] This mechanism enables thread mapping based on task type while injecting periodic task objects, thereby ensuring the isolation, load balancing, and predictability of task processing.

[0119] In one possible implementation, a hash algorithm is performed based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object. Specifically, this includes: constructing a hash ring, defining the hash space as a preset numerical range, and generating a unique thread identifier for each time processing thread; performing a hash calculation on each thread identifier to obtain multiple thread hash values; registering each thread hash value as a virtual thread node on the hash ring, with each time processing thread corresponding to one or more virtual thread nodes; for each periodic task object, extracting the task type field as a key and performing a hash calculation on the key to obtain the corresponding task hash value; in the hash ring, starting from the task hash value, searching clockwise for the target virtual node of the nearest thread virtual node among the multiple virtual thread nodes; determining that the time processing thread corresponding to the target virtual node is the mapping thread after the time event is bound to the periodic task object; if the task hash value is determined to be greater than the hash values ​​of all virtual thread nodes in the hash ring, then looping back to the beginning of the hash ring to continue searching until the mapping thread is determined; and pushing the time event bound to the periodic task object to the mapping thread for the time processing thread to perform scheduling judgments and status update operations.

[0120] Specifically, when constructing a hash ring, a fixed-length hash space is first preset, typically defined as a range from 0 to... The hash ring is a logically circular structure formed by unsigned integer closed intervals. This hash ring is a distributed structure used for mapping and searching, supporting clockwise searching for the node closest to the target hash value. The purpose of this structure is to provide a context boundary for the search range in subsequent consistent hashing algorithms, avoiding thread skew or uneven distribution problems in high-concurrency thread allocation.

[0121] To achieve the mapping and distribution of threads on the hash ring, a unique thread identifier is generated for each time-processing thread. The thread identifier can be a combination of the thread name or thread number and the identifier, ensuring uniqueness within the cluster environment. For example, the identifier for thread T1 could be "Thread-1@Node-A". Subsequently, a hash function is calculated for each thread identifier. It is recommended to use a non-cryptographic hash function with high dispersion and low collision rate, such as MurmurHash3, to obtain the hash value, which represents the thread's logical position on the hash ring.

[0122] To improve load balancing, multiple virtual thread nodes are generated for each processing thread at any given time. This means each real thread is mapped to multiple logical replicas, each with its own unique virtual thread identifier, such as "Thread-10" or "Thread-11". Each virtual thread identifier is hashed using a hash function, resulting in multiple discrete hash values ​​on a hash ring. This mapping using multiple virtual nodes significantly reduces the overall load migration issues caused by changes in task load or dynamic adjustments to the number of threads.

[0123] For each periodic task object, the task type field is extracted from the task object structure and used as the key for the consistent hashing algorithm. The task type field is usually a text identifier, such as "AutoRepurchase" or "AutoBuy". This key is input into the same hash function as the thread node to calculate a task hash value, which serves as the starting point for mapping thread lookup.

[0124] Starting with the task's hash value, traverse all registered virtual thread node hash values ​​in a clockwise direction within the hash ring, finding the first node greater than or equal to the task's hash value, and denote it as the target virtual node. This clockwise search operation exhibits monotonicity and local minimum variability, ensuring that periodic task objects with adjacent task hash values ​​are assigned to adjacent threads, reducing scheduling disturbances.

[0125] After identifying the target virtual node, the corresponding time processing thread is obtained based on the mapping relationship between the virtual node and the time processing thread. This thread serves as the mapping thread after the periodic task object is bound to the time event, i.e., the actual processing thread of the task. In extreme cases, such as when the task hash value is greater than the hash values ​​of all virtual nodes in the hash ring, the logical pointer is looped back from the maximum position in the hash space to the starting position to search again, ensuring the closure and integrity of the hash ring.

[0126] After mapping is completed, the binding structure formed by the time event and the periodic task object is submitted to the input queue of the selected mapping thread. The time processing thread then performs scheduling judgment and task status update operations to ensure the consistency between the event processing logic and the thread resource binding relationship.

[0127] For example, suppose there are three time-processing threads T1, T2, and T3, each allocated three virtual thread nodes, forming nine nodes scattered across a hash ring. The periodic task object "AutoBuy" is processed by a hash function, resulting in a task hash value of 2147483650. The first node with a value greater than this is found clockwise in the hash ring, locating node V8, whose corresponding thread is T2. The bound time event and the periodic task object are then pushed to the event processing channel handled by T2. This mechanism achieves stability, balance, and type awareness in thread allocation.

[0128] S150 is a task execution engine that parses the parameters of existing periodic tasks, performs risk control verification, distributes existing periodic tasks to target execution services according to the delegation strategy, obtains the execution results, and writes the execution results to the database.

[0129] In one possible implementation, after performing a consistent hash algorithm based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object, and distributing the mapping thread to the corresponding time processing thread, the method further includes: in the time processing thread, parsing the timestamp in the time event and the scheduling period field in the periodic task object to determine whether the periodic task object meets the current scheduling conditions; if it is determined that the periodic task object meets the current scheduling conditions, then updating the state of the periodic task object to the pending execution state; pushing the existing periodic tasks corresponding to the periodic task object with the pending execution state to the task execution engine; if it is determined that the periodic task object does not meet the current scheduling conditions, then maintaining the state of the periodic task object unchanged, and waiting for the subsequent scheduling cycle to make another judgment.

[0130] Specifically, after the time events and periodic task objects are mapped and delivered to the corresponding time processing threads, the time processing threads sequentially read the bound structures from the receiving queue and enter the scheduling judgment process. First, the thread extracts the timestamp field from the time event, which is the current second-level time and indicates the time point corresponding to the current scheduling cycle. Then, the thread extracts the scheduling period field from the periodic task object, which is a positive integer in seconds and specifies the repetition interval of the periodic task object. For example, a scheduling period field value of 60 indicates that the periodic task object should be triggered once every 60 seconds. The scheduling judgment logic performs a periodic condition determination based on the timestamp and scheduling period field, commonly using modulo arithmetic, i.e.:

[0131]

[0132] If the judgment condition is met, it means that the time event has just hit the trigger boundary of the periodic task object and meets the current scheduling condition; otherwise, the time event has not reached the scheduling window and needs to wait for the next round of time events to be re-judged.

[0133] If a periodic task object meets the current scheduling conditions, its status field is immediately updated to "Pending Execution". The status update operation is completed internally within the task object, usually through a thread-safe flag to prevent concurrent state write conflicts. The "Pending Execution" state is a transitional state of the periodic task object after scheduling judgment but before execution is completed, indicating that the task object has passed the scheduling admission check and is about to enter the execution process.

[0134] Subsequently, the periodic task objects with the "pending execution" status are delivered to the task receiving channel of the task execution engine. This process uses message passing through an inter-thread queue. The task execution engine asynchronously pulls the periodic task objects from the receiving channel and begins a series of subsequent processing steps, including parameter parsing, rule validation, path distribution, and writing execution results. This delivery mechanism decouples the time processing thread from the task execution thread, improving concurrent processing capabilities and the maintainability of the scheduling chain.

[0135] If the time processing thread determines that a periodic task object does not meet the current scheduling conditions (i.e., the current timestamp is not on its scheduling period boundary), it will not perform any modification operations on the task object, keeping its state fields unchanged and storing it in the thread-local task state table or buffer. The determination will be triggered again when the next time event arrives. This mechanism ensures that the scheduling behavior of task objects strictly depends on the periodic configuration and is not erroneously triggered by non-periodic time events, enhancing the stability and predictability of the scheduling mechanism.

[0136] As illustrated in one example, the scheduling period field of the periodic task object is 300 seconds, the task start time is 08:30:00, and the timestamp of the current time event is 08:45:00. The calculation yields:

[0137]

[0138] If the scheduling trigger condition is met, the status of the periodic task object is updated to "pending execution," and it is immediately pushed to the task execution engine, completing a closed-loop process from scheduling judgment to execution preparation. If the current timestamp is 08:46:00, then 900 + 60 = 960 seconds, and 960 \b mod 300 = 60 ≠ 0, so the scheduling condition is not met, and the task will remain in its original state, waiting for subsequent triggering. This mechanism ensures that task scheduling strictly follows the configuration cycle and avoids accidental triggering.

[0139] In one possible implementation, the task execution engine parses the parameters of existing periodic tasks, performs risk control verification, and distributes the existing periodic tasks to target execution services according to the delegation strategy. The execution results are then obtained and written to the database. Specifically, this includes: identifying target task objects in the pending execution state among the periodic task objects; outputting the target task objects to the task execution engine, extracting the parameter configuration fields of the target task objects, including target number, operation price parameter, operation quantity parameter, operation mode parameter, and scheduling priority parameter; parsing the parameter configuration fields into a unified internal execution data structure; loading a rule set matching the parameter configuration fields, and verifying the parameter configuration fields through the internal execution data structure, sequentially verifying whether the scheduling priority parameter meets the current operation requirements. The system checks whether the target object corresponding to the target object number is within a valid operation period, whether the operation price parameter is within the floating boundary range, and whether the operation quantity parameter exceeds the defined operation threshold limit. If the target task object passes the rule set verification, the corresponding task scheduling path is selected according to the rule set. If the task scheduling path is determined to be a strategy-driven path, the strategy service interface is called and the strategy calculation unit generates the operation instruction. If the task scheduling path is a direct instruction path, the operation instruction is sent through the instruction adaptation unit to the task intermediate dispatch interface. The operation instruction is submitted to the target execution service, and the response information returned by the target execution service is received. The response information includes the execution status, processing result, start and end timestamps, and feedback data. The response information is written to the database as the execution result, and the write operation adopts atomic transaction control.

[0140] Specifically, after periodically receiving periodic task objects in the pending execution state pushed by the time-processing thread, the task execution engine first retrieves the target task object currently in the pending execution state from the receiving channel. The target task object refers to the periodic task object that has passed scheduling judgment and is marked as "pending execution" in the task status field; it is the initial input for the task execution engine to formally enter the execution process. Filtering is performed through the task status table index or channel status filter to ensure that only task objects in a valid state are processed, avoiding re-entry and duplicate processing.

[0141] The task execution engine reads the parameter configuration field from the target task object structure. This field contains multiple parameter subfields, including the target object number (a unique identifier for the object to be operated on), the operation price parameter (representing the expected operation price), the operation quantity parameter (representing the planned quantity to be processed), the operation mode parameter (indicating whether strategy-driven or direct instruction is used), and the scheduling priority parameter (used to distinguish the processing order of tasks in the concurrent scheduling queue). This step ensures that the task engine obtains a complete set of business parameter foundations for subsequent unified structure parsing and verification operations.

[0142] The parameter parsing stage transforms the aforementioned parameter configuration fields into a unified internal execution data structure, typically represented as a task execution context object or intermediate model. This internal execution data structure is a fixed-length field structure with clear type definitions, boundary checking mechanisms, and field validity identifiers, facilitating subsequent module processing via a unified interface. This structure translates the raw parameters into a standard input format oriented towards execution logic, serving as a bridge for decoupling between various modules within the engine.

[0143] The rule set loading module dynamically loads matching rule sets based on parameter values ​​in the internal execution data structure. A rule set is a collection of multiple validation rules, each with its own judgment logic and exception handling strategy. Specifically, this includes: verifying whether the scheduling priority parameter meets the current resource scheduling strategy, such as whether low-priority tasks are allowed to execute during high load periods; checking whether the target number corresponds to the target within the operation's validity period, such as whether it's within the supported time window; verifying whether the operation price parameter is within the upper and lower limit floating boundary, which is dynamically defined by the business rules; and verifying whether the operation quantity parameter exceeds the maximum allowed operation threshold for a single task to prevent risk exposure or resource exhaustion.

[0144] If the target task passes all the checks in the above rule set, it enters the path decision stage. The task scheduling path is determined by the scheduling strategy module in combination with the operation mode parameters and the strategy switch field. If the judgment result is a strategy-driven path, the task execution engine will call the strategy service interface and send the internal execution data structure as input to the strategy calculation unit. The strategy calculation unit generates operation instructions based on the configured strategy template or runtime model. These instructions are in a structured command format and include fields such as target, method, parameters, and time identifier.

[0145] If the determination result is a direct instruction path, the instruction adaptation unit is invoked. This unit encapsulates the standard adaptation logic for interfacing with various execution services or intermediate dispatch interfaces. The adaptation unit translates the parameter fields in the internal execution data structure into an execution instruction format recognizable by the downstream interface and sends it to the task intermediate dispatch module via the network communication interface.

[0146] The operation instruction is submitted to the target execution service, which can be a trading platform, strategy engine, external trading interface, or simulator. The system receives the response information returned by the target execution service. The response information is a structured feedback body, which includes the execution status (success / failure / rejection), processing result (trading volume, transaction price, etc.), start and end timestamps (indicating execution time), and feedback data (abnormal information or processing remarks).

[0147] The task execution engine writes the response information as the task execution result to the database. Database writes employ atomic transaction control to ensure indivisibility, isolation, and consistency during the write process. If any field fails to be written during the task write process, the entire process will be rolled back to avoid inconsistencies. This write operation simultaneously triggers task status updates and execution log generation, ensuring that the execution of each periodic task is traceable and auditable.

[0148] For example, the operation mode parameters of a certain periodic task object are "strategy driven", the target number is "X123", the operation price is "100.50", the operation quantity is "200", and the scheduling priority is "3". The strategy service outputs an operation instruction based on the input: "Submit 200 units to the transaction interface at the best limit price within the current window". Finally, the target execution service returns "180 units were executed, some remain, status is successful". This information is persisted as the task execution result and fed back to the task management engine for status synchronization.

[0149] This embodiment also discloses a periodic task processing device, referring to... Figure 3 The device includes an acquisition module 301, a processing module 302, and an output module 303. It is used to execute any of the periodic task processing methods described above, wherein:

[0150] The acquisition module 301 is used to initialize the triggering logic of the beginning and end of the day tasks by parsing the task time parameters in the preset configuration file.

[0151] The processing module 302 is used to initialize the timer and bind it to the time-driven engine. The timer generates a time factor every second and executes a time fault tolerance algorithm based on the time jump tolerance threshold. It encapsulates the time factor into a time event and pushes it to the event engine to trigger the periodic task scheduling.

[0152] The processing module 302 is used to start multiple task processing engines. Among them, the event processing engine is used to pool multiple time processing threads, the time scheduling engine is used to listen for time events and trigger the scheduling of periodic tasks, and the task execution engine dynamically adjusts the number of execution threads according to the system load and executes periodic tasks.

[0153] The processing module 302 is used to load existing periodic tasks from the database and inject them into the event processing engine, perform hash distribution of time events based on task type, and update the status of existing periodic tasks.

[0154] The output module 303 is used by the task execution engine to parse the parameters of the existing periodic tasks, perform risk control verification, distribute the existing periodic tasks to the target execution service according to the delegation strategy, obtain the execution results, and write the execution results to the database.

[0155] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0156] This embodiment also discloses an electronic device, as shown in the reference. Figure 4 The electronic device may include: at least one processor 401, at least one communication bus 402, user interface 403, network interface 404, and at least one memory 405.

[0157] The communication bus 402 is used to enable communication between these components.

[0158] The user interface 403 may include a display screen and a camera. Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0159] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0160] The processor 401 may include one or more processing cores. The processor 401 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 405, and by calling data stored in memory 405. Optionally, the processor 401 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 401 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications. The GPU is responsible for rendering and drawing the content required for display on the screen. The modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 401 and may be implemented as a separate chip.

[0161] The memory 405 may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory 405 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 405 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 405 may also be at least one storage device located remotely from the aforementioned processor 401. As a computer storage medium, the memory 405 may include an operating system, a network communication module, a user interface 403 module, and an application program for a periodic task processing method.

[0162] exist Figure 4 In the illustrated electronic device, the user interface 403 is primarily used to provide an input interface for the user and to acquire user input data. The processor 401 can be used to call an application program stored in the memory 405 that performs a periodic task processing method. When executed by one or more processors 401, this causes the electronic device to perform one or more methods as described in the above embodiments.

[0163] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0164] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

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

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

[0167] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0168] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 405 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory 405 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0169] This application also discloses a computer-readable storage medium storing instructions. When executed by one or more processors 401, these instructions cause an electronic device to perform one or more methods as described in the above embodiments.

[0170] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truth. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for processing periodic tasks, characterized in that, The method includes: The triggering logic for the beginning and end of the day tasks is initialized by parsing the task time parameters in the preset configuration file. Initialize the timer and bind it to the time-driven engine. The timer generates a time factor every second and executes a time fault-tolerant algorithm based on the time jump tolerance threshold. The time factor is encapsulated as a time event and pushed to the event engine to trigger the periodic task scheduling. Multiple task processing engines are launched, including an event processing engine for pooling multiple time processing threads, a time-series scheduling engine for listening to the time events and triggering the scheduling of periodic tasks, and a task execution engine for dynamically adjusting the number of execution threads and executing the periodic tasks according to the system load. The system loads existing periodic tasks from the database and injects them into the event processing engine. It then performs hash distribution of time events based on task type and updates the status of the existing periodic tasks. The task execution engine parses the existing periodic tasks based on their parameters, performs risk control verification, distributes the existing periodic tasks to the target execution service according to the delegation strategy, obtains the execution results, and writes the execution results into the database. The time-tolerance algorithm based on the time jump tolerance threshold encapsulates time factors into time events and pushes them to the event engine, specifically including: Get the reference timestamp of the last successfully triggered task, and call the operating system time interface to get the current timestamp; Calculate the time difference between the current timestamp and the reference timestamp; The time difference is compared with a preset time jump tolerance threshold. If the time difference is less than or equal to the time jump tolerance threshold and equal to the preset time difference, the current timestamp is encapsulated as the time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp. If the time difference is greater than the preset time difference and less than or equal to the time jump tolerance threshold, then the time factor of each missed time point is reissued based on the time difference, and each time factor is encapsulated as a time event and pushed to the event engine in sequence. At the same time, the time factor corresponding to the current timestamp is encapsulated as a time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp. If the time difference is greater than the time jump tolerance threshold, the current timestamp is encapsulated as the time event and pushed to the event engine.

2. The periodic task processing method according to claim 1, characterized in that, The step of initializing the triggering logic for the beginning and end of the day tasks by parsing the task time parameters in the preset configuration file specifically includes: The daily task is triggered at a preset first moment, including reinitializing the timer and multiple task processing engines and reloading periodic task data; The end-of-day task is triggered at a preset second time, including destroying multiple instances of the task processing engine and terminating the task scheduling process.

3. The periodic task processing method according to claim 1, characterized in that, The process of loading existing periodic tasks from the database and injecting them into the event processing engine, and then hashing and distributing time events based on task type, specifically includes: The task management engine connects to the database and retrieves currently active periodic task records based on preset query conditions; Each of the aforementioned periodic task records is converted into a standardized periodic task object, which includes a task identifier, task type, scheduling period, status field, and parameter configuration field. The periodic task objects are injected one by one into the event processing engine, and the time processing thread obtains the corresponding time events and binds the time events to the periodic task objects. A hash algorithm is executed based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object, and the mapping thread is distributed to the corresponding time processing thread.

4. The periodic task processing method according to claim 3, characterized in that, After performing a consistent hashing algorithm based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object, and distributing the mapping thread to the corresponding time processing thread, the method further includes: In the time processing thread, the timestamp in the time event and the scheduling period field in the periodic task object are parsed to determine whether the periodic task object meets the current scheduling conditions. If it is determined that the periodic task object meets the current scheduling conditions, then the state of the periodic task object is updated to the pending execution state; The existing periodic tasks corresponding to the periodic task objects in the pending execution state are pushed to the task execution engine; If it is determined that the periodic task object does not meet the current scheduling conditions, the state of the periodic task object is maintained unchanged until the subsequent scheduling cycle is determined again.

5. The periodic task processing method according to claim 3, characterized in that, The step of executing the hash algorithm based on the task type field in the periodic task object to determine the mapping thread after the time event is bound to the periodic task object specifically includes: Construct a hash ring, define the hash space as a preset numerical range, and generate a unique thread identifier for each of the time processing threads; Perform a hash calculation on each of the thread identifiers to obtain multiple thread hash values; Each thread hash value is registered as a virtual thread node on the hash ring, and each time processing thread may correspond to one or more virtual thread nodes; For each of the periodic task objects, the task type field is extracted as a key, and the key is hashed to obtain the corresponding task hash value; In the hash ring, starting from the task hash value, the target virtual node of the nearest thread virtual node among the multiple virtual thread nodes is searched in a clockwise direction; The time processing thread corresponding to the target virtual node is determined to be the mapping thread after the time event is bound to the periodic task object; If it is determined that the hash value of the task is greater than the hash values ​​of all the virtual thread nodes in the hash ring, then the search continues to wrap around to the beginning of the hash ring until the mapped thread is determined. After the time event is bound to the periodic task object, it is pushed to the mapping thread for the time processing thread to perform scheduling judgment and status update operations.

6. The periodic task processing method according to claim 4, characterized in that, The process involves the task execution engine parsing the parameters of the existing periodic tasks, performing risk control verification, distributing the existing periodic tasks to the target execution service according to the delegation strategy, obtaining the execution results, and writing the execution results into the database. Specifically, this includes: Identify the target task object in the pending execution state among the periodic task objects; Output the target task object to the task execution engine, and extract the parameter configuration fields of the target task object, including the target number, operation price parameter, operation quantity parameter, operation mode parameter, and scheduling priority parameter; The parameter configuration fields are parsed into a unified format internal execution data structure; Load a set of rules that match the parameter configuration fields, and validate the parameter configuration fields through the internal execution data structure. This includes sequentially verifying whether the scheduling priority parameter meets the current operation requirements, whether the target number corresponding to the target is in a valid operation period, whether the operation price parameter is within the floating boundary range, and whether the operation quantity parameter exceeds the defined operation threshold limit. If the target task object passes the verification of the rule set, then the corresponding task scheduling path is selected according to the rule set; If the task scheduling path is determined to be a policy-driven path, then the policy service interface is invoked and the policy calculation unit generates operation instructions. If the task scheduling path is a direct command path, the operation command is sent through the command adaptation unit to the task intermediate dispatch interface. The operation instruction is submitted to the target execution service, and the response information returned by the target execution service is received. The response information includes the execution status, processing result, start and end timestamps, and feedback data. The response information is written to the database as the execution result, and the write operation is controlled by atomic transactions.

7. A periodic task processing device, characterized in that, The apparatus is used to perform a periodic task processing method as described in any one of claims 1-6, the apparatus comprising an acquisition module (301), a processing module (302), and an output module (303), wherein: The acquisition module (301) is used to initialize the triggering logic of the beginning-of-day task and the end-of-day task by parsing the task time parameters in the preset configuration file; The processing module (302) is used to initialize a timer and bind a time-driven engine. The timer generates a time factor every second and executes a time fault-tolerant algorithm based on a time jump tolerance threshold. It encapsulates the time factor into a time event and pushes it to the event engine to trigger the periodic task scheduling. The processing module (302) is used to start multiple task processing engines, wherein the event processing engine is used to pool multiple time processing threads, the time scheduling engine is used to listen to the time events and trigger the scheduling of periodic tasks, and the task execution engine dynamically adjusts the number of execution threads according to the system load and executes the periodic tasks. The processing module (302) is used to load existing periodic tasks from the database and inject them into the event processing engine, perform hash distribution of time events based on task type, and update the status of the existing periodic tasks. The output module (303) is used by the task execution engine to parse the task based on the parameters of the existing periodic task, perform risk control verification, distribute the existing periodic task to the target execution service according to the delegation strategy, obtain the execution result and write the execution result into the database. The acquisition module (301) is used to acquire the reference timestamp of the last successfully triggered task and call the operating system time interface to acquire the current timestamp; The processing module (302) is used to calculate the time difference between the current timestamp and the reference timestamp; The processing module (302) is used to compare the time difference with a preset time jump tolerance threshold. If the time difference is less than or equal to the time jump tolerance threshold and equal to the preset time difference, the current timestamp is encapsulated as the time event and pushed to the event engine, and the reference timestamp is updated to the current timestamp. The processing module (302) is configured to, if the time difference is greater than the preset time difference and less than or equal to the time jump tolerance threshold, reissue the time factor for each missed time point based on the time difference, encapsulate each time factor as a time event and push it to the event engine in sequence, and encapsulate the time factor corresponding to the current timestamp as the time event and push it to the event engine, and update the reference timestamp to the current timestamp. The processing module (302) is used to encapsulate the current timestamp into the time event and push it to the event engine if the time difference is greater than the time jump tolerance threshold.

8. An electronic device, characterized in that, The device includes a processor (401), a communication bus (402), a user interface (403), a network interface (404), and a memory (405). The memory (405) is used to store instructions. The user interface (403) and the network interface (404) are both used to communicate with other devices. The communication bus (402) is used to realize the connection and communication between the components within the electronic device. The processor (401) is used to execute the instructions stored in the memory (405) so that the electronic device performs the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-6.

Images