Lightweight monomer high-concurrency scheduling method and system

Abstract

The invention provides a lightweight monomer high-concurrency scheduling method and system, and relates to the technical field of high-concurrency task scheduling, and the method comprises the steps: pre-reading task configuration information when a program is started, comparing the current system time with the next triggering time of a task, adding a non-overtime task into a time graduator based on a memory to align the next triggering moment, and completing the task scheduling. The expiration time of the trigger is calculated for time compensation; when a triggering moment arrives, querying an execution state identifier of the task in the memory database, if the task is in a blocked state, adjusting a triggering strategy, and if the task is not blocked, allocating the task to a fast thread pool or a slow thread pool for execution according to historical execution time consumption of the task; and recording a task triggering timestamp, an execution state and next triggering time by utilizing the memory database, and immediately refreshing the next triggering time after the task is triggered. The method has the beneficial effects that task triggering with millisecond-level precision and concurrent processing capability of over 1500 are realized, and the technical problems of task blockage and insufficient time precision in a single environment are solved.

Description

Technical Field

[0001] This invention relates to the field of high-concurrency task scheduling technology, and more specifically, to a lightweight, single-unit high-concurrency scheduling method and system. Background Technology

[0002] With the rapid development of internet services, the number of scheduled tasks that monolithic applications need to handle is growing exponentially. Scenarios such as financial transactions, real-time monitoring, and precise control require millisecond-level precision in task triggering. Existing technologies typically employ a single global thread pool combined with system clock polling to trigger tasks. All tasks, regardless of execution time, enter the same waiting queue, or are triggered simply by comparing timestamps. This approach is highly susceptible to delays in task triggering when faced with thousands of concurrent tasks due to I / O blocking, thread contention, and clock drift. In severe cases, it can even lead to task backlog and system crashes.

[0003] To alleviate the above problems, existing technologies often achieve horizontal scaling by increasing the size of the thread pool without limit, deploying distributed scheduling clusters, or introducing heavyweight message middleware. However, these methods not only significantly increase system resource consumption and operational complexity, but also fail to resolve the fundamental contradiction between clock precision loss and task execution blocking in single-machine scenarios, making it difficult to meet the dual requirements of lightweight deployment and high-precision triggering. Summary of the Invention

[0004] The purpose of this invention is to provide a lightweight, single-unit, high-concurrency scheduling method and system to improve the aforementioned problems. To achieve this objective, the technical solution adopted by this invention is as follows: Firstly, this application provides a lightweight, single-mono high-concurrency scheduling method, comprising the following steps: When the program starts, it reads the task configuration information in advance, compares the current system time with the next trigger time of the task, adds tasks that have not timed out to the memory-based time scale to align with the next trigger time, and calculates the trigger expiration time for time compensation. When the trigger time arrives, query the execution status identifier of the task in the memory database. If it is in a blocked state, adjust the triggering strategy. If it is not blocked, allocate the task to the fast thread pool or slow thread pool for execution based on the historical execution time of the task. The system uses an in-memory database to record the task trigger timestamp, execution status, and next trigger time, and refreshes the next execution time immediately after the task is triggered.

[0005] Preferably, the step of allocating tasks to the fast thread pool or the slow thread pool for execution based on the historical execution time of the tasks includes: When the historical average execution time of a task is lower than a preset threshold, it is assigned to the fast thread pool; when it is higher than the preset threshold, it is assigned to the slow thread pool. The fast thread pool is configured with fewer core threads than the slow thread pool. The preset threshold is dynamically adjusted based on the sliding average of the historical execution time of the task.

[0006] Preferably, the step of pre-reading task configuration information when the program starts includes: loading the task identifier, triggering rules, and historical average execution time into memory for cache warm-up, and calibrating the system time based on the clock synchronization service to ensure millisecond-level alignment accuracy.

