Periodic task processing method and device

Abstract

The invention provides a periodic task processing method and device, and relates to the technical field of automation programs.The method comprises the steps that day beginning and day end task trigger logic is initialized by analyzing a configuration file, a timer is started, a time driving engine is bound, a time jump tolerance threshold value is combined to execute a time fault tolerance algorithm, and a time jump tolerance threshold value is set; and the time events are continuously generated and pushed to the event engine. An event processing engine, a time sequence scheduling engine and a task execution engine are further started, and decoupling cooperation of time event receiving, scheduling judgment and task execution is achieved. And after being loaded from the database, the periodic task objects are subjected to hash distribution according to task types, so that thread-level load balancing is realized. And the task execution engine analyzes the parameters, completes risk control verification and path selection, persistently writes an operation result into a database, and constructs a closed-loop efficient scheduling processing link. The processing efficiency of the periodic task can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of automated programs, and in particular to a method and device for processing periodic tasks. Background Art

[0002] Periodic tasks are the fundamental building blocks of automated trading systems. Common periodic tasks include, but are not limited to, automated share reductions, automated repurchases, automated reverse repurchases, and automated new share issuance. These tasks typically require triggering and delivering feedback on operational instructions according to established rules within specific trading hours. Due to the diverse nature of these tasks and their highly concentrated triggering times, the system must not only ensure accurate timing of these tasks, but also maintain isolation between tasks and flexible execution paths. 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 generally have problems with coarse granularity in thread resource scheduling and imprecise task classification in task processing architectures. There is a lack of a unified thread pool management strategy and a dynamic distribution mechanism that is aware of task types. This results in similar tasks easily aggregating in the same thread, causing blockage, and inability to achieve load balancing between tasks of different types. When the number of concurrent tasks in the system increases sharply, task queuing delays increase, and the execution failure rate rises, seriously affecting the predictability and consistency of automated tasks, leading to transaction delays, policy failures, and even compliance risks. To address the above issues, there is an urgent need to construct a periodic task processing method based on refined thread pool hierarchical management and a type-driven distribution 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] The present application provides a method and apparatus for processing periodic tasks, which can improve the processing efficiency of periodic tasks.

[0006] In a first aspect of the present application, a method for processing a periodic task is provided, the method comprising: Initialize the triggering logic for the start-of-day and end-of-day tasks by parsing the task time parameters in the preset configuration file; Initialize a 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 a time jump tolerance threshold. The time factor is encapsulated as a time event and pushed to the event engine to trigger periodic task scheduling. Start multiple task processing engines, where the event processing engine is used to pool multiple time processing threads, the timing scheduling engine is used to monitor 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; Loading existing periodic tasks from the database and injecting them into the event processing engine, performing hash distribution on time events based on task types, and updating the status of the existing periodic tasks; The task execution engine performs task analysis based on the parameters of the existing periodic tasks, performs risk control verification, and 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.

[0007] Based on the above technical solution, preferably, the triggering logic of initializing the start-of-day task and the end-of-day task by parsing the task time parameters in the preset configuration file specifically includes: Triggering the daily task at a preset first moment, including reinitializing the timer and the plurality of task processing engines and reloading periodic task data; The end-of-day task is triggered at a preset second moment, including destroying multiple instances of the task processing engine and terminating the task scheduling process.

[0008] Based on the above technical solution, preferably, the method of executing a time fault tolerance algorithm based on a time jump tolerance threshold, encapsulating the time factor into a time event and pushing it to the event engine, specifically includes: Get the reference timestamp of the last successful task triggering, and call the operating system time interface to get the current timestamp; Calculating a 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, encapsulating the current timestamp as the time event and pushing it to the event engine, and updating the reference timestamp 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, the time factor of each missing time point is reissued based on the time difference, and each of the time factors is respectively encapsulated as the 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 the time event and pushed to the event engine together, 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.

[0009] On the basis of the above technical solutions, preferably, the loading of the inventory periodic tasks from the database and the injection into the event processing engine, the time events are distributed based on the task type, and specifically comprising: The task management engine connects the database and retrieves the periodic task records currently in an active state based on a preset query condition; Each of the periodic task records is converted into a standardized periodic task object, and the periodic task object includes a task identifier, a task type, a scheduling period, a state field, and a parameter configuration field; The periodic task objects are injected into the event processing engine one by one, the corresponding time events are obtained by the time processing thread, and the time events are bound to the periodic task objects; Based on the task type field in the periodic task object, a hash algorithm is executed 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.

[0010] On the basis of the above technical solutions, preferably, after the consistent 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, the method further comprises: 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 condition; If it is determined that the periodic task object meets the current scheduling condition, the state of the periodic task object is updated to a to-be-executed state; The inventory periodic task corresponding to the periodic task object in the to-be-executed state is pushed to the task execution engine; If it is determined that the periodic task object does not meet the current scheduling condition, the state of the periodic task object is maintained unchanged, and the periodic task object is judged again in the subsequent scheduling period.

[0011] On the basis of the above technical solutions, preferably, the 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 specifically comprising: A hash ring is constructed, the hash space is defined as a preset numerical range, and a unique thread identifier is generated for each time processing thread; Each of the thread identifiers is subjected to hash calculation to obtain a plurality of thread hash values; Registering each of the thread hash values ​​as a virtual thread node on the hash ring, wherein each of the time processing threads may correspond to one or more virtual thread nodes; For each of the periodic task objects, extract the task type field as a keyword, and perform hash calculation on the keyword to obtain a corresponding task hash value; In the hash ring, starting from the task hash value, searching for a target virtual node of the nearest thread virtual node among the multiple virtual thread nodes in a clockwise direction; Determine that the time processing thread corresponding to the target virtual node is a mapping thread after the time event is bound to the periodic task object; If it is determined that the task hash value is greater than the hash values ​​of all the virtual thread nodes in the hash ring, then loop back to the starting position of the hash ring and continue searching until the mapping thread is determined; The time event is bound to the periodic task object and then pushed to the mapping thread for the time processing thread to perform scheduling judgment and status update operations.

