Stepped multi-stage timing system and method, electronic equipment and storage medium

Abstract

The invention relates to a stepped multi-stage timing method and system, electronic equipment and a storage medium, timing containers graded according to time intervals are managed through a timing engine, timers are dynamically allocated to corresponding containers according to remaining time, check is triggered in combination with inverted indexes, and when the remaining time is insufficient, the containers with smaller intervals are migrated. And utilizing the multi-core CPU to process different group pulse tasks in parallel. According to the scheme, the problems of low efficiency, slow response and poor expansibility caused by single interval scheduling of a traditional timer are solved, the effects of efficient scheduling to reduce CPU occupancy, dynamic migration to improve trigger precision, supporting self-defined hierarchy to enhance expansibility, and automatic overdue cleaning to save resources are achieved, and timing precision and resource consumption are balanced through hierarchical dynamic management.

Description

Technical Field

[0001] This application relates to the field of timing systems, and in particular to a stepped multi-level timing system, method, electronic device, and storage medium. Background Technology

[0002] With the development of computer technology, timers, as a fundamental system component, are widely used in various software systems to implement functions such as scheduled tasks, delayed execution, and periodic operations. Traditional timing systems typically employ a single-time-granularity timing method, that is, checking the status of all timers at fixed time intervals. This method has significant limitations when dealing with a large number of timers or scenarios with varying time precision requirements.

[0003] Currently, common timing system implementations mainly include two types: polling-based timers and event-driven timers. Polling-based timers determine whether to trigger by periodically checking the timer's state, such as the Timer class in Java; while event-driven timers implement timing functionality through system interrupts or callback mechanisms, such as the timerfd mechanism in Linux systems. These traditional timing systems face a trade-off between efficiency and accuracy in practical applications.

[0004] Traditional timing systems typically check all timers at a uniform time interval, failing to differentiate based on the remaining trigger time, leading to wasted system resources. For example, using the same check frequency for a timer with one hour remaining and one with one second remaining is clearly unreasonable. Secondly, existing technologies cannot adjust the management container assigned to a timer as its remaining time changes, impacting timing accuracy and system efficiency. Thirdly, existing technologies fail to implement a multi-level timing container architecture based on time granularity, making it difficult to meet the efficient management needs of large-scale timers.

[0005] Currently, no effective solution has been proposed for the problem of resource waste in timer systems in related technologies. Summary of the Invention

[0006] This application provides a stepped multi-level timing method, system, computer device, and computer-readable storage medium to at least solve the problem of resource waste in timer systems in related technologies.

[0007] In a first aspect, embodiments of this application provide a stepped multi-level timing method, implemented based on a stepped timing system. The stepped timing system includes a timer, a timing container, and a timing engine for managing the timing container and dynamically allocating the timer. The method includes:

[0008] The timing engine is initialized to obtain multiple preset time intervals with decreasing time granularity, wherein the preset time intervals are used to instruct the timing container to check the trigger status of the timer;

[0009] Based on multiple preset time intervals, multiple sets of timing containers corresponding to different timing precision requirements are created, and a reverse index is established between each timing container;

[0010] Upon receiving a new timer instance, a dynamic allocation algorithm is used to dynamically allocate the timer instance to multiple timer containers for processing in a step-down manner based on the remaining time of the timer instance and the reverse index.

[0011] In some embodiments, multiple sets of timing containers corresponding to different timing accuracy requirements are created according to multiple preset time intervals, and a reverse index is established between the timing containers, including:

[0012] Iterate through the preset time intervals, create a corresponding timer container for each preset time interval, and configure attribute parameters for each timer container;

[0013] Based on the time interval, the timing container is divided into different levels to obtain a multi-level timing container with decreasing time granularity. The larger the preset time interval, the higher the level of the timing container; the smaller the preset time interval, the lower the level of the timing container.

[0014] Sort all timing containers from largest to smallest according to a preset time interval, and create the reverse index list.

[0015] In some embodiments, the process of dynamically allocating the timer instances to multiple timer containers in a step-decreasing manner includes:

[0016] In the initial state, the corresponding first timing container is matched according to the initial remaining trigger time of the timer instance;

[0017] In the first timing container, following the dynamic changes of the remaining trigger time, the trigger status of the timer instance is checked, and the timer is migrated to a second timing container that matches the current remaining time through a dynamic migration mechanism.