[0007] Preferably, the calculation of the expiration time of the trigger for time compensation includes: calculating the deviation between the current system time and the theoretical trigger time of the task; when the deviation is within the range of a preset compensation threshold, calibrating the next trigger time through a compensation algorithm; and when the deviation exceeds the compensation threshold, marking the task as a delayed state and triggering compensation execution.

[0008] Preferably, the step of querying the execution status identifier of the task in the memory database and adjusting the triggering strategy if it is in a blocked state includes: If the execution status is marked as "in execution", it is determined to be in a blocked state, and the sliding window avoidance strategy is triggered to postpone the current trigger time to the next time window; if the execution status is marked as "waiting", it is updated to "in execution" and allowed to enter the thread pool for execution.

[0009] Preferably, the step of using an in-memory database to record the task trigger timestamp, execution status, and next trigger time includes: A transaction mechanism is adopted to ensure the atomicity of task trigger timestamp and status update operations, and a flushing strategy is set to periodically flush task execution logs asynchronously to persistent storage media, while keeping the data at the trigger time only in the memory layer.

[0010] Preferably, the step of adjusting the triggering strategy if the system is in a blocked state further includes: If a task is detected to be blocked after multiple consecutive triggers, the task will be automatically promoted to the slow thread pool priority. When the number of tasks accumulated in a single thread pool exceeds the warning threshold, the maximum number of threads in the corresponding thread pool is dynamically expanded and the task distribution rebalancing mechanism is triggered.

[0011] Preferably, the step of adding non-timeout tasks to a memory-based time scale to align with the next trigger time includes: the time scale is implemented using a hierarchical time wheel algorithm or a delayed queue; the fast thread pool and slow thread pool are configured with a default core thread count of 5 and a maximum thread count of 20, supporting a task concurrency of more than 1500 in a non-expansion state.

[0012] Preferably, a real-time web interface is provided to return the trigger time, waiting time, execution status, next scheduling time, and thread pool load metrics of all current tasks, and the timeline sequence of task execution is refreshed and displayed every second through a long connection or polling mechanism.

[0013] Secondly, this application also provides a lightweight, monolithic, high-concurrency scheduling system, comprising: The pre-read processing module is used to pre-read task configuration information when the program starts and compare the current system time with the next trigger time of the task; The time alignment engine is used to add tasks that have not timed out to a memory-based time scale to align them with the next trigger time and to calculate the trigger expiration time for time compensation. The dual-thread pool scheduler queries the execution status flag of the task in the memory database when the trigger time arrives. If it is in a blocked state, the triggering strategy is adjusted. If it is not blocked, the task is allocated to the fast thread pool or the slow thread pool for execution based on the historical execution time of the task. The in-memory database management layer records the task trigger timestamp, execution status, and next trigger time, and refreshes the next execution time immediately after the task is triggered.

[0014] Thirdly, this application also provides a lightweight, single-unit, high-concurrency scheduling device, comprising: Memory, used to store computer programs; A processor, used to implement the lightweight monolithic high-concurrency scheduling method when executing the computer program.

[0015] Fourthly, this application also provides a readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described lightweight single-unit high-concurrency scheduling method.

[0016] The beneficial effects of this invention are as follows: This invention improves traditional scheduling algorithms by adding task information to an in-memory database. It utilizes the high-speed read and write capabilities of this database to obtain the timestamp of task execution and refresh the next execution time. It also incorporates task timeout triggering and task refresh strategies to prevent abnormal situations such as task blocking and crashes in single-task multitasking scenarios. It is applicable to most scheduling scenarios with extremely high requirements for task triggering time.

[0017] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the lightweight single-unit high-concurrency scheduling method described in this embodiment of the invention; Figure 2 This is a schematic diagram of the lightweight single-unit high-concurrency scheduling system structure described in an embodiment of the present invention; Figure 3 This is a schematic diagram of the lightweight single-unit high-concurrency scheduling device structure described in an embodiment of the present invention.