[0012] Based on the above technical solution, preferably, the task execution engine performs task parsing based on the parameters of the existing periodic tasks, 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, specifically including: Determining a target task object in the waiting-to-be-executed 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; Parsing the parameter configuration fields into an internal execution data structure in a unified format; Loading a rule set matching the parameter configuration field, verifying the parameter configuration field through the internal execution data structure, and sequentially verifying whether the scheduling priority parameter meets the current operation requirements, whether the target corresponding to the target number 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 a corresponding task scheduling path is selected according to the rule set; If it is determined that the task scheduling path is a policy-driven path, the policy service interface is called and the policy calculation unit generates an operation instruction; If the task scheduling path is a direct instruction type path, the operation instruction is sent through the instruction adaptation unit to the task intermediate dispatch interface; Submitting the operation instruction to the target execution service and receiving response information returned by the target execution service, wherein the response information includes execution status, processing results, start and end timestamps and feedback data; The response information is written into the database as the execution result, and the writing operation adopts atomic transaction control.

[0013] In a second aspect of the present application, a periodic task processing device is provided, the device being configured to execute any one of the periodic task processing methods described above. The device comprises an acquisition module, a processing module, and an output module, wherein: 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; The processing module is used to initialize the timer and bind it to the time-driven engine. The timer generates a time factor every second, executes a time fault tolerance algorithm based on a time jump tolerance threshold, encapsulates the time factor into a time event, and pushes it to the event engine to trigger periodic task scheduling. 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 timing scheduling engine is used to monitor 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 is used to load the existing periodic tasks from the database and inject them into the event processing engine, perform hash distribution on the time events based on the task type, and update the status of the existing periodic tasks; The output module is used for the task execution engine to perform task analysis based on the parameters of the existing periodic tasks, perform risk control verification, and 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.

[0014] In the third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface and a network interface, 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 so that the electronic device performs any of the methods described above.

[0015] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions. When the instructions are executed, any one of the methods described above is executed.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. This application constructs a periodic task scheduling architecture that integrates event-driven and time-driven approaches, adopts a thread pool hierarchical management mechanism and a task type-driven hash distribution strategy to achieve concurrency isolation and load balancing in task scheduling; introduces a time fault-tolerant algorithm and a dynamic jump tolerance threshold to ensure the continuity of time events and scheduling stability; and combines standardized parsing, rule verification, and path adaptation mechanisms of periodic task objects to enhance the flexibility and responsiveness of the task execution link, thereby effectively reducing task delays and blocking risks in high-concurrency scenarios and significantly improving the overall processing efficiency of periodic tasks.

[0017] 2. By introducing a time fault-tolerant algorithm and combining it with a time jump tolerance threshold to dynamically determine the time difference, we ensure that missed time events are automatically reissued when non-fatal anomalies such as system delays, jitter, or short-term blockages occur, thereby effectively ensuring the time continuity and stability of periodic task scheduling and improving the accuracy of task triggering in uncertain environments.

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

[0019] 4. By making precise judgments based on the timestamp 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 of scheduling triggers, avoids resource waste and false triggers, and further enhances the execution controllability of periodic tasks and the stability of system scheduling.

[0020] 5. By building a consistent hash ring, generating virtual thread nodes, and performing hash mapping based on the task type field, type-aware distribution of periodic tasks between time processing threads is achieved. Combined with a clockwise search and wraparound mechanism, this ensures that all tasks can be mapped to specific threads, effectively improving task dispersion between threads and system scalability.

[0021] 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 to ensure 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, high accuracy of task execution and full-process closed-loop control are achieved, thereby enhancing the system's security, traceability and task processing integrity of the automated policy execution process. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a flowchart of a periodic task processing method disclosed in an embodiment of the present application; Figure 2 It is a state transition diagram based on time fault tolerance disclosed in an embodiment of the present application; Figure 3 This is a module diagram of a periodic task processing device disclosed in an embodiment of the present application; Figure 4 This is a structural diagram of an electronic device disclosed in an embodiment of the present application.

[0023] Explanation of the reference numerals: 301, acquisition module; 302, processing module; 303, output module; 401, processor; 402, communication bus; 403, user interface; 404, network interface; 405, memory. DETAILED DESCRIPTION

[0024] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

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

[0026] In the description of the embodiments of the present application, the term "multiple" means two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0027] In securities trading scenarios, periodic tasks are the basis for achieving automated strategy execution. However, existing technologies have problems with coarse thread scheduling granularity, imprecise task classification, and a lack of type awareness in the distribution mechanism when processing periodic tasks. These problems lead to the aggregation and blocking of similar tasks and uneven load on heterogeneous tasks. In high-concurrency scenarios, these problems can easily lead to 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 sophisticated thread pool hierarchical management and task type-driven distribution mechanism to improve task processing efficiency and system responsiveness.

[0028] This embodiment discloses a periodic task processing method, referring to Figure 1 , including the following steps S110-S150: S110 , initializing 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.

[0029] The present invention discloses a periodic task processing method for a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablet computers, wearable devices, and personal computers (PCs), and may also be a background server that runs a periodic task processing method. The server may be implemented as a standalone server or a server cluster consisting of multiple servers.

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