[0018] In some embodiments, performing a trigger status check on the timer in any timing container includes:

[0019] Check the triggering status of the timer instance according to the preset time interval corresponding to the timer container;

[0020] If the trigger state is not triggered, determine whether the current remaining trigger time of the timer instance is less than the preset time interval of the timer container. If not, continue to check the trigger state. If yes, dynamically migrate the timer instance.

[0021] In some embodiments, the characteristic feature is that, in any timing container, dynamically migrating the timer instance includes:

[0022] Based on the reverse index, obtain multiple time containers to be migrated that have a time granularity smaller than the first time container;

[0023] Determine the candidate preset time intervals corresponding to each time container to be migrated, and obtain the current remaining time of the timer instance;

[0024] Based on the current remaining time and each candidate preset time interval, the most matching time container group to be migrated is obtained as the second time container, and the timer instance is migrated to the second time container.

[0025] In some embodiments, the method further includes:

[0026] If the trigger state is "triggered", determine whether the current trigger count of the timer instance meets the preset maximum trigger count.

[0027] If so, remove the timer instance from the timing container and delete the timer from the global hash table of the timing engine;

[0028] If not, the remaining time of the timer instance is reset to the initial remaining trigger time, and the reset timer instance is dynamically allocated to multiple timer containers in a step-decreasing manner through a dynamic allocation calculation.

[0029] In some embodiments, the method further includes:

[0030] The timing engine is used to obtain the number of available CPU cores and initialize the thread pool.

[0031] The timer containers with different time intervals are allocated to different threads in the thread pool according to their core count, and each thread synchronously drives the corresponding container to execute pulse tasks. The pulse tasks include: trigger status check, traversing the timer to trigger the expiration, updating the remaining time, and dynamic migration.

[0032] Secondly, embodiments of this application provide a stepped multi-level timing system, characterized in that the system includes: a timer, a timing container, and a timing engine for managing the timing container and dynamically allocating the timer, for performing timing tasks using the stepped multi-level timing method provided in the first aspect.

[0033] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect above.

[0034] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0035] Compared to related technologies, the beneficial effects of the step-by-step multi-level timing method provided in this application are as follows:

[0036] 1. By adopting a multi-level time container structure and managing timers hierarchically according to different time granularities, the number of invalid checks on timer status is significantly reduced, CPU utilization is lowered, and system resource utilization efficiency is improved compared with traditional timer systems;

[0037] 2. The dynamic migration strategy based on remaining time enables the timer to automatically migrate to a more suitable time granularity container as the remaining time changes, improving trigger accuracy and ensuring that the timer is processed at the most appropriate time granularity, thus reducing response latency.

[0038] 3. Supports custom time interval levels. The system can flexibly configure the time granularity according to the needs of different application scenarios, adapt to different scenario requirements, and flexibly cope with various complex scheduling scenarios, thus enhancing the system's scalability.

[0039] 4. The automatic cleanup mechanism using an expiration timer avoids memory leaks, improves long-term system stability, and saves system resources.

[0040] 5. By combining a multi-level time interval dynamic allocation algorithm, a group pulse triggering mechanism, a timer migration strategy, and an automatic expiration cleanup mechanism, efficient and flexible large-scale timer management is achieved, solving the performance bottleneck problem of traditional timer systems under high load conditions. Attached Figure Description

[0041] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0042] Figure 1 This is a flowchart of a step-by-step timing method provided according to an embodiment of this application;

[0043] Figure 2 This is a flowchart of another step-by-step multi-level timing method according to an embodiment of this application;

[0044] Figure 3 This is a structural block diagram of a stepped multi-level timing system according to an embodiment of this application;

[0045] Figure 4 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0047] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0048] This application provides a stepped multi-level timing method based on a stepped timing system. The stepped timing system includes a timer, a timing container, and a timing engine for managing the timing container and dynamically allocating the timer. Figure 1 This is a flowchart of a step-by-step timing method provided according to an embodiment of this application, such as... Figure 1 As shown, the method specifically includes the following steps:

[0049] S101, Initialize the timing engine and obtain multiple preset time intervals with decreasing time granularity. The preset time intervals are used to instruct the timing container to check the trigger status of the timer.