[0020] In the diagram: 701, pre-read processing module; 702, time alignment engine; 703, dual-thread pool scheduler; 704, memory database management layer; 800, lightweight monolithic high-concurrency scheduling device; 801, processor; 802, memory; 803, multimedia component; 804, I / O interface; 805, communication component. Detailed Implementation

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

[0022] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] Example 1: This embodiment provides a lightweight, single-unit, high-concurrency scheduling method.

[0024] See Figure 1The figure shows the steps involved in this method: When the program starts, it reads the task configuration information in advance, compares the current system time with the next trigger time of the task, adds tasks that have not timed out to the memory-based time scale to align with the next trigger time, and calculates the trigger expiration time for time compensation. When the trigger time arrives, query the execution status identifier of the task in the memory database. If it is in a blocked state, adjust the triggering strategy. If it is not blocked, allocate the task to the fast thread pool or slow thread pool for execution based on the historical execution time of the task. The system uses an in-memory database to record the task trigger timestamp, execution status, and next trigger time, and refreshes the next execution time immediately after the task is triggered.

[0025] In some alternative implementations, the purpose of this algorithm is to incorporate pre-read time, modify thread scheduling in traditional scheduling algorithms, move tasks with different time consumption into corresponding thread pools, and leverage the fast read / write speed of in-memory databases to record trigger times, thereby improving the accuracy of task triggering. This algorithm is suitable for scheduling scenarios with extremely high requirements for task triggering timing.

[0026] Specifically, this embodiment does not simply read the configuration file, but instead constructs a full pre-read and spatiotemporal pre-compensation mechanism. During system startup, by implementing the application launcher's initialization interface, it scans the relational database (storing historical policy configurations) and local configuration files in parallel, encapsulating task metadata into task metadata objects. In this process, the system introduces a time pre-compensation algorithm: during loading, it obtains nanosecond-level hardware timestamps through system calls, combines this with historical garbage collection statistics from the Java Virtual Machine (obtained through the management interface to estimate past pause times), and estimates the potential latency introduced by the system from pre-reading to the first trigger. Based on this, the system corrects the theoretical trigger time, advancing the pre-read trigger time by a compensation amount, ensuring that even under high load, the time when the task is added to the memory timescale has been reverse-corrected, thereby offsetting system jitter during startup.

[0027] Meanwhile, when comparing the current system time with the next task trigger time, the system doesn't simply perform a numerical comparison, but instead employs a clock drift-aware comparison algorithm. Since the Java Virtual Machine's system clock can be affected by fluctuations in the operating system's time synchronization service (Network Time Protocol), the system records the initial offset between the monotonic clock (a high-resolution time counter) and the wall clock (system time) during the pre-read phase. In subsequent time comparisons, the system calculates the time interval based on the monotonic clock and uses the wall clock as an anchor point to determine the absolute time, thus avoiding false or missed triggers of batch tasks due to time synchronization fluctuations. After this preprocessing, when tasks that haven't timed out are added to the memory-based time scale, their internal trigger times are already precisely aligned to the millisecond level, eliminating the need for runtime calculations and significantly reducing computational overhead on the scheduling path.

[0028] This step eliminates the impact of startup delay and system time jump on the accuracy of the first trigger by using spatiotemporal pre-compensation and dual clock system comparison. This allows the task to have millisecond-level time accuracy when it is first added to the scheduler, avoiding the large-scale initial delay caused by resource contention during the startup phase in traditional solutions.