[0031] Specifically, a trigger condition is set at a preset first moment, preferably the daily opening time. The timer scheduling component monitors the trading calendar and time signals. When the time matches the opening time, the daily task flow is triggered. First, the timer is reinitialized. This involves resetting the timer used to generate the time factor in the time driver module, clearing any remaining state information from the previous trading day, including the timestamp cache and event sequence number, and re-starting the time callback mechanism with second-level accuracy. This timer, as the core of the time driver, generates a time factor once per second. This is subsequently encapsulated as a time event to drive the scheduling process, ensuring the integrity and continuity of the time series. Subsequently, multiple task processing engines are restarted in sequence, including the event processing engine, the time sequence 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 the thread binding logic to ensure that the task processing context of the previous trading day is fully cleared. For example, the time processing thread in the event processing engine must be rebound to the timer callback flow, the time sequence scheduling engine must reattach the time event distribution channel, and the task execution engine must rebuild the execution thread resource pool based on the current load. After engine initialization, the task management engine filters periodic task records from the database by "activation status," parses them into periodic task objects, and injects them into the event processing engine for scheduling and execution triggered by subsequent time events. Reloading periodic task data includes not only reading parameter fields but also synchronizing status fields, calculating scheduling periods, and resetting the initial scheduling position, ensuring that all periodic tasks enter a unified scheduling process from the start.

[0032] By synchronizing with the exchange's closing time, the end-of-day task process is triggered when the preset second moment is detected, preferably the daily close. First, multiple task processing engine instances are destroyed, completely releasing the thread pool resources, cached data structures, and running status flags maintained by the event processing engine, timing scheduling engine, and task execution engine. Specifically, all time processing threads in the event processing thread pool exit their execution loops sequentially via interrupt signals and unregister callbacks with the time-driven component. The timing scheduling engine stops listening for time events, disconnects the event input stream, and clears the task schedule table. The task execution engine stops accepting new task requests and transitions all task objects in the "pending" state to the "terminated" state, updating the database to prevent repeated execution the next day. Terminating the task schedule also involves resetting the status flag in the schedule controller, suspending the event broadcast channel, and logging the engine shutdown, ensuring that the entire schedule remains frozen after the market closes, no longer responding to external time factors or task input events. To illustrate this with an example: After the closing event is triggered at 3:00 PM daily, the engine shutdown API is called sequentially within 3:00:01 PM, completing the destruction of all engine resources and state migration within an average of 200 milliseconds, thus providing a clean environment for reinitialization on the next trading day. This mechanism prevents residual task state from contaminating the next round of trade execution, effectively ensuring the isolation of the scheduling process and the clarity of the time rhythm.

[0033] S120, 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. The time factor is encapsulated as a time event and pushed to the event engine to trigger periodic task scheduling.

[0034] In one possible implementation, a time fault tolerance algorithm is executed based on a time jump tolerance threshold, and the time factor is encapsulated as a time event and pushed to the event engine, specifically including: obtaining the reference timestamp of the last successful task triggering, 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 is equal to the preset time difference, 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, 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 turn, and 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 a time event and pushed to the event engine.

[0035] Specifically, after the timer is initialized, an independent time-driven thread is started, which establishes a binding relationship with the operation-level time interface to ensure that the current timestamp can be obtained with second-level accuracy. The 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 indicates the time point when the time event was successfully generated and pushed last time, and is the time benchmark for all scheduling behaviors; the current timestamp is the current second-level time, which comes from the operation call and has high precision and stability. The above two timestamps are used as inputs to the time fault-tolerant algorithm to evaluate whether there is time jump or missed triggering behavior.

[0036] 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, it should be 1, indicating that time is progressing normally and no event triggers are missed. When the time interval difference is less than or equal to the 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 corrected by retransmission, while those exceeding this threshold are considered serious anomalies.

[0037] If the time interval difference is 1, meaning the current timestamp differs from the reference timestamp by exactly one second, time progression is stable and no retransmission is required. 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 decisions by the time processing thread. Once the push is complete, the reference timestamp is updated to the current timestamp, establishing a new baseline for the next iteration.

[0038] If the time interval difference is greater than 1 but less than or equal to the time jump tolerance threshold, it means that there are one or more missed time points during this period. Construct a reissue time series, from all second-level time points between 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 to form a batch event list. Push these time events to the event engine in sequence to ensure that the event engine receives them one by one in chronological order to restore the integrity of the time drive; then encapsulate the current timestamp as a time event and push it additionally, forming a one-time reissue and current trigger joint push operation. After the reissue is completed, the reference timestamp is synchronously updated to the current timestamp to maintain the next round of time benchmark.

[0039] If the time interval difference exceeds the time jump tolerance threshold, a serious timing anomaly is identified, such as a thread pause, restart, or time service interruption. To avoid invalid reissues and resource waste, only the current timestamp is encapsulated as a time event and pushed directly to the event engine. Recovery of missed time is abandoned, and an exception log is recorded for analysis by the monitoring module. This log records the time interval difference, current timestamp, reference timestamp, and jump cause determination for use in operations and maintenance or scheduling audits.

[0040] 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:

[0041] Used to dynamically adjust the time jump tolerance threshold , ensuring that the time fault-tolerant algorithm takes into account the processing feasibility and scheduling continuity in high-concurrency task scenarios while guaranteeing responsiveness. This formula dynamically calculates the maximum acceptable reissue window at each moment by introducing the current CPU resource usage and task load ratio, thereby achieving adaptive optimization of the time tolerance mechanism. The advantage of this algorithm lies in its dynamism and resource sensitivity. It can self-adjust the reissue window according to the running state, so that the time fault-tolerant strategy can strike a balance between high-frequency reissue and stability, thereby significantly improving the response adaptability and throughput stability of periodic task processing in large-scale load scenarios.

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