[0050] Specifically, upon system startup, the timing engine first performs an initialization operation, loading multiple predefined preset time intervals from the configuration file. These preset time intervals are arranged in descending order of time granularity, forming a stepped decreasing sequence of time granularity. For example, preset time intervals can be set as [1 day, 1 hour, 10 minutes, 1 minute, 10 seconds, 1 second, 100 milliseconds], and these time intervals will be used to create timing containers of different precisions later.

[0051] During initialization, the timing engine also creates a global hash table to store references to all timer instances for quick lookup and management. Simultaneously, the timing engine initializes its internal state, preparing to receive and process timer instances.

[0052] S102, Based on multiple preset time intervals, create multiple sets of timing containers corresponding to different timing precision requirements, and establish a reverse index between each timing container;

[0053] In this step, the timing engine iterates through the previously acquired list of preset time intervals and creates a corresponding timing container for each preset time interval. Each timing container is configured with specific attribute parameters, including a container identifier, a preset time interval value, and a container hierarchy.

[0054] For example, for a preset time interval [1 hour, 10 minutes, 1 minute, 10 seconds, 1 second, 100 milliseconds], the timing engine will create 6 timing containers, each corresponding to one of these 6 different time intervals. Each timing container maintains a list of timers to store the timer instances assigned to that container.

[0055] Based on the preset time interval, the timing engine divides these timing containers into different levels, forming a multi-level timing container structure with decreasing time granularity. The larger the preset time interval, the higher the corresponding timing container level; the smaller the preset time interval, the lower the corresponding timing container level.

[0056] In the example above, the timer containers corresponding to 1-hour intervals are assigned to the highest level, while the timer containers corresponding to 100-millisecond intervals are assigned to the lowest level. This hierarchical structure allows the system to allocate the timer to the most appropriate timer container for processing based on the remaining trigger time of the timer.

[0057] After creating all timing containers, the timing engine sorts them from largest to smallest according to preset time intervals, creating a reverse index list. This reverse index list is used to quickly locate the appropriate target timing container during dynamic timer migration.

[0058] S103, upon receiving a new timer instance, uses a dynamic allocation algorithm to dynamically allocate the timer instance to multiple timer containers in a step-down manner based on the remaining time and reverse index of the timer instance.

[0059] When the system receives a new timer instance, the timing engine first registers the timer instance in the global hash table, and then determines the most suitable timing container to handle the timer based on the change in the initial remaining trigger time of the timer instance through a dynamic allocation algorithm.

[0060] The core logic of the dynamic allocation algorithm in this application is: traverse the timer containers in the reverse index list, find the first timer container whose preset time interval is less than or equal to the remaining trigger time of the timer, and allocate the timer instance to that container.

[0061] For example, if a newly added timer instance has an initial remaining trigger time of 30 minutes, then in the example above, the timing engine will assign it to a timing container with a preset time interval of 10 minutes, because this is the first timing container with a preset time interval that is closest to the granularity of the remaining time of 30 minutes.

[0062] Once the allocation is complete, the timing container will periodically check the trigger status of the timer at its preset time intervals. Over time, when the remaining trigger time of the timer decreases to less than the preset time interval of the current container, the timing engine will dynamically migrate the timer to a lower-level timing container to provide more accurate timing checks.

[0063] This step-decreasing dynamic allocation mechanism ensures that the timer receives the most appropriate processing in different remaining time stages, guaranteeing timing accuracy while avoiding unnecessary resource consumption.

[0064] Specifically, in the initial state, the corresponding first timing container is matched according to the initial remaining trigger time of the timer instance;

[0065] When a new timer instance is created and added to the system, the timing engine needs to find the most suitable initial timing container for it. The timing engine first obtains the initial remaining trigger time of the timer instance, then iterates through the timing containers in the reverse index list and finds the first timing container whose preset time interval is less than the initial remaining trigger time of the timer as the first timing container.

[0066] For example, suppose there are six timers in the system with preset time intervals of [1 hour, 10 minutes, 1 minute, 10 seconds, 1 second, 100 milliseconds]. If the initial remaining trigger time of a timer is 45 minutes, the timing engine will assign it to the timer container with a preset time interval of 10 minutes, because 45 minutes is less than 1 hour and greater than 10 minutes.