[0029] This embodiment does not use Java's native timer scheduler, but instead implements a three-level hierarchical time wheel structure. The first level is a millisecond-level time wheel (designed with 512 slots, each slot representing 1 millisecond) for short-latency tasks with a delay of less than 300 milliseconds; the second level is a second-level time wheel (60 slots) for second-level delay tasks; and the third level is a graded time wheel (60 slots) for long-term tasks with a delay of more than a minute. Tasks select the appropriate level based on their calculated delay, and constant-time-complexity fast positioning is achieved through bitwise operations (the slot index is equal to the bitwise AND operation of the delay time and the wheel size). When a task expires in the millisecond time wheel, the system will compare the current system time with the theoretical trigger time again. If the current system time is found to be behind by more than a preset threshold (such as 2 milliseconds), a gradual compensation strategy will be triggered: instead of immediately catching up in full (which would cause a time jump), the deviation value will be calculated and the compensation amount will be evenly distributed over several subsequent cycles to make the system time smoothly catch up to the theoretical timeline, avoiding spikes or discontinuities in backtesting data due to time jumps.

[0030] By using a layered time wheel and progressive time compensation, this step reduces the lookup complexity at the task trigger moment to constant level and achieves smooth compensation when there is system latency, ensuring that millisecond-level triggering accuracy can still be maintained under continuous high load, eliminating the linear time overhead caused by traditional single-level queue traversal lookup.

[0031] When the trigger time arrives, the system executes the operation described in claim 1, which queries the task execution status identifier in the in-memory database. This embodiment designs a task status table in the in-memory database, containing fields such as task number (primary key), status code, version number, and last heartbeat time. The system utilizes the atomic update operation of the database to implement an optimistic locking state machine: before triggering, a conditional update statement is executed; only when the status is "waiting" is it updated to "executing" and the version number is incremented. If the returned number of affected rows is 1, execution rights are obtained; otherwise, it is considered blocked. This in-memory database-based detection mechanism, compared to traditional local memory locks (such as reentrant locks), has better cross-thread visibility and deadlock immunity.

[0032] If a blocking state is detected, the system triggers a sliding window avoidance strategy. This strategy does not simply discard the trigger or blindly retry, but first calculates the conflict density within the current time window (by statistically analyzing the deviation distribution between the actual execution time and the theoretical execution time of each task within the current 1-second time slice) to determine if there is a systemic resource bottleneck. If it is an intermittent blocking (a single task times out), an exponential backoff algorithm is used to postpone the trigger time to the next low-load window (e.g., postponed sequentially by 50 milliseconds, 100 milliseconds, 200 milliseconds up to the upper limit of 2 seconds), and at the same time, a "high conflict" tag is marked in the metadata of the task; if it is a persistent blocking (blocking after 3 consecutive triggers), the strategy adjustment described in claim 7 is triggered, automatically promoting the task to the head of the slow thread pool priority queue to ensure that it obtains sufficient execution resources.

[0033] In other words, by using an optimistic locking state machine and sliding window avoidance, this step achieves precise task anti-reentrancy control without using heavyweight distributed locks, and avoids system jitter through adaptive backoff, thereby improving the system's stability under extreme loads.

[0034] Specifically, regarding the dual-thread pool allocation mechanism, this embodiment implements dynamic hierarchical routing based on exponentially weighted moving averages. The system maintains an independent execution time statistics sequence for each task, calculating a smoothed expected value using a weighted moving average formula (current observation weighted at 20% to 30%, historical average weighted at 70% to 80%, with weights adaptively adjusted based on system response speed). Unlike fixed threshold determination, this system introduces a dual-buffer hysteresis mechanism: setting an upward threshold (e.g., 50 milliseconds) and a downward threshold (e.g., 30 milliseconds). A task is only considered for migration to the slow thread pool when its average execution time continuously rises from below the downward threshold and exceeds the upward threshold; conversely, it is only migrated back to the fast thread pool when its average execution time falls from above the upward threshold to below the downward threshold. This threshold design with memory prevents frequent migrations (ping-pong effect) of tasks at the dual-pool boundary due to execution time fluctuations, reducing unnecessary thread context switching overhead.