[0043] This indicator is used to reflect the density of business pressure. The higher the value, the busier it is, and the more cautious the time reissue should be.

[0044] During the specific implementation process, the current CPU idle rate is detected once per second, and the current task load ratio is calculated simultaneously The ratio is used as a divisor to normalize the idle rate and obtain the candidate value of the resource sensitive reissue threshold under the current load. Then, through double restrictions, ensure that the calculated result is not less than and no greater than , to avoid false alarms caused by too low thresholds or resource blocking caused by too high thresholds. For example, if the current CPU idle rate is 60, the current task volume is 300, and the maximum supported task volume is 1000, then:

[0045] Substituting into the formula we get:

[0046] This means that the current resources are sufficient but the task density is high, so the maximum reissue capacity is still maintained to ensure the integrity of the reissue scheduling. If the task density is extremely high and the CPU idle rate decreases, for example, the idle rate is 15% and the task load is 90%, then:

[0047] Even if the task ratio is high, it will still be reissued within the maximum allowed threshold to ensure that the scheduling integrity is not interrupted.

[0048] Reference Figure 2In the initial state S0, after the startup or initialization of the daily task, the time fault tolerance process has not yet received the first valid time event and is in the initial state waiting for the time driver to activate. 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 is Δt = 1, it indicates that time advancement is stable and 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 re-issuance operation is performed, only the reference timestamp is updated, and the cycle continues.

[0049] In the S2 reissue state, if Δt > 1 and Δt ≤ T (where T is the current time jump tolerance threshold), indicating a small amount of time jump but still within the reissue tolerance range, the state transitions to the reissue state. In this state, all missing time points between the reference timestamp and the current timestamp are constructed one by one as reissue time factors and encapsulated as time events. These are pushed to the event engine in sequence. After the reissue is completed, the reference timestamp is updated and the system returns to S1 to continue scheduling.

[0050] In the S3 exception handling state, when Δt>T, that is, the time difference between the current timestamp and the reference timestamp exceeds the maximum tolerance threshold, it is judged as a serious abnormal jump, such as thread suspension, blocking, or clock drift, and the state is transferred to the exception handling state. In this state, no reissue operation is performed, only the current time event is triggered, and the error log is recorded and an alarm notification is generated. This state usually requires external monitoring or intervention by operations and maintenance personnel to determine the source of the exception and perform manual intervention. This means that after being in the S3 state, the fallback logic is manually triggered through external operations (such as operation and maintenance recovery, task status reset, clock resynchronization, etc.), resetting the current state from S3 to S1, restoring the normal scheduling path, and avoiding prolonged stay in the abnormal state.

[0051] S130, start multiple task processing engines, among which the event processing engine is used to pool multiple time processing threads, the timing scheduling engine is used to monitor 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.

[0052] After completing the timer construction and time-driven component registration in the service initialization phase, multiple task processing engines are started, each of which is responsible for different functional modules such as event reception, scheduling judgment, and task delivery. The engines are connected through thread-safe message channels to form a complete periodic task processing chain.

[0053] The event processing engine is started first. Its function is to receive and pre-process the time events pushed periodically by the timer at the thread level. The event processing engine internally pools multiple time processing threads through the thread pool mechanism. Each time processing thread has an independent event receiving channel and task buffer area, which is used to parallelly process time event messages from the timer in high-concurrency scenarios. The so-called "pooling" refers to the use of the thread pool to pre-create a fixed number of thread resources to avoid performance loss caused by frequent creation and destruction of threads when tasks arrive, thereby improving resource reuse efficiency and responsiveness. After receiving the time event, the time processing thread will match the event with the corresponding periodic task object based on the bound task type hash mapping strategy, and push it to the scheduling judgment link.

[0054] The timing scheduling engine is then started. Its responsibility is to listen to the time events and periodic task object pairs pushed by the event processing engine, and to determine whether the task object meets the trigger conditions for this round of scheduling by combining the scheduling period field in the task object with the current timestamp. The scheduling period field indicates the time interval at which the task should be repeated, such as every 10 seconds, every 1 minute, etc. The scheduling engine performs a remainder judgment or a time window comparison on the timestamp and the period field to determine whether the scheduling point is hit. When the scheduling conditions are hit, the scheduling engine encapsulates the periodic task object as a "task unit to be executed" and delivers it to the task receiving channel of the task execution engine.

[0055] After startup, the task execution engine initializes the task execution thread pool based on the configured minimum number of threads and dynamically adjusts the number of threads based on real-time monitoring of indicators such as CPU load, task backlog, and response latency. This process is called "dynamic scaling," meaning that the thread pool capacity automatically expands as the load increases, and automatically reclaims excess thread resources when task density decreases, thereby achieving real-time matching of resource scheduling and processing power. After obtaining the "task unit to be executed," each task execution thread first parses the task parameter fields (such as the target number, operation direction, and operation price), executes the compliance rule verification module to verify the legitimacy of the task, and after passing the verification, determines whether to use the policy service or the instruction adapter interface to issue the instruction 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 results to the database and notifies the task management engine to update the task status, completing a complete periodic task execution process.

[0056] The three task processing engines collaborate with each other and decouple their functions, forming a closed-loop processing chain 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.

[0057] S140 , loading the existing periodic tasks from the database and injecting them into the event processing engine, performing hash distribution on the time events based on the task type, and updating the status of the existing periodic tasks.