[0067] If the timer's initial remaining trigger time is 8 seconds, it will be assigned to a timing container with a preset time interval of 1 second. This matching mechanism ensures that the timer is always assigned to a timing container that can properly handle its remaining time.

[0068] In the first timing container, the trigger status of the timer instance is checked in accordance with the dynamic changes of the remaining trigger time, and the timer is migrated to the second timing container that matches the current remaining time through a dynamic migration mechanism.

[0069] After a timer instance is assigned to the first timer container, that container periodically checks the trigger status of the timers at its preset time intervals. For example, a timer container with a preset time interval of 1 hour will check the trigger status of all timers in it every 1 hour.

[0070] During the inspection process, the timer container updates the remaining trigger time of the timer and determines whether the timer needs to be triggered or moved to another timer container. As time goes on, the remaining trigger time of the timer will continuously decrease. When the remaining trigger time is less than the preset time interval of the current timer container, the timer is moved to a lower-level timer container.

[0071] For example, when a timer initially assigned to a 1-hour timer container has its remaining trigger time reduced to 56 minutes, it needs to be migrated to a timer container with a preset time interval of 10 minutes. This dynamic migration mechanism ensures that the timer receives the most appropriate processing frequency in different remaining time stages, guaranteeing timing accuracy while avoiding unnecessary resource consumption.

[0072] Check the trigger status of the timer instance according to the preset time interval corresponding to the timer container;

[0073] Within any given timer container, the trigger status of the timers is checked at preset time intervals for that container. For example, a timer container with a preset time interval of 10 minutes will check the trigger status of all its timers every 10 minutes.

[0074] During the check, the timer container iterates through all timer instances, updates the remaining trigger time of each timer, and determines whether the trigger condition has been met. If the remaining trigger time of a timer decreases to zero or a negative value, it means that the timer has met the trigger condition and the corresponding trigger operation needs to be performed.

[0075] On the other hand, if the triggering state is not triggered, it is determined whether the current remaining triggering time of the timer instance is less than the preset time interval of the timer container. If not, the triggering state check continues; if so, the timer instance is dynamically migrated.

[0076] If the timer's trigger status is not triggered, the timer container will further determine whether the timer's current remaining trigger time is less than the container's preset time interval. This determination is crucial to the dynamic migration mechanism.

[0077] If the current remaining trigger time of the timer is still greater than or equal to the preset time interval of the current timer container, the timer will remain in the current container and wait for the next trigger status check.

[0078] For example, in a timer container with a preset time interval of 10 minutes, if a timer has 15 minutes of remaining trigger time, then at the next check (10 minutes later), its remaining trigger time will become 5 minutes, which is less than the container's preset time interval of 10 minutes, requiring dynamic migration.

[0079] If the current remaining trigger time of the timer is less than the preset time interval of the current timer container, the timer needs to be migrated to a lower-level timer container to obtain more precise trigger time control.

[0080] Specifically, in the migration process, multiple time containers to be migrated with a time granularity smaller than that of the first time container are obtained based on the reverse index.

[0081] When dynamic migration of timers is required, the timing engine first obtains all time containers with a time granularity smaller than the current time container based on the reverse index list, as a candidate set of time containers to be migrated.

[0082] For example, if the current timer is in a timer container with a preset time interval of 10 minutes, then the candidate set of timer containers to be migrated includes timer containers with preset time intervals of 1 minute, 10 seconds, 1 second, and 100 milliseconds.

[0083] Determine the candidate preset time intervals corresponding to each time container to be migrated, and obtain the current remaining time of the timer instance;

[0084] The timing engine retrieves the preset time interval for each container from the candidate set of timer containers to be migrated, forming a list of candidate preset time intervals. Simultaneously, the timing engine obtains the current remaining trigger time of the timer instances that need to be migrated.

[0085] For example, for the candidate set above, the list of potential preset time intervals is [1 minute, 10 seconds, 1 second, 100 milliseconds]. Assuming the timer's current remaining trigger time is 10 minutes, the timing engine needs to find the most suitable one from these potential preset time intervals.

[0086] Based on the current remaining time and each candidate preset time interval, the most matching time container group to be migrated is obtained as the second time container, and the timer instance is migrated to the second time container.

[0087] The timing engine iterates through the list of candidate preset time intervals and finds the first preset time interval that is less than the current remaining trigger time of the timer. The corresponding timing container is the best matching second timing container.