[0035] The fast thread pool is configured with 3 core threads and a maximum of 5 threads. Its work queue uses a linked list transfer queue with a capacity of 100 (offering lower enqueue latency and higher throughput compared to traditional blocking queues). The slow thread pool is configured with 7 core threads and a maximum of 15 threads. Its queue capacity is 500, and it enables a caller rejection policy to ensure that the main scheduler thread can maintain its scheduling heartbeat under extreme loads and will not be paralyzed due to thread pool saturation. Both pools use named thread factories, with task type identifiers embedded in the thread names for easy visualization and differentiation using runtime monitoring tools (such as Java management extension interfaces).

[0036] Furthermore, this step physically isolates long and short tasks through a dynamic hysteresis threshold, preventing long tasks from blocking the execution channel of short tasks. This allows high-frequency short tasks (such as market snapshot processing) to respond in milliseconds, while low-frequency long tasks (such as batch report generation) do not consume system resources, thus achieving a hybrid deployment of heterogeneous task loads.

[0037] Regarding the in-memory database recording mechanism, this embodiment adopts a hybrid mode of write-ahead logging and asynchronous flushing. The task trigger timestamp and the next execution time are stored in the in-memory table of the in-memory database, leveraging its multi-version concurrency control feature to ensure lock-free parallel read and write operations. The task execution log (such as trigger time, actual execution duration, and exception stack trace) is cached through a high-performance circular buffer (designed to have 65,536 slots, i.e., 2 to the power of 16, for easy bitwise indexing). A separate daemon thread asynchronously flushes the logs to persistent storage (such as a relational database on a solid-state drive) every 5 seconds or when the buffer is 80% full. This design ensures that the critical path (hot path) of task triggering only operates in memory, with latency controllable to the microsecond level. At the same time, asynchronous persistence ensures fault recovery capabilities and prevents disk I / O blocking every time a task is triggered.

[0038] Specifically, this embodiment is applied to an edge computing gateway device in a smart manufacturing scenario. The device uses an embedded processor (dual-core architecture, 2 gigabytes of memory) and needs to simultaneously schedule two distinct tasks: high-frequency acquisition of device status (short task) and batch firmware upgrade (long task) under conditions of no external network connection (offline environment). It also requires real-time viewing of the issuance status of production line equipment control commands through a local web interface.

[0039] For resource-constrained environments (corresponding to the lightweight requirements of claim 8), this embodiment optimizes the time scaler by employing a hybrid architecture combining a single-level time wheel and a delayed queue. Due to the low concurrency requirement (approximately 500 tasks), a native Java delayed queue (implemented based on a priority queue) replaces the complex time wheel, achieving nanosecond-level precision in triggering and sorting through a custom delayed element interface. To address the limited memory constraints of embedded devices, task objects utilize object pooling technology, using an object pool framework to manage task execution unit instances and avoid pauses caused by frequent object creation and garbage collection. The thread pool configuration is strictly limited to 2 core threads and a maximum of 4 threads (corresponding to the hyper-threading capability of a physical dual-core processor), with a fast queue capacity of 50 and a slow queue capacity of 100, ensuring that physical memory usage does not exceed 400 megabytes.

[0040] During the pre-reading of task information, considering that edge devices may operate offline for extended periods, the system, in addition to loading the persistent configuration of the local relational database upon startup, also implements a configuration integrity verification and self-repair mechanism. The system uses a cyclic redundancy check (CRC) code to detect whether the configuration file is corrupted due to an abnormal power outage; if corruption is detected, it automatically restores it from the backup area in read-only memory. For clock synchronization, since a network time protocol server cannot be relied upon (production environments may be physically isolated), the system uses a fusion calibration of a local real-time clock chip and a software clock: it reads the hardware clock chip to obtain the reference time, calculates the high-precision relative time using the timestamp counter register of the central processing unit, and fits the clock drift rate (due to the crystal oscillator frequency changing with temperature) using a linear regression compensation algorithm. The system clock is continuously corrected during device operation to ensure that the cumulative error does not exceed 10 milliseconds within 72 hours, meeting the accuracy requirements of industrial control.