[0058] In one possible implementation, existing periodic tasks are loaded from a database and injected into an event processing engine, and time events are hashed and distributed based on task types, specifically including: a task management engine connects to a database and retrieves periodic task records that are currently active based on preset query conditions; each periodic task record is converted into a standardized periodic task object, and the periodic task object includes a task identifier, a task type, a scheduling period, a status field, and a parameter configuration field; the periodic task objects are injected into the event processing engine one by one, and the time processing thread obtains the corresponding time event and binds the time event to the periodic task object; 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.

[0059] Specifically, the task management engine connects to the database after initialization or the triggering of the daily task, executes structured query statements (such as SELECT) based on preset query conditions, and extracts periodic task records that are currently in the "activated" state. This state is determined by the status field in the task record. For example, if the status field value is "ENABLED" or "READY", it means 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 a strategy class or an instruction class), a scheduling cycle (specifying the time interval for repeated triggering of the task), a status field (identifying the current scheduling status), and a parameter configuration field (encapsulating execution parameters, such as the target number, operation price, etc.). The task management engine performs structured parsing on the above fields to generate standardized periodic task objects. Periodic task objects are runtime instances of tasks maintained in memory, with a unified field structure and operational properties.

[0060] The generated periodic task objects are then injected one by one into the event processing engine. The event processing engine maintains a task receiving buffer queue. After injection, each periodic task object enters a waiting state until its scheduling trigger condition is met. Upon receiving a time event through the time event broadcast mechanism, the time processing thread extracts the periodic task objects from the buffer queue in the order in which they were registered and binds the time event to the periodic task object, forming a time-bound task pair.

[0061] To achieve thread load balancing and task type isolation, a consistent hashing algorithm is executed based on the task type field in the periodic task object to determine the mapping thread. Let the task type field in the periodic task object be a string value , such as "Auto Repurchase", using a hash function Hash the string to get the hash value , the hash value space is a closed interval . Build a virtual hash ring and process the thread identifier every time Mapped to one or more virtual nodes in the hash space through a hash function , the hash value of each virtual node is ,in is the redundancy factor number, indicating the A virtual node.

[0062] When the periodic task object is bound to the time event, its hash value Map to the hash ring and search clockwise for the first value greater than or equal to Virtual nodes , the thread corresponding to the virtual node This is the mapping thread after the time event is bound to the periodic task object. The mapping process can be expressed as:

[0063] If there is no greater than If a virtual node is found, it will be re-searched from the starting point of the hash ring, forming a wraparound logic to ensure that all tasks can be assigned. After the mapping is completed, the bound time event and periodic task object pair is delivered to the event processing channel of the corresponding time processing thread, allowing the thread to complete scheduling judgment and status update.

[0064] Three time processing threads are registered during initialization , each thread corresponds to three virtual nodes, a total of nine nodes are distributed on the hash ring. The task type of a periodic task object is "AutoBuy", and the 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 , and its corresponding thread is , the task is assigned to implement.

[0065] Through this mechanism, while injecting periodic task objects, thread mapping based on task type is realized, thereby ensuring the isolation, load balancing and scheduling predictability of task processing.

[0066] In one possible implementation, a hash algorithm is executed based on a task type field in a periodic task object to determine a mapping thread after a time event is bound to the periodic task object. The method specifically includes: constructing a hash ring, defining a hash space within a preset value 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, where each time processing thread may correspond to one or more virtual thread nodes; for each periodic task object, extracting the task type field as a keyword and performing a hash calculation on the keyword to obtain a corresponding task hash value; starting from the task hash value, searching the hash ring for a target virtual node that is the nearest thread virtual node among multiple virtual thread nodes in a clockwise direction; 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 it is determined that the task hash value is greater than the hash values ​​of all virtual thread nodes in the hash ring, looping back to the starting position of the hash ring to continue searching until the mapping thread is determined; and pushing the time event to the periodic task object after binding to the mapping thread for the time processing thread to perform scheduling judgment and status update operations.

[0067] Specifically, when constructing a hash ring, a fixed-length hash space is first preset, usually defined as a space from 0 to A closed interval of unsigned integers forms a logical ring structure. This hash ring is a distributed structure used for mapping and search, supporting clockwise searches for the node closest to the target hash value. This structure provides contextual boundaries for the subsequent consistent hashing algorithm to avoid thread skew or uneven allocation during high-concurrency thread allocation.

[0068] To achieve thread mapping and distribution on the hash ring, a unique thread identifier is generated for each time processing thread. The thread identifier can be a thread name or a combination of thread number and identifier to ensure uniqueness within the cluster. For example, thread T1 can be identified as "Thread-1@Node-A." A hash function is then applied to each thread identifier. A highly distributed, low-collision, non-cryptographic hash function such as MurmurHash3 is recommended. The resulting hash value represents the thread's logical position on the hash ring.

[0069] To improve the distribution balance, multiple virtual thread nodes are generated for each time processing thread, that is, each real thread is mapped to multiple logical copies, each copy has an independent virtual thread identifier, such as "Thread-10", "Thread-11", etc. Each virtual thread identifier is calculated by a hash function and forms multiple discrete hash values on the hash ring. Through multiple virtual node mapping, the overall load migration problem caused by task quantity change or thread number dynamic adjustment can be significantly reduced.

[0070] For each periodic task object, the task type field is extracted from the task object structure as the key of the consistency hash algorithm. The task type field is usually a text identifier, such as "AutoRepurchase", "AutoBuy", etc. The key is input into the same hash function as the thread node to calculate a task hash value as the starting point for the mapping thread search.