[0088] In the example above, the timer's current remaining trigger time is 10 minutes, and the list of candidate preset time intervals is [1 minute, 10 seconds, 1 second, 100 milliseconds]. Since 10 minutes is greater than all preset time intervals in the list, the timing engine will select the timing container corresponding to the largest preset time interval in the list, 1 minute, as the second timing container.

[0089] Once the second timing container is determined, the timing engine removes the timer instance from the first timing container and adds it to the second timing container. This allows the timer to perform trigger status checks according to the preset time intervals of the second timing container, resulting in more precise trigger timing control.

[0090] If the trigger status is triggered, determine whether the current trigger count of the timer instance meets the preset maximum trigger count. If yes, remove the timer instance from the timer container and delete the timer from the global hash table of the timer engine. If no, reset the remaining time of the timer instance to the initial remaining trigger time, and use a dynamic allocation algorithm to continue the tiered trigger process, dynamically allocating the reset timer instance to multiple timer containers for processing in a tiered decreasing manner.

[0091] When a timer is in the triggered state, the timing engine needs to determine whether the timer should continue operating. The timing engine first checks whether the current trigger count of the timer instance has reached the preset maximum trigger count.

[0092] If the current trigger count of a timer has reached the preset maximum trigger count, it means that the timer has completed all its scheduled triggering tasks and no longer needs to work. At this time, the timing engine will remove the timer instance from the current timing container, delete the reference to the timer from the global hash table, and release the related resources.

[0093] For example, if a timer's preset maximum number of triggers is 5, when it triggers for the 5th time, the timing engine will determine that it has reached the maximum number of triggers and remove it from the system.

[0094] If the current trigger count of the timer has not yet reached the preset maximum trigger count, it means that the timer needs to continue working. At this time, the timing engine will reset the remaining time of the timer instance to the initial remaining trigger time and increment its trigger count.

[0095] After a reset, the timing engine uses a dynamic allocation algorithm to reassign the timer to a suitable timing container based on its initial remaining trigger time. This process is the same as the dynamic allocation process when adding a new timer instance, ensuring that the timer is assigned to the most suitable timing container to continue working after each trigger.

[0096] Additionally, it should be noted that this embodiment obtains the number of available CPU cores through a timing engine and initializes the thread pool;

[0097] To fully utilize the computing power of multi-core processors and improve the system's parallel processing capabilities, the timing engine obtains the number of CPU cores currently available in the system and initializes the thread pool based on this value.

[0098] Specifically, the timing engine obtains the current number of CPU cores on the machine through the system API, and then creates a thread pool whose size matches the number of cores. For example, if the system has 8 available CPU cores, the timing engine will create a thread pool containing 8 worker threads.

[0099] After the thread pool is initialized, the timing engine will assign a specific task to each thread, allowing multiple timing containers to process in parallel and improve the overall efficiency of the system.

[0100] The timer containers with different time intervals are allocated to different threads in the thread pool according to their core count, and each thread synchronously drives the corresponding container to execute pulse tasks. The pulse tasks include: triggering state checks, traversing timers to trigger expiration, updating remaining time, and dynamic migration.

[0101] The timing engine distributes the created multiple timing containers to different threads in the thread pool according to a certain strategy. A common allocation strategy is to assign timing containers with similar time intervals to the same thread to reduce load imbalance between threads.

[0102] For example, given six time containers with preset time intervals of [1 hour, 10 minutes, 1 minute, 10 seconds, 1 second, 100 milliseconds], if the system has 3 available CPU cores, the timing engine might allocate them as follows:

[0103] Thread 1: Responsible for processing timer containers of 1 hour and 10 minutes.

[0104] Thread 2: Responsible for handling the 1-minute and 10-second timer containers.

[0105] Thread 3: Responsible for handling timers of 1 second and 100 milliseconds.

[0106] After allocation, each thread synchronously drives the timing container it is responsible for to execute the pulse task. The pulse task is the core operation of the timing container, including the following aspects:

[0107] Trigger status check: Periodically check the trigger status of all timers in the timer container according to the preset time interval.

[0108] Iterate through timers to trigger expiration events: For timers whose trigger status is "triggered", execute the corresponding triggering operation, such as calling a callback function or sending an event notification.