[0041] This step, through hardware clock fusion and configuration self-healing, enables the system to maintain time accuracy and configuration consistency even in industrial environments with no network and prone to power outages, breaking through the limitations of traditional scheduling systems that rely on stable networks and highly available storage.

[0042] Specifically, the dynamic strategy adjustment manifests as adaptive load balancing and a task stealing mechanism in edge scenarios. The system monitors the thread pool queue depth and task blocking rate in real time (by counting the number of blocking events using a concurrent hash table). When the slow thread pool (handling long tasks for firmware upgrades) queue exceeds 80% capacity for three consecutive cycles, a cross-pool task stealing mechanism is triggered: idle threads in the fast thread pool (monitored by the active thread count) can temporarily take over the head task in the slow task queue, and return to the original pool after execution. This dynamic load balancing avoids resource idleness caused by traditional fixed partitioning. For continuously blocked tasks (such as firmware upgrades that time out multiple times due to the target device being offline), the system automatically marks them as "cold tasks" and reduces their virtual slot priority in the time wheel (by adjusting their sorting weight in the queue), ensuring that the real-time channel for emergency control commands (such as emergency stop signals) remains open.

[0043] In other words, by stealing tasks and separating hot and cold tasks, this step achieves elastic resource scheduling in a resource-constrained single-machine environment, avoiding channel congestion caused by the failure of individual long tasks and ensuring the real-time performance of critical tasks.

[0044] At the memory data management level, this embodiment uses a local high-performance cache instead of a complete in-memory database (because edge devices do not need to support complex queries). The cache is configured with a maximum of 1000 entries, and the expiration policy is to expire 1 hour after writing. Utilizing the cache's window-based, micro-least recently used eviction policy, historical task records that have not been triggered for a long time are automatically evicted when memory is insufficient, ensuring the stability of the gateway under high load. Task status updates adopt a stamped locking mechanism: during reading, an optimistic read lock is acquired and the stamp is verified; if no change has been made, execution proceeds. During writing, a write lock is upgraded to ensure the consistency of the trigger time, status, and next execution time triple. An incremental checkpoint is triggered every 30 seconds via a timer executor, serializing the changed data to a raw partition in flash memory (bypassing the file system to reduce write overhead and improve power failure safety), achieving lightweight persistence.

[0045] It should be noted that this step achieves high-concurrency state management with a memory footprint of only a few hundred KB through cache eviction and optimistic locking, and ensures extreme reliability in industrial environments through raw partition writing, thus solving the problem of traditional databases being too cumbersome on embedded devices.

[0046] Specifically, this embodiment uses reactive streaming technology to implement the monitoring interface. The backend pushes task status changes via a server-side push event protocol, while the frontend uses a charting library to draw a real-time timeline Gantt chart. To accommodate the limited bandwidth of edge devices, data serialization uses a binary message protocol instead of the text-based JSON format, reducing transmission volume by approximately 60%. The monitoring interface refreshes every second, displaying the deviation curve between the actual and theoretical trigger times of each task, a heatmap of active threads in the current thread pool, and hit rate statistics from the memory database. This allows factory maintenance personnel to visually see the precise timing of equipment control commands on a local webpage.

[0047] This step, through binary protocol and push mechanism, enables real-time monitoring in low-bandwidth industrial network environments, allowing maintenance personnel to track task execution trajectories in milliseconds, thus meeting the needs of industrial sites for visualized maintenance.

[0048] In summary, this invention, by pre-reading task configurations at program startup and aligning trigger times based on a memory time scaler, combined with a dual-thread pool separation mechanism and a high-speed read / write architecture for a memory database, achieves millisecond-level precision task triggering and a concurrent processing capacity of over 1500 threads under lightweight resource consumption conditions with only dual-thread pools configured (default core threads 5, maximum threads 20). This effectively solves the technical problems of task blocking, insufficient time precision, and excessive resource consumption in a monolithic environment.

