A real-time data delay scheduling method under a large-scale limited out-of-order scenario
By using task hashing and time wheel mechanisms, the problem of orderly task distribution and high reliability in large-scale out-of-order scenarios is solved, achieving efficient and reliable delayed scheduling and improving task processing efficiency and throughput.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING IRIDIUM SOFT TECH CO LTD
- Filing Date
- 2023-03-30
- Publication Date
- 2026-07-31
AI Technical Summary
Existing technologies cannot achieve efficient, reliable, and orderly delayed scheduling of real-time data in large-scale, limited, and out-of-order scenarios, especially in abnormal situations where the reliability and order of tasks are difficult to guarantee.
By hashing tasks to different partitions and utilizing time wheels and dynamic caching mechanisms, the system ensures task ordering and high reliability. It also adopts a loosely coupled design to reduce intrusion into business processes and leverages multi-process concurrency to improve throughput.
It achieves efficient, reliable, and orderly delayed task scheduling, improves latency performance, reduces dependence on databases, supports multi-process concurrency, and ensures task uniqueness and efficient execution.
Smart Images
Figure CN116339950B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data delay scheduling technology, specifically to a method for real-time sequential scheduling in out-of-order scenarios where data has a limited time frame. Background Technology
[0002] In most IT systems, many scenarios require the execution of a specific task at a particular moment. With the development of computer hardware and the popularization of networks, the amount of data processed in IT systems is increasing daily. These events have the following characteristics:
[0003] A. Increasing event volume: Due to the need for centralization, the larger the event volume, the larger the workload of management, with peaks reaching tens of thousands of tasks triggered simultaneously.
[0004] B. Event reliability is getting higher and higher: The high reliability of events requires that tasks are not lost when business programs restart or anomalies occur.
[0005] C. Events are disordered: Disordered events mean that the operations on tasks are out of order, and the business layer needs to ensure the orderliness of adding / deleting / modifying tasks.
[0006] D. The timeliness of the event is very important: the trigger time after the event occurs and is delayed needs to be accurate to the second.
[0007] Given the characteristics of these events, the scheduled execution of tasks needs to have persistence capabilities, ensure high reliability, support distributed deployment of business applications, and be real-time and efficient.
[0008] In view of the characteristics of the above-mentioned events, the following technical solutions exist:
[0009] Option 1: ScheduledExecutorService (a thread pool-based scheduled task class): After receiving a task, the thread pool is used to schedule the task with a delay.
[0010] Option 2: Quartz (an open-source job scheduling framework): After receiving a task, it persists the task to the database and supports delayed scheduling of tasks by the cluster.
[0011] However, existing technologies have the following drawbacks:
[0012] Option 1: ScheduledExecutorService is a memory-based delayed scheduling method that does not have clustering capabilities and cannot guarantee task reliability in abnormal situations.
[0013] Option 2: Quartz is the de facto standard for scheduled tasks in Java, but it still has the following drawbacks:
[0014] A. It requires persisting the business QuartzJobBean to a database table, which is quite intrusive to the system.
[0015] B. With the business logic and QuartzJobBean being heavily coupled, performance will be greatly limited by the business logic as the workload increases and the business logic becomes more complex.
[0016] C. Using a database for persistence can lead to performance bottlenecks when a large number of tasks are triggered simultaneously.
[0017] D. In cluster mode, scheduling is random and the order of events cannot be guaranteed. Summary of the Invention
[0018] The technical problem to be solved by the present invention is to provide a real-time data delay scheduling method in a large-scale finite out-of-order scenario, which can realize real-time sequential scheduling in a finite-time out-of-order scenario.
[0019] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows.
[0020] A real-time data delay scheduling method for large-scale finite out-of-order scenarios includes the following steps:
[0021] S1. Hash tasks into different partitions based on their identifiers to ensure their order and provide conditions for distributed processing;
[0022] S2. Define several clock cycles and step sizes using a time wheel. Each time the pointer moves one step, retrieve the task on the clock scale and execute it.
[0023] S3. Confirm the task.
[0024] Preferably, step S1 specifically includes the following steps:
[0025] S11. Using a task hasher, related tasks are grouped according to their identifiers, and unrelated tasks are hashed according to a certain strategy to ensure the orderliness of related tasks.
[0026] S12. Distribute the tasks processed in step S11 to different partitions to form loose coupling.
[0027] Preferably, in step S12, a certain strategy is implemented automatically according to the business logic requirements.
[0028] Preferably, when the current task type obtained in step S2 is "add", the task execution method is as follows:
[0029] If the estimated execution time of the current task is later than the operation time of the confirmed task obtained from step S3, it means that the current task has not been executed. The task is then placed in the cache according to the task group, task identifier, and task type.
[0030] If the execution time of a task is earlier than or equal to the operation time of a confirmed task, it means that the task has been executed and no further action is required.
[0031] Preferably, when the type of the current task obtained in step S2 is deletion, the task execution method is: query the task whose type is addition based on the task group, task identifier and task type;
[0032] If no results are found, it means that the task of type "add" has already been executed. The task of type "delete" will be cached and the deletion will fail.
[0033] If a task of type "add" is found and its expected execution time is earlier than or equal to the receiving time of a task of type "delete", it means that the task of type "delete" cannot successfully delete the task of type "add". The task of type "delete" will be cached and set as a deletion failure.
[0034] If the query finds a task of type "Add" whose expected execution time is later than the receiving time of a task of type "Delete", it means that the task of type "Delete" can delete the task of type "Add". Delete the task of type "Add" from the cache, add the task of type "Delete" to the cache, and the deletion is successful.
[0035] Preferably, step S3 specifically includes the following steps:
[0036] S31. A scheduled task periodically retrieves the minimum position from the time wheel;
[0037] S32. After the task is delayed, determine whether the current position is less than or equal to the minimum position;
[0038] If so, the task can be confirmed;
[0039] If not, the task cannot be confirmed;
[0040] S33. After the task is successfully sent, record the confirmation information.
[0041] Preferably, the confirmed information in step S33 includes the minimum position, maximum position, task, estimated execution time, and task reception time in the time wheel.
[0042] Due to the adoption of the above technical solutions, the technical progress achieved by this invention is as follows.
[0043] This invention significantly improves latency performance: tasks are loosely coupled with business logic, so latency does not depend on task execution efficiency; tasks do not rely on a database, but are stored and distributed using queues; and tasks are triggered using time wheel technology, thus significantly improving latency performance.
[0044] This invention enables ordered distribution of unordered tasks: based on the task's business identifier, a certain hashing strategy is used to hash the tasks into an ordered queue, thereby achieving ordered distribution.
[0045] This invention achieves high reliability for tasks: by utilizing the confirmation function, tasks can be consumed repeatedly, and program-controlled execution is performed only once, thus achieving high reliability for tasks.
[0046] This invention enables multi-process concurrency: by utilizing partitioning capabilities, tasks can be hashed and consumed concurrently by multiple processes, thereby improving throughput. Attached Figure Description
[0047] Figure 1 This is a diagram of the architecture of the present invention;
[0048] Figure 2 This is a schematic diagram of the task hasher of the present invention;
[0049] Figure 3 This is a schematic diagram of the task scheduler of the present invention;
[0050] Figure 4 This is a flowchart of the task scheduling process of the present invention;
[0051] Figure 5 This is a flowchart illustrating the task confirmation process of the present invention. Detailed Implementation
[0052] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.
[0053] A real-time data delay scheduling method for large-scale finite out-of-order scenarios, combined with Figure 1 As shown, it includes the following steps:
[0054] S1. Distribute tasks to different partitions based on their identifiers to ensure their order and provide conditions for distributed processing.
[0055] S2. Define several clock cycles and step sizes using a time wheel. Each time the pointer moves one step, retrieve the task on the clock scale and execute it.
[0056] S3. Confirm the task.
[0057] The task confirmation process, such as Figure 5 As shown, the specific steps include:
[0058] S31. The scheduled task retrieves the minimum position from the time wheel at regular intervals.
[0059] Each task in the time wheel has an offset, which represents its position. By iterating through all tasks in the time wheel, the minimum offset is calculated. For example, if task A is at position 50, task B at position 80, and task C at position 100, the minimum offset obtained after iterating is 50.
[0060] S32. After the task is delayed, determine whether the current position is less than or equal to the minimum position;
[0061] If so, the task can be confirmed;
[0062] If not, the task cannot be confirmed;
[0063] Assume the time wheel contains task A at position 50, with an estimated execution time of 16:00:00; task B at position 80, with an estimated execution time of 15:50:00; and task C at position 100, with an estimated execution time of 16:10:00. Task B experiences a delay first, and polling reveals the minimum position as 50. Since position 80 is greater than the minimum position 50, task B cannot be confirmed. Task A experiences a delay, and polling reveals the minimum position as 100. Since position 50 is less than the minimum position 100, task A can be confirmed. Task C experiences a delay, and polling yields no data, so the minimum position remains 100. Since 100 equals 100, task C can be confirmed.
[0064] S33. After the task is successfully sent, record the confirmation information. The confirmation information includes the minimum position, maximum position in the time wheel, the task, the estimated execution time, and the task reception time.
[0065] like Figure 2 As shown, step S1 specifically includes the following steps:
[0066] S11. The task hasher groups related tasks according to their identifiers, and hashes unrelated tasks according to a certain strategy to ensure the orderliness of related tasks.
[0067] S12. Distribute the tasks processed in step S11 to different partitions to form loose coupling, reduce intrusion, and improve processing efficiency.
[0068] Specifically, certain strategies can be implemented according to business logic needs. For example: Task A and Task B are related to business, so the partition identifier is set to 1; Task C is not related to business of Task A and Task B, so the partition identifier is set to 2; the number of partitions is 3, namely partition 0, partition 1, and partition 2; the partition identifier of Task A and Task B is modulo the number of partitions to get 1, and the data will be sent sequentially to partition 1; the partition identifier of Task C is modulo the number of partitions to get 2, and the data will be sent to partition 2.
[0069] Step S2, as follows Figure 3 As shown, the task scheduler uses a time wheel and dynamic cache to execute tasks. The time wheel scheme introduces the concept of a clock from real life into the software design. The main idea is to define several clock cycles (multi-layers) and step size (time interval). Each time the pointer moves one step, it will obtain the task on the clock scale and execute it.
[0070] The tasks output by the task hasher enter the task scheduler in an orderly manner, are arranged into an ordered queue, real-time tasks are assigned to the time wheel, and timed-out tasks are put into cached data.
[0071] Task scheduling process as follows Figure 4 As shown:
[0072] Scenario 1: If the type of the current task is "add", the task execution method is as follows:
[0073] A. If the estimated execution time of the current task is later than the operation time of the confirmed task obtained from step S3, it means that the current task has not been executed. The task is placed in the cache according to the task group, task identifier and task type.
[0074] For example, if the operation time of the confirmed task obtained from S3 is 16:00:00, and the estimated execution time of the current task is 16:10:00, it means that the current task has not been executed and is placed in the cache to wait for execution.
[0075] B. If the execution time of a task is earlier than or equal to the operation time of a confirmed task, it means that the task has been executed and no further action is taken.
[0076] For example: Assume task A is at position 100, with an estimated execution time of 16:00:00; task B is at position 50, with an estimated execution time of 16:10:00. Task A executes first. After execution, according to step S3, task A cannot be confirmed. Task B executes next. After execution, according to step S3, task B becomes a confirmed task. If the program is restarted at this point, task A will be received again. However, the estimated execution time of task A is already earlier than the operation time of the confirmed task in S3, and therefore it cannot be executed again.
[0077] Scenario 2: If the current task type is "delete", the task execution method is to query the task type "add" based on the task group, task identifier, and task type.
[0078] A. If no results are found, it means that the task of type "add" has already been executed. The task of type "delete" will be cached, and the deletion will fail.
[0079] For example, if a task of type "add" is executed at 16:00:00, and the corresponding task of type "delete" arrives at 16:10:00, the task of type "add" will not be found at this time because the task has already been executed. Instead, the task of type "delete" will be added to the time wheel cache.
[0080] B. If a task of type "add" is found and its expected execution time is earlier than or equal to the receiving time of a task of type "delete", it means that the task of type "delete" cannot successfully delete the task of type "add". The task of type "delete" will be cached and the deletion will be set to fail.
[0081] For example: Suppose that the task of type "add" is scheduled to be executed at 16:00:00, and the corresponding task of type "delete" is also scheduled to be received at 16:00:00. In this case, the task of type "add" cannot be successfully deleted, and the task of type "delete" is added to the time wheel cache.
[0082] C. If the query finds a task of type "add" whose expected execution time is later than the receiving time of a task of type "delete", it means that the task of type "delete" can delete the task of type "add". Delete the task of type "add" from the cache, because the task of type "add" no longer needs to be executed. Put the task of type "delete" into the cache and set the deletion to successful.
[0083] For example, if the task of type "add" is scheduled to be executed at 16:00:00, and the corresponding task of type "delete" is scheduled to be received at 15:50:00, then the task of type "add" can be successfully deleted and the task of type "delete" can be added to the cache.
[0084] Tasks are cached and retrieved at the execution time. The tasks are then hashed according to the S1 method, which is the execution of the task.
[0085] In use, this invention achieves ordered distribution by distributing unordered business data to ordered queues according to a certain hashing strategy; it reduces invasiveness and improves task processing efficiency by loosely coupling tasks with business logic, where operations are only performed on tasks and business logic is implemented by specific business code; it achieves high task reliability by using an acknowledgment mechanism; it achieves distributed processing by receiving data from ordered queues using a multi-process approach; and it improves task triggering efficiency by using a time wheel technique for task triggering.
Claims
1. A real-time data delay scheduling method for large-scale finite out-of-order scenarios, characterized in that: Includes the following steps: S1. Hash tasks into different partitions based on their identifiers to ensure their order and provide conditions for distributed processing; Step S1 specifically includes the following steps: S11. Using a task hasher, related tasks are grouped according to their identifiers, and unrelated tasks are hashed according to a certain strategy to ensure the orderliness of related tasks. S12. Distribute the tasks processed in step S11 to different partitions to form loose coupling; S2. Define several clock cycles and step sizes using a time wheel. Each time the pointer moves one step, retrieve the task on the clock scale and execute it. When the type of the current task obtained in step S2 is "add", the task execution method is as follows: If the estimated execution time of the current task is later than the operation time of the confirmed task obtained from step S3, it means that the current task has not been executed. The task is then placed in the cache according to the task group, task identifier, and task type. If the execution time of a task is earlier than or equal to the operation time of a confirmed task, it means that the task has been executed and no further action is required. When the current task type obtained in step S2 is deletion, the task execution method is as follows: query the task type as addition based on the task group, task identifier, and task type; If no results are found, it means that the task of type "add" has already been executed. The task of type "delete" will be cached and the deletion will fail. If a task of type "add" is found and its expected execution time is earlier than or equal to the receiving time of a task of type "delete", it means that the task of type "delete" cannot successfully delete the task of type "add". The task of type "delete" will be cached and set as a deletion failure. If the query finds a task of type "add" whose expected execution time is later than the receiving time of a task of type "delete", it means that the task of type "delete" can delete the task of type "add". Delete the task of type "add" from the cache, add the task of type "delete" to the cache, and the deletion is successful. S3. Confirm the task; Step S3 specifically includes the following steps: S31. A scheduled task periodically retrieves the minimum position from the time wheel; S32. After the task is delayed, determine whether the current position is less than or equal to the minimum position; If so, the task can be confirmed; If not, the task cannot be confirmed; S33. After the task is successfully sent, record the confirmation information; The confirmed information in step S33 includes the minimum position, maximum position, task, estimated execution time, and task reception time in the time wheel.
2. The real-time data delay scheduling method for large-scale finite out-of-order scenarios according to claim 1, characterized in that: The strategy in step S12 is implemented according to the business logic requirements.