[0071] In the hash ring, the task hash value is taken as the starting point, and all registered virtual thread node hash values are traversed in the clockwise direction to find the first node greater than or equal to the task hash value, which is recorded as the target virtual node. This clockwise search operation has monotonicity and local minimum variability, which can ensure that periodic task objects with adjacent task hash values are assigned to adjacent threads, reducing scheduling disturbance.

[0072] After determining the target virtual node, the corresponding time processing thread is obtained according to the mapping relationship between the virtual node and the time processing thread, which is the mapping thread after the periodic task object is bound with the time event, that is, the actual processing thread of the task. In the extreme case, if the task hash value is greater than all virtual node hash values in the hash ring, the logical pointer is rewound from the maximum position in the hash space to the starting position for re-search, ensuring the closure and integrity of the hash ring.

[0073] After mapping, the binding structure formed by the time event and the periodic task object is delivered to the input queue of the selected mapping thread, and the time processing thread performs scheduling judgment and task state update operations to ensure the consistency of the event processing logic and the thread resource binding relationship.

[0074] For example, assume that there are three time processing threads T1, T2, T3, each thread is allocated three virtual thread nodes, forming nine nodes scattered on the hash ring. The periodic task object "AutoBuy" is processed by a hash function to obtain a task hash value of 2147483650, and the first node greater than this value is found in the clockwise direction from the hash ring, which is located at node V8, which corresponds to thread T2. Then the bound time event and periodic task object are pushed into the event processing channel responsible by T2. This mechanism realizes the stability, balance and type perception ability of thread allocation.

[0075] S150, the task execution engine performs task analysis based on the parameters of the existing periodic tasks, performs risk control verification, and 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.

[0076] In one possible implementation, after executing a consistent hashing algorithm based on the task type field in the periodic task object, determining 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 also 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, updating the state of the periodic task object to a pending state; pushing the existing periodic tasks corresponding to the periodic task object with a pending state to the task execution engine; if it is determined that the periodic task object does not meet the current scheduling conditions, maintaining the state of the periodic task object unchanged and waiting for re-judgment in the subsequent scheduling period.

[0077] Specifically, after the time event and the periodic task object are mapped and delivered to the corresponding time processing thread, the time processing thread reads the binding structure from the receiving queue in sequence and enters the scheduling judgment process. First, the thread extracts the timestamp field from the time event. This field is the current second-level time, which is used to indicate the time point corresponding to this round of scheduling cycle; then, the thread extracts the scheduling period field from the periodic task object. This field is a positive integer in seconds, which is used to specify the repeated triggering 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 periodic condition judgment based on the timestamp and scheduling period fields. The commonly used algorithm is modular operation, that is:

[0078] If the judgment condition is met, it means that the time event just hits the trigger boundary of the periodic task object and meets the current scheduling conditions; 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.

[0079] If a periodic task object meets the current scheduling conditions, its status field is immediately updated to "pending." This status update is performed internally within the task object, typically using a thread-safe flag to prevent concurrent state write conflicts. The "pending" state is a transitional state for a periodic task object after scheduling and before execution is complete. This indicates that the task object has passed scheduling admission checks and is about to enter the execution process.

[0080] Subsequently, the periodic task object, with a status of "pending," is delivered to the task execution engine's task receiving channel. This process involves message passing through inter-thread queues. The task execution engine asynchronously retrieves the periodic task object from the receiving channel and begins a series of subsequent processing steps, including parameter parsing, rule verification, path distribution, and execution result writing. This delivery mechanism decouples the event processing thread from the task execution thread, improving concurrent processing capabilities and the maintainability of the scheduling chain.

[0081] If the time processing thread determines that a periodic task object does not meet the current scheduling conditions—that is, the current timestamp is not on the boundary of its scheduling period—it does not perform any changes to the task object, leaving its status field unchanged and retaining it in the thread-local task status table or buffer until the next time event arrives to trigger the judgment again. This mechanism ensures that the task object's scheduling behavior strictly adheres to the period configuration and prevents false triggering due to non-periodic time events, thereby enhancing the stability and predictability of the scheduling mechanism.

[0082] For example, the scheduling period field of a 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 result is:

[0083] If the scheduling trigger condition is met, the periodic task object's status is updated to "pending" and 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 mod 300 = 60 ≠ 0, the scheduling condition is not met. The task will remain in its original state and await a subsequent trigger. This mechanism ensures that task scheduling strictly adheres to the configured periodicity and avoids false triggering.

[0084] In one possible implementation, the task execution engine performs task parsing based on the parameters of the existing periodic tasks, performs risk control verification, and 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, specifically including: determining the target task object in the periodic task object that is in a pending state; outputting the target task object to the task execution engine, extracting the parameter configuration field of the target task object, including the target target number, operation price parameter, operation quantity parameter, operation mode parameter and scheduling priority parameter; parsing the parameter configuration field into an internal execution data structure in a unified format; loading a set of rules that matches the parameter configuration field, verifying the parameter configuration field through the internal execution data structure, and verifying in turn whether the scheduling priority parameter meets the current operation requirements, Whether the target target corresponding to the target target number is in the 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, the corresponding task scheduling path is selected according to the rule set; if it is determined that the task scheduling path is a policy-driven path, the policy service interface is called and the operation instruction is generated by the policy calculation unit; 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 results, 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.

[0085] Specifically, after the task execution engine periodically receives periodic task objects in the pending state pushed by the time processing thread, it first obtains the target task object currently in the pending state from the receiving channel. The target task object refers to a periodic task object that has passed the scheduling judgment and is marked as "pending" in the task status field. It is the starting input for the task execution engine to officially enter the execution process. Filtering is performed using the task status table index or channel status filter to ensure that only task objects in the valid state are processed, avoiding reentry and repeated processing.