[0049] Example 2: like Figure 2 As shown, this embodiment provides a lightweight, single-unit, high-concurrency scheduling system. See [link to documentation]. Figure 2 The system includes: The pre-read processing module 701 is used to pre-read task configuration information when the program starts and compare the current system time with the next trigger time of the task. The time alignment engine 702 is used to add tasks that have not timed out to a memory-based time scale to align with the next trigger time and calculate the trigger expiration time for time compensation. The dual-thread pool scheduler 703 is used to query the execution status identifier of the task in the memory database when the trigger time arrives. If it is in a blocked state, the triggering strategy is adjusted. If it is not blocked, the task is allocated to the fast thread pool or the slow thread pool for execution based on the historical execution time of the task. The in-memory database management layer 704 is used to record the task trigger timestamp, execution status, and next trigger time, and refreshes the next execution time immediately after the task is triggered.

[0050] It should be noted that the specific methods by which each module performs operations in the system described in the above embodiments have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0051] Example 3: Corresponding to the above method embodiments, this embodiment also provides a lightweight single-unit high-concurrency scheduling device. The lightweight single-unit high-concurrency scheduling device described below and the lightweight single-unit high-concurrency scheduling method described above can be referred to in correspondence.

[0052] Figure 3 This is a block diagram illustrating a lightweight, monolithic, high-concurrency scheduling device 800 according to an exemplary embodiment. Figure 3 As shown, the lightweight monolithic high-concurrency scheduling device 800 includes a processor 801 and a memory 802. The lightweight monolithic high-concurrency scheduling device 800 also includes one or more of a multimedia component 803, an I / O interface 804, and a communication component 805.

[0053] The processor 801 controls the overall operation of the lightweight monolithic high-concurrency scheduling device 800 to complete all or part of the steps in the aforementioned lightweight monolithic high-concurrency scheduling method. The memory 802 stores various types of data to support the operation of the lightweight monolithic high-concurrency scheduling device 800. This data may include, for example, instructions for any application or method operating on the lightweight monolithic high-concurrency scheduling device 800, as well as application-related data such as contact data, sent and received messages, images, audio, video, etc. The memory 802 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The multimedia component 803 may include a screen and an audio component. The screen may be, for example, a touchscreen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in the memory 802 or transmitted via the communication component 805. The audio component also includes at least one speaker for outputting audio signals. I / O interface 804 provides an interface between processor 801 and other interface modules, such as keyboards, mice, or buttons. These buttons can be virtual or physical. Communication component 805 is used for wired or wireless communication between this lightweight, single-unit, high-concurrency scheduling device 800 and other devices. Wireless communication includes, for example, Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or one or more combinations thereof. Therefore, the corresponding communication component 805 may include a Wi-Fi module, a Bluetooth module, or an NFC module.

[0054] In an exemplary embodiment, the lightweight single-unit high-concurrency scheduling device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the lightweight single-unit high-concurrency scheduling method described above.

[0055] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, which, when executed by a processor, implement the steps of the lightweight single-unit high-concurrency scheduling method described above. For example, the computer-readable storage medium may be the memory 802 including program instructions described above, which may be executed by the processor 801 of the lightweight single-unit high-concurrency scheduling device 800 to complete the lightweight single-unit high-concurrency scheduling method described above.

[0056] Example 4: Corresponding to the above method embodiments, this embodiment also provides a readable storage medium. The readable storage medium described below can be referred to in conjunction with the lightweight monolithic high-concurrency scheduling method described above.

[0057] A computer program is stored on a readable storage medium, and when the computer program is executed by a processor, it implements the steps of the lightweight monolithic high-concurrency scheduling method described in the above method embodiments.