[0109] Update Remaining Time: Update the remaining trigger time of all timers in the container based on the passage of time.

[0110] Dynamic migration: For timers with remaining trigger time less than the current container's preset time interval, migrate them to a lower-level timer container to obtain more precise trigger time control.

[0111] It's understandable that by processing different timer containers in parallel using multiple threads, the system can handle a large number of timer instances simultaneously, improving overall processing efficiency and response speed. At the same time, because timer containers with different time intervals are assigned to different threads, the workload of each thread can remain relatively balanced.

[0112] in addition, Figure 2 This is a flowchart of another step-by-step multi-level timing method according to an embodiment of this application.

[0113] Through steps S101 to S103 above, a tiered multi-level timing method is proposed. This method manages timing containers hierarchically by time interval through a timing engine, dynamically allocating timers to corresponding containers based on remaining time. It combines reverse index trigger checks, migration to smaller interval containers when remaining time is insufficient, and parallel processing of different groups of pulse tasks using multi-core CPUs. This scheme solves the problems of low efficiency, slow response, and poor scalability caused by traditional single-interval scheduling of timers. It achieves efficient scheduling to reduce CPU usage, dynamic migration to improve trigger accuracy, support for custom levels to enhance scalability, and automatic expiration cleanup to save resources. Hierarchical dynamic management balances timing accuracy and resource consumption.

[0114] Secondly, embodiments of this application also provide a stepped multi-level timing system. Figure 3 This is a structural block diagram of a stepped multi-level timing system according to an embodiment of this application, such as... Figure 3 As shown, the system includes: a timer, a timing container, and a timing engine for managing the timing container and dynamically allocating the timer, for executing a tiered multi-level timing method and performing timing tasks.

[0115] Specifically, an example of a system performing a timing task is as follows:

[0116] S1, initialize the timing engine and obtain multiple preset time intervals with decreasing time granularity. The preset time intervals are used to instruct the timing container to check the trigger status of the timer.

[0117] Specifically, upon system startup, the timing engine first performs an initialization operation, loading multiple predefined preset time intervals from the configuration file. These preset time intervals are arranged in descending order of time granularity, forming a stepped decreasing sequence of time granularity. For example, preset time intervals can be set to [2 hours, 20 minutes, 2 minutes, 20 seconds, 2 seconds, 200 milliseconds], and these time intervals will be used to create timing containers of different precisions later.

[0118] During initialization, the timing engine also creates a global hash table to store references to all timer instances for quick lookup and management. Simultaneously, the timing engine initializes its internal state, preparing to receive and process timer instances.

[0119] S2, based on multiple preset time intervals, create multiple sets of timing containers corresponding to different timing precision requirements, and establish a reverse index between each timing container;

[0120] In this step, the timing engine iterates through the previously acquired list of preset time intervals and creates a corresponding timing container for each preset time interval. Each timing container is configured with specific attribute parameters, including a container identifier, a preset time interval value, and a container hierarchy.

[0121] For example, for a preset time interval [2 hours, 20 minutes, 2 minutes, 20 seconds, 2 seconds, 200 milliseconds], the timing engine will create 6 timing containers, each corresponding to one of these 6 different time intervals. Each timing container maintains a list of timers to store the timer instances assigned to that container.

[0122] Based on the preset time interval, the timing engine divides these timing containers into different levels, forming a multi-level timing container structure with decreasing time granularity. The larger the preset time interval, the higher the corresponding timing container level; the smaller the preset time interval, the lower the corresponding timing container level.

[0123] In the example above, the timing containers corresponding to 2-hour intervals are assigned to the highest level, while the timing containers corresponding to 200-millisecond intervals are assigned to the lowest level. This hierarchical structure allows the system to allocate the timer to the most appropriate timing container for processing based on the remaining trigger time.

[0124] After creating all timing containers, the timing engine sorts them from largest to smallest according to preset time intervals, creating a reverse index list. This reverse index list is used to quickly locate the appropriate target timing container during dynamic timer migration.

[0125] Upon receiving a new timer instance, a dynamic allocation algorithm is used to dynamically distribute the timer instance to multiple timer containers for processing in a step-down manner based on the remaining time and reverse index of the timer instance.