[0086] The task execution engine reads the parameter configuration field in the target task object structure. This field contains multiple parameter subfields, including the target ID (a unique identifier for the object to be operated on), the operation price parameter (indicating the expected operation price), the operation quantity parameter (indicating the planned number of operations to be processed), the operation mode parameter (indicating whether policy-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 business parameter foundation for subsequent unified structure parsing and verification operations.

[0087] The parameter parsing phase converts the aforementioned parameter configuration fields into a unified internal execution data structure, typically represented by a task execution context object or an intermediate state model. This internal execution data structure is a fixed-length field structure with clear type definitions, bounds checking mechanisms, and field validity identification, facilitating subsequent modules to process according to a unified interface. This structure translates raw parameters into a standard input format for execution logic, serving as a bridge for decoupling modules within the engine.

[0088] The rule set loading module dynamically loads the matching rule set based on the parameter values ​​in the internal execution data structure. The rule set is a collection of multiple verification rules, and each rule has judgment logic and exception handling strategies. Specifically, it includes: verifying whether the scheduling priority parameters meet the current resource scheduling strategy, such as whether low-priority tasks are allowed to execute during high-load periods; checking whether the target target corresponding to the target target number is within the validity period of the operation, such as whether it is within the supported time window; verifying whether the operation price parameter is within the upper and lower floating boundaries, which are dynamically defined by business rules; and verifying whether the operation quantity parameter exceeds the maximum allowable operation threshold for a single task to prevent risk exposure or resource exhaustion.

[0089] If the target task object passes all validations of the aforementioned rule set, the path decision phase begins. The task scheduling path is determined by the scheduling policy module, combining the operation mode parameters and the policy switch field. If the result is a policy-driven path, the task execution engine invokes the policy service interface and sends the internal execution data structure as input to the policy calculation unit. The policy calculation unit generates an operation instruction based on the configured policy template or runtime model. This instruction is in a structured command format and contains fields such as the target, method, parameters, and time stamp.

[0090] If the result is a direct instruction path, the instruction adapter unit is invoked. This unit encapsulates standard adaptation logic for interfacing with various execution services or intermediate dispatch interfaces. The adapter 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.

[0091] The operation instruction is submitted to the target execution service, which can be a counter, strategy engine, external trading interface or simulation executor, etc., and receives the response information returned by the target execution service. The response information is a structured feedback body, including the execution status (success / failure / rejection), processing results (trading volume, transaction price, etc.), start and end timestamps (indicating the execution time), and feedback data (exceptions or processing notes).

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

[0093] For example, the operation mode parameter of a periodic task object is "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 trading interface at the best limit price within the current window". Finally, the target execution service returns "180 units traded, some remaining, status is successful". This information is persistently recorded as the task execution result and fed back to the task management engine for status synchronization.

[0094] This embodiment also discloses a periodic task processing device, referring to Figure 3 , comprising an acquisition module 301, a processing module 302 and an output module 303, the device is used to execute any of the above-mentioned periodic task processing methods, 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.

[0095] 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. The time factor is encapsulated as a time event and pushed to the event engine to trigger periodic task scheduling.

[0096] Processing module 302 is used to start multiple task processing engines, among which the event processing engine is used to pool multiple time processing threads, the timing scheduling engine is used to monitor 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.

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

[0098] The output module 303 is used for the task execution engine to perform task analysis 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 to the database.

[0099] It should be noted that the above embodiments provide devices that implement their functions using only the division of the above functional modules as examples. In actual 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 device and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0100] This embodiment also discloses an electronic device, referring to Figure 4 The electronic device may include: at least one processor 401 , at least one communication bus 402 , a user interface 403 , a network interface 404 , and at least one memory 405 .

[0101] The communication bus 402 is used to implement the connection and communication between these components.

[0102] The user interface 403 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0103] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0104] The processor 401 may include one or more processing cores. Using various interfaces and circuits, the processor 401 connects to various components within the server. It executes instructions, programs, code sets, or instruction sets stored in the memory 405, as well as accesses data stored in the memory 405, to perform various server functions and process data. Optionally, the processor 401 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 401 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and application programs. The GPU is responsible for rendering and drawing content displayed on the display screen. The modem handles wireless communications. It is understood that the modem may not be integrated into the processor 401 but implemented as a separate chip.

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

[0106] exist Figure 4 In the electronic device shown, user interface 403 is primarily used to provide an input interface for the user and to obtain user input data. Processor 401 can be used to invoke an application stored in memory 405 that includes a periodic task processing method. When executed by one or more processors 401, the electronic device executes one or more of the methods described in the above embodiments.

[0107] It should be noted that for the aforementioned method embodiments, for simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for this application.

[0108] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0109] In several embodiments provided in the present application, it should be understood that the disclosed apparatus can be implemented in other manners. For example, the division of the apparatus embodiments is merely illustrative, and the division of units can be changed according to actual needs. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed coupling or direct coupling or communication connection between units can be indirect coupling or communication connection through some intervening interface, device or unit, and can be electrical or other forms.

[0110] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one place or distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0111] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0112] If the integrated unit is realized in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium 405 and includes a number of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the methods of the embodiments. The aforementioned storage medium 405 includes: a U disk, a mobile hard disk, a magnetic disk or an optical disk, and various media that can store program codes.

[0113] The present application also discloses a computer readable storage medium, which stores instructions. When executed by one or more processors 401, the electronic device executes one or more methods as described in the above embodiments.