[0058] Specifically, the readable storage medium can be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0059] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0060] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A lightweight, single-unit, high-concurrency scheduling method, characterized in that, Includes the following steps: When the program starts, it reads the task configuration information in advance, compares the current system time with the next trigger time of the task, adds tasks that have not timed out to the memory-based time scale to align with the next trigger time, and calculates the trigger expiration time for time compensation. When the trigger time arrives, query the execution status identifier of the task in the memory database. If it is in a blocked state, adjust the triggering strategy. If it is not blocked, allocate the task to the fast thread pool or slow thread pool for execution based on the historical execution time of the task. The system uses an in-memory database to record the task trigger timestamp, execution status, and next trigger time, and refreshes the next execution time immediately after the task is triggered.

2. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The process of allocating tasks to the fast thread pool or slow thread pool based on historical task execution time includes: When the historical average execution time of a task is lower than a preset threshold, it is assigned to the fast thread pool; when it is higher than the preset threshold, it is assigned to the slow thread pool. The fast thread pool is configured with fewer core threads than the slow thread pool. The preset threshold is dynamically adjusted based on the sliding average of the historical execution time of the task.

3. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The step of pre-reading task configuration information when the program starts includes: loading the task identifier, trigger rules, and historical average execution time into memory for cache warm-up, and calibrating the system time based on the clock synchronization service to ensure millisecond-level alignment accuracy.

4. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The calculation of the expiration time of the trigger for time compensation includes: calculating the deviation between the current system time and the theoretical trigger time of the task; when the deviation is within the range of a preset compensation threshold, calibrating the next trigger time through a compensation algorithm; when the deviation exceeds the compensation threshold, marking the task as a delayed state and triggering compensation execution.

5. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The process involves querying the execution status identifier of the task in the memory database. If the task is in a blocked state, the triggering strategy is adjusted, including: If the execution status is marked as "Executing", it is determined to be in a blocked state, and the sliding window avoidance strategy is triggered to postpone the current trigger time to the next time window; if the execution status is marked as "Waiting", it is updated to "Executing" and allowed to enter the thread pool for execution.

6. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The method of using an in-memory database to record task trigger timestamps, execution status, and next trigger time includes: A transaction mechanism is adopted to ensure the atomicity of task trigger timestamp and status update operations, and a flushing strategy is set to periodically flush task execution logs asynchronously to persistent storage media, while keeping the data at the trigger time only in the memory layer.

7. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The step of adjusting the triggering strategy if the system is in a blocked state also includes: If a task is detected to be blocked after multiple consecutive triggers, the task will be automatically promoted to the slow thread pool priority. When the number of tasks accumulated in a single thread pool exceeds the warning threshold, the maximum number of threads in the corresponding thread pool is dynamically expanded and the task distribution rebalancing mechanism is triggered.

8. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, The step of adding non-timeout tasks to a memory-based timer to align with the next trigger time includes: the timer is implemented using a hierarchical time wheel algorithm or a delayed queue; the fast thread pool and slow thread pool are configured with a default core thread count of 5 and a maximum thread count of 20, supporting a task concurrency of more than 1500 in a non-expansion state.

9. The lightweight single-unit high-concurrency scheduling method according to claim 1, characterized in that, Also includes: It provides a real-time web interface to return the trigger time, waiting time, execution status, next scheduling time, and thread pool load metrics for all current tasks. The timeline sequence of task execution is refreshed every second through a long connection or polling mechanism.

10. A lightweight, monolithic, high-concurrency scheduling system, based on the lightweight, monolithic, high-concurrency scheduling method of claim 1, characterized in that, include: The pre-read processing module is used to pre-read task configuration information when the program starts and compare the current system time with the next trigger time of the task; The time alignment engine is used to add tasks that have not timed out to a memory-based time scale to align them with the next trigger time and to calculate the trigger expiration time for time compensation. The dual-thread pool scheduler queries the execution status flag of the task in the memory database when the trigger time arrives. If it is in a blocked state, the triggering strategy is adjusted. If it is not blocked, the task is allocated to the fast thread pool or the slow thread pool for execution based on the historical execution time of the task. The in-memory database management layer records the task trigger timestamp, execution status, and next trigger time, and refreshes the next execution time immediately after the task is triggered.

Images