[0126] S3. When the system receives a new timer instance, the timing engine first registers the timer instance in the global hash table, and then determines the most suitable timing container to handle the timer based on the initial remaining trigger time of the timer instance through a dynamic allocation algorithm.

[0127] The core logic of the dynamic allocation algorithm is: traverse the timer containers in the reverse index list, find the first timer container whose preset time interval is less than or equal to the remaining trigger time of the timer, and allocate the timer instance to that container.

[0128] For example, if a newly added timer instance has an initial remaining trigger time of 60 minutes, then in the example above, the timing engine will assign it to a timing container with a preset time interval of 20 minutes.

[0129] Once the allocation is complete, the timing container will periodically check the trigger status of the timer at its preset time intervals. Over time, when the remaining trigger time of the timer decreases to less than the preset time interval of the current container, the timing engine will dynamically migrate the timer to a lower-level timing container to provide more accurate timing checks.

[0130] This step-decreasing dynamic allocation mechanism ensures that the timer receives the most appropriate processing in different remaining time stages, guaranteeing timing accuracy while avoiding unnecessary resource consumption.

[0131] Obtain the number of available CPU cores using the timing engine and initialize the thread pool;

[0132] To fully utilize the computing power of multi-core processors and improve the system's parallel processing capabilities, the timing engine obtains the number of CPU cores currently available in the system and initializes the thread pool based on this value.

[0133] Specifically, the timing engine obtains the current number of CPU cores on the machine through the system API, and then creates a thread pool whose size matches the number of cores. For example, if the system has 16 available CPU cores, the timing engine will create a thread pool containing 16 worker threads.

[0134] After the thread pool is initialized, the timing engine will assign a specific task to each thread, allowing multiple timing containers to process in parallel and improve the overall efficiency of the system.

[0135] The timer containers with different time intervals are allocated to different threads in the thread pool according to their core count, and each thread synchronously drives the corresponding container to execute pulse tasks. The pulse tasks include: triggering state checks, traversing timers to trigger expiration, updating remaining time, and dynamic migration.

[0136] The timing engine distributes the created multiple timing containers to different threads in the thread pool according to a certain strategy. A common allocation strategy is to assign timing containers with similar time intervals to the same thread to reduce load imbalance between threads.

[0137] For example, given six time containers with preset time intervals of [2 hours, 20 minutes, 2 minutes, 20 seconds, 2 seconds, 200 milliseconds], if the system has 3 available CPU cores, the timing engine might allocate them as follows:

[0138] Thread 1: Responsible for processing timer containers of 2 hours and 20 minutes.

[0139] Thread 2: Responsible for handling the 2-minute and 20-second timer containers.

[0140] Thread 3: Responsible for handling the 2-second and 200-millisecond timer containers.

[0141] After allocation, each thread synchronously drives the timing container it is responsible for to execute the pulse task. The pulse task is the core operation of the timing container, including the following aspects:

[0142] Trigger status check: Periodically check the trigger status of all timers in the timer container according to the preset time interval.

[0143] Iterate through timers to trigger expiration events: For timers whose trigger status is "triggered", execute the corresponding triggering operation, such as calling a callback function or sending an event notification.

[0144] Update Remaining Time: Update the remaining trigger time of all timers in the container based on the passage of time.

[0145] Dynamic migration: For timers with remaining trigger time less than the current container's preset time interval, migrate them to a lower-level timer container to obtain more precise trigger time control.

[0146] By using multi-threaded parallel processing of different timer containers, the system can handle a large number of timer instances simultaneously, improving overall processing efficiency and response speed. Furthermore, because timer containers with different time intervals are assigned to different threads, the workload of each thread remains relatively balanced.

[0147] The system described above utilizes a dynamic allocation algorithm to distribute timers to groups of different time intervals (e.g., 1 day → 1 hour → 1 second) based on their remaining time. This is combined with a group pulse triggering mechanism, timer migration strategy, and hardware optimization for multi-core CPU parallel processing. This solution addresses the technical problems of traditional timer systems (such as Java Timer) that suffer from low efficiency (high-frequency checks waste resources), response latency (lack of proximity-based priority processing), and poor scalability (difficulty in supporting large-scale dynamic scheduling) due to single-interval scheduling. It achieves the technical effects of reducing invalid checks and lowering CPU usage, dynamic optimization, strong scalability (support for custom levels), and resource conservation. The hierarchical management and dynamic allocation mechanism balances timing accuracy with system resource consumption.