[0114] The above are merely exemplary embodiments of the present disclosure and are not intended to limit the scope of the present disclosure. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure are still within the scope of the present disclosure. After considering the disclosure of the specification and the truth of practice, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any variations, uses or adaptations of the present disclosure, which follow the general principles of the present disclosure and include common knowledge or customary technical means in the art that are not recorded in the present disclosure. The description and examples are to be regarded as exemplary only, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A periodic task processing method, characterized in that: The method comprises: Initialize the triggering logic for the start-of-day and end-of-day tasks by parsing the task time parameters in the preset configuration file; Initialize a 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 a time jump tolerance threshold. The time factor is encapsulated as a time event and pushed to the event engine to trigger periodic task scheduling. Start multiple task processing engines, where the event processing engine is used to pool multiple time processing threads, the timing scheduling engine is used to monitor 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; Loading existing periodic tasks from the database and injecting them into the event processing engine, performing hash distribution on time events based on task types, and updating the status of the existing periodic tasks; The task execution engine performs task analysis based on the parameters of the existing periodic tasks, performs risk control verification, and 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.

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

3. A periodic task processing method according to claim 1, characterized in that: The time fault tolerance algorithm is executed based on the time jump tolerance threshold, and the time factor is encapsulated as a time event and pushed to the event engine, specifically including: Get the reference timestamp of the last successful task triggering, and call the operating system time interface to get the current timestamp; Calculating a 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, encapsulating the current timestamp as the time event and pushing it to the event engine, and updating the reference timestamp 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, the time factor of each missing time point is reissued based on the time difference, and each of the time factors is respectively encapsulated as the 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 the time event and pushed to the event engine together, 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.

4. A 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 performing hash distribution on time events based on task types, specifically includes: The task management engine connects to the database and retrieves the periodic task records that are currently active based on preset query conditions; Converting each of the periodic task records into a standardized periodic task object, wherein the periodic task object includes a task identifier, a task type, a scheduling period, a status field, and a parameter configuration field; Injecting the periodic task objects into the event processing engine one by one, obtaining corresponding time events by the time processing thread, and binding 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 a mapping thread after the time event is bound to the periodic task object, and the mapping thread is distributed to a corresponding time processing thread.

5. A periodic task processing method according to claim 4, characterized in that: After executing the consistent hashing algorithm based on the task type field in the periodic task object, determining 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 condition, updating the state of the periodic task object to a pending state; Pushing the existing periodic tasks corresponding to the periodic task objects in the pending state to the task execution engine; If it is determined that the periodic task object does not meet the current scheduling condition, the state of the periodic task object is maintained unchanged and is determined again in a subsequent scheduling period.

6. A periodic task processing method according to claim 4, characterized in that: The performing of 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: Constructing a hash ring, defining the hash space as a preset value range, and generating a unique thread identifier for each of the time processing threads; Performing hash calculation on each of the thread identifiers to obtain multiple thread hash values; Registering each of the thread hash values ​​as a virtual thread node on the hash ring, wherein each of the time processing threads may correspond to one or more virtual thread nodes; For each of the periodic task objects, extract the task type field as a keyword, and perform hash calculation on the keyword to obtain a corresponding task hash value; In the hash ring, starting from the task hash value, searching for a target virtual node of the nearest thread virtual node among the multiple virtual thread nodes in a clockwise direction; Determine that the time processing thread corresponding to the target virtual node is a mapping thread after the time event is bound to the periodic task object; If it is determined that the task hash value is greater than the hash values ​​of all the virtual thread nodes in the hash ring, then loop back to the starting position of the hash ring and continue searching until the mapping thread is determined; The time event is bound to the periodic task object and then pushed to the mapping thread for the time processing thread to perform scheduling judgment and status update operations.

7. A periodic task processing method according to claim 5, characterized in that: The task execution engine performs task parsing based on the parameters of the existing periodic tasks, 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, specifically including: Determining a target task object in the waiting-to-be-executed 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; Parsing the parameter configuration fields into an internal execution data structure in a unified format; Loading a rule set that matches the parameter configuration field, verifying the parameter configuration field through the internal execution data structure, and sequentially verifying whether the scheduling priority parameter meets the current operation requirements, whether the target corresponding to the target number 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 a corresponding task scheduling path is selected according to the rule set; If it is determined that the task scheduling path is a policy-driven path, the policy service interface is called and the policy calculation unit generates an operation instruction; If the task scheduling path is a direct instruction type path, the operation instruction is sent through the instruction adaptation unit to the task intermediate dispatch interface; Submitting the operation instruction to the target execution service and receiving response information returned by the target execution service, wherein the response information includes execution status, processing results, start and end timestamps and feedback data; The response information is written into the database as the execution result, and the writing operation adopts atomic transaction control.

8. A periodic task processing device, characterized in that: The device is used to execute a periodic task processing method according to any one of claims 1 to 7, and the device comprises 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 driving engine, wherein the timer generates a time factor every second, executes a time fault tolerance algorithm based on a time jump tolerance threshold, encapsulates the time factor into a time event and pushes it to the event engine to trigger 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 timing scheduling engine is used to monitor 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 the existing periodic tasks from the database and inject them into the event processing engine, perform hash distribution on the time events based on the task type, and update the status of the existing periodic tasks; The output module (303) is used for the task execution engine to perform task analysis based on the parameters of the existing periodic tasks, perform risk control verification, and 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.

9. An electronic device, characterized in that: The electronic device comprises a processor (401), a communication bus (402), a user interface (403), a network interface (404) and a memory (405), wherein 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 connection and communication between components in the electronic device, and the processor (401) is used to execute the instructions stored in the memory (405) so that the electronic device executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 7 is executed.

Images