[0148] In one embodiment, Figure 4 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application, such as... Figure 4 As shown, an electronic device is provided, which can be a server, and its internal structure diagram can be as follows. Figure 4As shown, the electronic device includes a processor, a network interface, internal memory, and non-volatile memory connected via an internal bus. The non-volatile memory stores the operating system, computer programs, and a database. The processor provides computing and control capabilities, the network interface communicates with external terminals via a network connection, the internal memory provides an environment for the operation of the operating system and computer programs, the computer programs are executed by the processor to implement a ladder-style multi-level timing method, and the database stores data.

[0149] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0150] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0151] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A stepped multi-level timing method, characterized in that, Based on a tiered timing system, the tiered timing system includes a timer, a timing container, and a timing engine for managing the timing container and dynamically allocating the timer. The method includes: The timing engine is initialized to obtain multiple preset time intervals with decreasing time granularity, wherein the preset time intervals are used to instruct the timing container to check the trigger status of the timer; Based on multiple preset time intervals, multiple sets of timing containers corresponding to different timing precision requirements are created, and a reverse index is established between each timing container; Upon receiving a new timer instance, a dynamic allocation algorithm is used to dynamically allocate the timer instance to multiple timer containers for processing in a step-down manner based on the remaining time of the timer instance and the reverse index.

2. The method according to claim 1, characterized in that, Based on multiple preset time intervals, multiple sets of timing containers corresponding to different timing precision requirements are created, and a reverse index is established between each timing container, including: Iterate through the preset time intervals, create a corresponding timer container for each preset time interval, and configure attribute parameters for each timer container; Based on the time interval, the timing container is divided into different levels to obtain a multi-level timing container with decreasing time granularity. The larger the preset time interval, the higher the level of the timing container; the smaller the preset time interval, the lower the level of the timing container. Sort all timing containers from largest to smallest according to a preset time interval, and create the reverse index list.

3. The method according to claim 2, characterized in that, The process of dynamically allocating the timer instances to multiple timer containers in a step-decreasing manner includes: In the initial state, the corresponding first timing container is matched according to the initial remaining trigger time of the timer instance; In the first timing container, following the dynamic changes of the remaining trigger time, the trigger status of the timer instance is checked, and the timer is migrated to a second timing container that matches the current remaining time through a dynamic migration mechanism.

4. The method according to claim 3, characterized in that, In any given timing container, checking the trigger status of the timer includes: Check the triggering status of the timer instance according to the preset time interval corresponding to the timer container; If the trigger state is not triggered, determine whether the current remaining trigger time of the timer instance is less than the preset time interval of the timer container. If not, continue to check the trigger state. If yes, dynamically migrate the timer instance.

5. The method according to any one of claims 3 to 4, characterized in that, Dynamically migrating the timer instance within any timer container includes: Based on the reverse index, obtain multiple time containers to be migrated that have a time granularity smaller than the first time container; Determine the candidate preset time intervals corresponding to each time container to be migrated, and obtain the current remaining time of the timer instance; Based on the current remaining time and each candidate preset time interval, the most matching time container group to be migrated is obtained as the second time container, and the timer instance is migrated to the second time container.

6. The method according to claim 3, characterized in that, The method further includes: If the trigger state is "triggered", determine whether the current trigger count of the timer instance meets the preset maximum trigger count. If so, remove the timer instance from the timing container and delete the timer from the global hash table of the timing engine; If not, the remaining time of the timer instance is reset to the initial remaining trigger time, and the reset timer instance is dynamically allocated to multiple timer containers in a step-decreasing manner through a dynamic allocation calculation.

7. The method according to claim 1, characterized in that, The method further includes: The timing engine is used to obtain the number of available CPU cores and initialize the thread pool. The timer containers with different time intervals are allocated to different threads in the thread pool according to their core count, and each thread synchronously drives the corresponding container to execute pulse tasks. The pulse tasks include: trigger status check, traversing the timer to trigger the expiration, updating the remaining time, and dynamic migration.

8. A stepped multi-level timing system, characterized in that, The system includes: a timer, a timing container, and a timing engine for managing the timing container and dynamically allocating the timer, for executing the tiered multi-level timing method of claim 1 and performing timing tasks.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images