A custom time-delay message processing method based on a distributed message queue

Abstract

This invention relates to a custom time-delay message processing method based on a distributed message queue, belonging to the field of distributed message queue technology. The method includes: a client receiving an arbitrary delay duration specified by the user, calculating a target Unix timestamp based on the client's current system time, and sending a message carrying that timestamp to a message broker layer; the message broker layer storing the message in a delay queue and inserting it into the corresponding time slot of a hierarchical circular time wheel according to the target Unix timestamp; the hierarchical circular time wheel consists of multiple levels of circular arrays, connected by an overflow mechanism; the message broker layer advances a global pointer at fixed time intervals, scans the messages to be scheduled in the time slots, and transfers expired messages from the delay queue to a regular queue for consumer consumption. This achieves flexible support for arbitrary delay durations and achieves task scheduling with O(1) time complexity through the hierarchical circular time wheel.

Description

Technical Field

[0001] This invention belongs to the field of distributed message queue technology, and particularly relates to a custom time-delay message processing method based on distributed message queues. Background Technology

[0002] In the field of delayed message processing in message queues, existing technologies mainly rely on fixed delay levels to achieve delayed message delivery. For example, RocketMQ version 4.0 only supports 18 preset delay levels (such as 1s, 5s, 10s, etc.), which cannot meet users' needs for arbitrary delay durations. Although RocketMQ version 5.0 introduced arbitrary delay message functionality, there is still a maximum delay time limit, resulting in insufficient applicability in scenarios requiring ultra-long delays or precise time triggering. In addition, existing solutions face problems such as low storage efficiency and high scheduling complexity when processing large-scale custom delayed messages, making it difficult to support flexible scheduling requirements in high-concurrency scenarios.

[0003] To address the aforementioned technical pain points, several patents have explored related areas. For example, patent application CN112118297A discloses a delayed message control method based on a time wheel algorithm. This method achieves delayed message push by setting preset delay levels and scanning trajectory data, but it is still limited by a fixed delay level architecture and cannot support users to customize arbitrary delay times. Patent application CN119597507A proposes a business timed delay processing scheme based on RocketMQ, which achieves dynamic scheduling through delayed consumption topics and consumer thread polling, but its upper limit for delay levels is forcibly set to 2 hours, which cannot break through the maximum delay constraint. Patent application CN115242744A uses time wheel and message hiding technology to process custom delayed messages, but it relies on complex log file management and physical offset tracing mechanisms, increasing system complexity and failure risk.

[0004] Therefore, none of these solutions systematically address the core issues in current technology, and the main technical problems are as follows: (1) The fixed delay level mechanism lacks flexibility and cannot meet the user's need for a delay of any length, thus limiting the diversity of application scenarios; (2) Existing custom delay solutions generally set a maximum delay time threshold, which cannot adapt to business scenarios with ultra-long delays (such as several days or months); (3) The delayed message storage and scheduling architecture is complex and relies on multi-level log files and index maintenance, resulting in high system resource consumption and low fault recovery efficiency; (4) The time wheel algorithm has insufficient scalability in high-concurrency scenarios and lacks a dynamic load balancing mechanism, which can easily lead to message scheduling delays or loss.

[0005] To address the technical issues of traditional message queue delayed message processing methods mentioned above, such as the inability to support user-defined arbitrary delay durations, the existence of maximum delay time limits, and the complexity of scheduling architectures and insufficient scalability in high-concurrency scenarios, no effective solution has yet been proposed. Summary of the Invention

[0006] In view of the shortcomings of the prior art, the purpose of the invention is to provide a custom time-delay message processing method based on a distributed message queue, which breaks through the maximum delay limit and optimizes resource utilization by reconstructing the delayed message storage architecture and dynamic scheduling strategy.

[0007] In a first aspect, the present invention proposes a custom time-delay message processing method based on a distributed message queue, comprising: a client receiving an arbitrary delay duration specified by a user, calculating a target Unix timestamp based on the client's current system time and the arbitrary delay duration, and sending a message carrying the target Unix timestamp to a message broker layer of the distributed message queue; the message broker layer storing the received message in a delay queue, and inserting the message into the corresponding time slot of a hierarchical circular time wheel according to the target Unix timestamp; the hierarchical circular time wheel consists of multiple levels of circular arrays, each level having a circular array of... The group is divided into several time slots, each time slot corresponding to a fixed time slot granularity, and the granularity of each time slot within the same level is the same; and, the circular array of each level corresponds to a fixed total time span of the level, and the levels are connected through an overflow mechanism; the message broker layer advances the first global pointer at a first fixed time interval, and when the first global pointer points to a time slot of the hierarchical circular time wheel, it scans all the messages to be scheduled in the time slot. If the target Unix timestamp of a message to be scheduled is less than or equal to the current system time of the message broker layer, then the message to be scheduled is transferred from the delayed queue to the ordinary queue for consumption by consumers.

[0008] According to a second aspect of the present disclosure, a custom time-delay message processing system based on a distributed message queue is provided, comprising: a client layer, configured to receive an arbitrary delay duration specified by a user, calculate a target Unix timestamp based on the client's current system time and the arbitrary delay duration, and send a message carrying the target Unix timestamp to a message broker layer; the message broker layer comprising: a delay queue, configured to store the received message; and a hierarchical circular time wheel, composed of multiple levels of circular arrays, each level of the circular array being divided into several time slots, each time slot corresponding to a fixed time slot granularity, and the granularity of each time slot within the same level being... The same; and, each level of the circular array corresponds to a fixed total time span of the level, and the levels are connected through an overflow mechanism; the message insertion module is used to insert the message into the corresponding time slot of the hierarchical circular time wheel according to the target Unix timestamp; the message transfer module is used to advance the first global pointer at a first fixed time interval, and when the first global pointer points to a time slot of the hierarchical circular time wheel, scan all the messages to be scheduled in the time slot. If the target Unix timestamp of a message to be scheduled is less than or equal to the current system time of the message broker layer, then the message to be scheduled is transferred from the delayed queue to the ordinary queue for consumption by the consumer.

[0009] The beneficial effects of this invention are as follows: (1) Improved flexibility and accuracy: By calculating the target Unix timestamp and writing it into the message attribute through the client, the original fixed delay level limitation of the distributed message queue (RocketMQ) is broken, and users can specify any delay duration to meet the needs of diverse business scenarios; at the same time, the accuracy and reliability of data input are ensured through the timestamp validity verification mechanism.

[0010] (2) High efficiency and low resource consumption: The hierarchical ring time wheel structure is adopted, and the time complexity of task insertion and scheduling is O(1), which avoids the high overhead of traditional scanning algorithms. The layers are connected through an overflow mechanism, which realizes efficient management of large-scale delayed tasks under limited storage resources and significantly improves the system throughput.

[0011] (3) Reliability and consistency guarantee: Transactional operations are introduced during the message expiration and transfer process, including locking message status, updating metadata, and triggering notification mechanisms to ensure that messages are not lost or duplicated; the extension layer independent time wheel service is combined with the RocketMQ transaction message mechanism to achieve eventual consistency of delayed tasks.

[0012] (4) Scalability and scenario adaptation: Provide two extension schemes: local time wheel on the client side and time wheel service in the independent middleware layer, which are suitable for scenarios with low latency and high reliability requirements, respectively; dynamically adjust the time wheel hierarchy or time slot granularity by monitoring the backlog of tasks to avoid performance bottlenecks under high concurrency; for ultra-long latency tasks, provide two processing strategies: message splitting and external storage to break through the maximum latency range limit.

[0013] Therefore, this invention achieves efficient, reliable, and flexible custom delayed message processing by organically combining a hierarchical ring time wheel scheduling mechanism, arbitrary timestamp support, transactional message transfer, hierarchical architecture design, and extension layer optimization scheme. It effectively solves the technical problems of traditional message queue delayed message processing methods, such as the inability to support user-defined arbitrary delay duration, the existence of maximum delay time limit, and the lack of scalability in complex scheduling architecture and high-concurrency scenarios. Attached Figure Description

[0014] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.

[0015] Figure 1 This is an overall architecture diagram of a custom time-delay message processing system based on a distributed message queue, as described in the embodiments of this application. Figure 2 This is a flowchart of a custom time-delay message processing method based on a distributed message queue, according to an embodiment of this application. Figure 3 This is a schematic diagram illustrating two implementation processes of the client layer in RocketMQ versions 4.x and 5.x, according to embodiments of this application. Figure 4 This is a schematic diagram of the layered annular time wheel structure according to an embodiment of this application; Figure 5 This is a flowchart of the internal scheduling process of the message broker layer according to an embodiment of this application; Figure 6 This is a scheduling flowchart of the extended layer independent time wheel service according to the embodiments of this application; Figure 7 This is a diagram illustrating the overall system architecture and data flow according to the embodiments of this application. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0017] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.

[0018] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.

[0020] Terminology Explanation: 1. RocketMQ (Distributed Message Queue): An open-source distributed message middleware that adopts a publish-subscribe model. It features high performance, high reliability, and high real-time performance. It supports core functions such as reliable message transmission, ordered messages, and transactional messages. It is widely used in scenarios such as asynchronous decoupling, traffic shaping, and log processing.

[0021] 2. Custom delayed messages: Supports users to specify any delay duration (breaking through the original RocketMQ fixed delay level limitation), and requires the calculation and writing of delay timestamps for message types.

[0022] 3. Broker Layer (Message Broker Layer): The core server-side component of RocketMQ, responsible for message storage, forwarding, and scheduling. It receives messages sent by producers and persists them, while maintaining the consumption progress of the message queue and providing message push or pull services to consumers. In a RocketMQ cluster, the Broker is typically deployed in a master-slave architecture to ensure high availability.

[0023] 4. Layered circular time wheel mechanism: The scheduling structure consists of multi-level circular arrays, with each level corresponding to a fixed time span time slot, which is connected through an overflow mechanism. The task scheduling time complexity is O(1).

[0024] 5. delayTimeStamp: A Unix timestamp generated by adding the current system time to the user-inputted delay duration and writing it to the message attributes to specify any delay.

[0025] 6. sendDelayMessage (dedicated API method): This method is called by the RocketMQ 5.x client. It encapsulates the delay timestamp calculation logic internally, eliminating the need for manual processing by the user.

[0026] 7. Timestamp validity verification: Before sending a message, check whether the delayed timestamp exceeds the maximum delay range or is a negative value. If invalid, trigger the exception handling mechanism.

[0027] 8. Transactional message transfer: When the Broker transfers delayed messages to a regular queue, it first locks the messages to avoid concurrent conflicts. After the transfer, it updates the metadata and triggers a notification, relying on the built-in storage engine to ensure persistence and high availability.

[0028] 9. Netty HashedWheelTimer: A client-side extended local time wheel component that temporarily stores delayed tasks (Runnable objects), advances them in fixed time slots, and automatically sends a message to the Broker when the target time is reached.

[0029] 10. Middleware Layer Independent Time Wheel Service: This service acts as a proxy layer to receive delayed messages from clients. It is optimized based on Kafka's layered time wheel and combined with RocketMQ's transactional message mechanism to ensure eventual message consistency.

[0030] 11. Clock Synchronization (NTP / PTP): The core requirement is for the client and server to calibrate time deviations through the NTP protocol or a distributed clock service (such as PTP) to avoid scheduling errors.

[0031] 12. Maximum delay range (40 days): The upper limit of delay is constrained by the time wheel hierarchy design. If the delay exceeds the range, the application layer needs to handle it additionally.

[0032] 13. Message splitting (long-cycle scheduling): A message processing method with a delay of more than 40 days, which is to split into multiple sub-tasks or combine with external storage to achieve long-cycle scheduling.

[0033] 14. Time slot granularity optimization: High-precision scenarios use millisecond-level fine-grained time slots, requiring optimization solutions that balance system resource overhead.

[0034] 15. Task backlog monitoring: A mechanism that monitors the backlog of tasks in the time wheel and dynamically adjusts the hierarchical structure to prevent performance bottlenecks.

[0035] 16. delayTimeLevel: A message attribute in RocketMQ 4.x that only supports fixed delay levels. This solution extends it to allow arbitrary delays.

[0036] 17. Transaction Check (Before Delayed Task Scheduling): In the middleware layer extension, a local transaction check is performed before delayed task scheduling to ensure eventual message consistency.

[0037] Method Implementation Examples This embodiment provides a custom time-delay message processing method based on a distributed message queue, which is suitable for corresponding custom time-delay message processing systems. Figure 1 The overall architecture diagram of the system is shown, for reference. Figure 1 As shown, the system adopts a three-tier architecture, including a client layer, a message broker layer, and an extension layer. The client layer is responsible for receiving user-specified delay durations, calculating the target Unix timestamp, and sending the message to the message broker layer. The message broker layer is the core of the system, with a built-in hierarchical circular time wheel and delay queue, responsible for the storage and scheduling of delayed messages. The extension layer provides optional optimization schemes, including a client-side local time wheel component and an independent middleware layer time wheel service, to meet the performance and reliability requirements of different scenarios. The three layers work together through standardized interfaces to achieve end-to-end processing of custom delayed messages.

[0038] Figure 2 A flowchart illustrating the method is shown below. (Refer to...) Figure 2 As shown, the method includes: S202: The client receives any delay duration specified by the user, calculates the target Unix timestamp based on the client's current system time and the arbitrary delay duration, and sends the message carrying the target Unix timestamp to the message broker layer of the distributed message queue.

[0039] S204: The message broker layer stores the received message in a delayed queue and inserts the message into the corresponding time slot of the hierarchical circular time wheel according to the target Unix timestamp; the hierarchical circular time wheel consists of multiple levels of circular arrays, each level of the circular array is divided into several time slots, each time slot corresponds to a fixed time slot granularity, and the granularity of each time slot within the same level is the same; furthermore, each level of the circular array corresponds to a fixed total time span of the level, and the levels are connected through an overflow mechanism.

[0040] S206: The message broker layer advances the first global pointer at a first fixed time interval. When the first global pointer points to a time slot of the hierarchical circular time wheel, it scans all the messages to be scheduled in the time slot. If the target Unix timestamp of a message to be scheduled is less than or equal to the current system time of the message broker layer, the message to be scheduled is transferred from the delayed queue to the ordinary queue for consumption by consumers.

[0041] In this embodiment of the invention, when a user needs to send a message that needs to be delivered at any time in the future, the client receives any delay duration specified by the user, for example, the user wants the message to be delivered after 3 hours, 15 minutes, and 20 seconds. At this time, the client first obtains its current system time, for example, assuming the current system time is March 1, 2025, 10:00:00 (represented as 1700000000 in Unix timestamps). Based on this current system time and the delay duration, the target Unix timestamp is calculated as 1700000000 + (3 × 3600 + 15 × 60 + 20) = 1700012120. Then, the client sends the message carrying this target Unix timestamp to the message broker layer of a distributed message queue (e.g., RocketMQ). It should be noted that the client can implement the above sending operation in several ways. For example, in RocketMQ 4.x, the client directly writes the calculated target Unix timestamp into the message attribute delayTimeStamp; in RocketMQ 5.x, the client can call the dedicated API method sendDelayMessage, which automatically completes the timestamp calculation and encapsulation internally.

[0042] Figure 3 This illustrates two implementation flows of the client layer in RocketMQ versions 4.x and 5.x, such as... Figure 3As shown, this invention provides two implementation paths for different versions of RocketMQ: the upper path is the implementation method for RocketMQ 4.x, where the client receives any user-specified delay duration, calculates the target Unix timestamp based on the client's current system time and the delay duration, writes the timestamp into the message attribute `delayTimeStamp`, and verifies the timestamp's validity before sending; the lower path is the implementation method for RocketMQ 5.x, where the client directly calls a dedicated API method (such as `sendDelayMessage`) to transmit the delay duration, with the timestamp calculation logic encapsulated internally by the API, and timestamp validity verification is also performed before sending. The core commonality of both implementation methods is that they both support user-specified arbitrary delay durations, both use the target Unix timestamp to identify the expected message delivery time, and both perform timestamp validity verification before sending to ensure that invalid inputs exceeding the maximum delay range or negative values ​​are promptly captured and trigger exception handling mechanisms. Therefore, the client can choose the appropriate implementation method based on the RocketMQ version used, and both methods can achieve custom delayed message sending based on the target Unix timestamp.

[0043] Next, after receiving the message carrying the target Unix timestamp from the client, the message broker layer first stores the message in a delay queue for management as a delayed message to be scheduled. Simultaneously, based on the target Unix timestamp in the message, the message broker layer inserts it into the corresponding time slot of the hierarchical circular time wheel. The hierarchical circular time wheel is the core scheduling structure of this invention. Figure 4 A schematic diagram of its specific structure is shown. For example... Figure 4 As shown, the hierarchical circular time wheel consists of multiple levels of circular arrays, for example... Figure 4The example illustrates three levels: Level 1 (seconds), Level 2 (minutes), and Level 3 (hours). Each level's circular array is divided into several consecutive time slots, each corresponding to a fixed granularity. All time slots within the same level have the same granularity. For example, Level 1 might have a 1-second granularity for each time slot, containing 60 time slots, resulting in a total time span of 60 seconds. Level 2 might have a 1-minute granularity for each time slot, also containing 60 time slots, for a total time span of 60 minutes. Level 3 might have a 1-hour granularity for each time slot, containing 24 time slots, for a total time span of 24 hours. Levels are connected via an overflow mechanism: when a message's delay exceeds the total time span of the current level, the message is placed in the corresponding time slot of the next level with a larger total time span. Therefore, the message broker layer determines the level and time slot position to be inserted based on the difference between the target Unix timestamp and the current system time (i.e., the remaining delay duration). For example, if the remaining delay duration is 3 hours, 15 minutes and 20 seconds, it is first determined that it exceeds the range of the first and second levels, so it is inserted into the time slot corresponding to the 3-hour interval in the third level.

[0044] Finally, the message broker layer advances the first global pointer at a first fixed time interval (e.g., every second). When the first global pointer points to a time slot in the hierarchical circular time wheel, the message broker layer scans all scheduled messages in that time slot, checking whether the target Unix timestamp of each message is less than or equal to the current system time of the message broker layer. If a scheduled message meets this condition, it means that the message's delay time has expired, and the message broker layer moves the message from the delay queue to the normal queue. Figure 5 The internal scheduling process of the message broker layer is shown, such as... Figure 5 As shown, the first global pointer continuously advances and triggers a scan. Once an expired message is found, a transfer operation is performed, moving the message from the delayed queue to the regular queue. After the transfer, messages in the regular queue can be pulled and consumed by consumers, thus achieving timely message delivery. It should be noted that the message broker layer relies on RocketMQ's built-in storage engine during the transfer process to ensure persistent message storage and high availability. However, specific transactional details (such as locking states, updating metadata, etc.) can be flexibly implemented according to the actual deployment situation, and this embodiment does not limit them.

[0045] This completes the entire process from the user specifying an arbitrary delay duration to the message finally being delivered to the consumer. Using this method, users can flexibly specify any delay duration, and the message broker layer utilizes a layered circular time wheel to achieve efficient scheduling, meeting diverse business needs.

[0046] As described in the background section, the message queue delayed message processing method has the following main problems: (1) The fixed delay level mechanism lacks flexibility and cannot meet the user's custom delay requirements for any length, thus limiting the diversity of application scenarios; (2) Existing custom delay schemes generally set a maximum delay time threshold, which cannot adapt to business scenarios with ultra-long delays (such as several days or months); (3) The delayed message storage and scheduling architecture is complex and relies on multi-level log files and index maintenance, resulting in high system resource consumption and low fault recovery efficiency.

[0047] In view of this, this application calculates the target Unix timestamp on the client and writes it into the message attribute, breaking through the original fixed delay level limitation of the distributed message queue (RocketMQ), supporting users to specify arbitrary delay durations, and meeting the needs of diverse business scenarios. Furthermore, by adopting a hierarchical circular time wheel structure, the time complexity of task insertion and scheduling is O(1), avoiding the high overhead of traditional scanning algorithms; the layers are connected through an overflow mechanism, achieving efficient management of large-scale delayed tasks under limited storage resources, significantly improving system throughput. Thus, this application, by calculating the target Unix timestamp on the client, breaks through the original fixed delay level limitation of the distributed message queue, achieving flexible support for arbitrary delay durations and meeting diverse business needs; simultaneously, through the hierarchical circular time wheel structure of the message broker layer, the insertion and scheduling of delayed tasks are completed in O(1) time complexity, avoiding the high resource consumption of traditional scanning algorithms, significantly reducing system complexity and improving scheduling efficiency. This solves the technical problems of traditional message queue delayed message processing methods, such as the inability to support user-defined arbitrary delay durations, the existence of maximum delay time limitations, and the complexity of the scheduling architecture.

[0048] Optionally, before sending the message carrying the target Unix timestamp to the message broker layer of the distributed message queue, the method further includes: verifying whether the target Unix timestamp is valid, wherein the verification includes determining whether the target Unix timestamp exceeds a preset maximum delay range or is a negative value; if the verification is invalid, an exception handling mechanism is triggered.

[0049] In this embodiment of the invention, to improve the robustness of the system and the accuracy of data input, the client can perform a timestamp validity verification operation before sending the message carrying the target Unix timestamp to the message broker layer. Specifically, after calculating the target Unix timestamp, the client first determines whether the timestamp meets preset validity conditions. These validity conditions include, but are not limited to, whether the target Unix timestamp exceeds a preset maximum delay range and whether the target Unix timestamp is negative. If the target Unix timestamp exceeds the maximum delay range or is negative, it is determined to be an invalid timestamp, and the client triggers an exception handling mechanism, such as returning an error message to the user, logging an exception, or refusing to send the message. If the verification passes, the client continues to execute subsequent message sending operations.

[0050] refer to Figure 3 As shown, in both the 4.x and 5.x versions of RocketMQ, the client layer includes a timestamp validity verification step before message sending. Taking RocketMQ 4.x as an example, after the client writes the calculated target Unix timestamp to the message attribute `delayTimeStamp`, it immediately performs a verification step to check if the timestamp exceeds the system's preset maximum delay range. Assuming the current system time is March 1, 2025, 10:00:00 (Unix timestamp 1700000000), and the preset maximum delay range is set to an example of 40 days (i.e., 40 × 24 × 3600 = 3,456,000 seconds), the valid range of the target Unix timestamp is, for example, between 1700000000 and 1703456000. If the user specifies a delay duration of 50 days, the calculated target Unix timestamp is 1700000000 + 50 × 24 × 3600 = 1704320000. This value exceeds the upper limit of the valid range, so the client determines it to be invalid and triggers exception handling. Similarly, if the user mistakenly enters a negative delay duration, the calculated target Unix timestamp will be less than the current system time (e.g., 1699999999), which will also trigger exception handling.

[0051] It should be noted that the maximum latency range described in this application is not a fixed hard threshold; the 40-day period is merely illustrative and not a limitation of the invention. Based on the hierarchical design principle of a layered circular time wheel, by increasing the number of time wheel levels or adjusting the total time span of each level, theoretically, an arbitrarily large latency range can be supported, even considered to have no strict upper limit. Users can flexibly configure the maximum latency range parameter according to actual business needs. The technical solution of this application does not rely on a specific maximum latency value, but rather achieves efficient management of large-scale latency tasks with limited storage resources through a layered overflow mechanism, avoiding the applicability limitations caused by the maximum latency threshold in traditional solutions.

[0052] Therefore, through the aforementioned timestamp validity verification mechanism, this application can effectively avoid message scheduling errors or system resource waste caused by invalid delay inputs, ensuring that only valid delayed messages within the preset range enter the scheduling process of the message broker layer, thereby further improving the stability and reliability of the system. Compared with existing technologies (such as RocketMQ 4.x's delayTimeLevel attribute, which only supports fixed levels), this application provides flexible time delay settings to meet diverse business needs, while reducing user manual calculation errors through API encapsulation.

[0053] Optionally, the method further includes: when the arbitrary delay duration specified by the user causes the calculated target Unix timestamp to exceed the maximum delay range supported by the hierarchical ring time wheel, performing the following scheduling processing on the message carrying the target Unix timestamp at the application layer: splitting the message into multiple consecutive sub-messages, the sum of the delay durations corresponding to each sub-message being equal to the arbitrary delay duration, and submitting each sub-message sequentially to the message broker layer for execution; or storing the message in external persistent storage, and having the external scheduling system re-deliver the message to the message broker layer at a time point at a preset time distance from the target Unix timestamp.

[0054] In this embodiment of the invention, to further overcome the potential latency constraints imposed by the physical structure of the hierarchical ring time wheel and meet the needs of business scenarios with ultra-long cycles (e.g., months or years), this application also provides an application-layer ultra-long latency scheduling mechanism. When any user-specified latency causes the calculated target Unix timestamp to exceed the maximum latency range supported by the hierarchical ring time wheel (e.g., exceeding 40 days), the client or application layer can trigger one of the following two scheduling methods to ensure that ultra-long latency messages can still be reliably delivered.

[0055] Therefore, during the timestamp validity verification process, if the client finds that the target Unix timestamp exceeds the preset maximum delay range, in addition to triggering the exception handling mechanism, it can also choose to enter the ultra-long delay scheduling process according to the business configuration. This application provides two specific processing methods: The first approach is message splitting. The application layer breaks down the original delayed task into multiple consecutive sub-messages, where the sum of the delay durations of each sub-message equals any delay duration specified by the user. For example, suppose a user needs to send a message with a delay of 100 days, while the maximum delay range supported by the hierarchical circular time wheel is 40 days. The application layer can split this message into three consecutive sub-messages: the first sub-message is delayed by 40 days, the second by 40 days, and the third by 20 days. The application layer submits these three sub-messages sequentially to the message broker layer for execution; that is, the first sub-message expires after 40 days and is consumed by the consumer, the consumer completes its processing, triggering the submission of the second sub-message, and so on. In this way, multiple consecutive sub-messages collectively fulfill the original ultra-long delay requirement. It should be noted that the granularity of sub-message splitting can be flexibly set according to business needs, but the sum of the delay durations of each sub-message must equal the original delay duration.

[0056] The second approach involves external persistent storage. The application layer stores the message carrying the target Unix timestamp in external persistent storage (such as a database or distributed file system), and an external scheduling system manages the message's delivery upon expiration. The external scheduling system re-delivers the message to the message broker layer at a predetermined time before the target Unix timestamp (e.g., one hour before the target timestamp arrives). Specifically, the external scheduling system periodically scans the messages in the external storage. When it detects that the current system time is less than the predetermined time before the target Unix timestamp (e.g., one hour), it resubmits the message to the message broker layer, which then schedules it according to the normal delayed message processing flow. Since the remaining delay time is within the range supported by the hierarchical circular time wheel, the message broker layer can process the message normally and transfer it to a regular queue when the target timestamp arrives.

[0057] It should be noted that the maximum delay range described in this application is not a fixed hard threshold; the 40-day limit is merely illustrative and not a limitation of the invention. Based on the hierarchical design principle of the layered ring time wheel, by increasing the number of layers or adjusting the total time span of each layer, theoretically, an arbitrarily large delay range can be supported, even considered to have no strict upper limit. Therefore, the technical solution of this application, through an ultra-long delay scheduling mechanism at the application layer, further expands the support capability for the delay range based on the physical structure of the layered ring time wheel, avoiding the applicability limitations caused by the maximum delay threshold in traditional solutions.

[0058] Through the aforementioned ultra-long delay scheduling and processing mechanism, this application can effectively adapt to business scenarios with ultra-long delays (such as several days or months). Compared with existing technologies (such as the patent application with publication number CN119597507A, whose delay level upper limit is forcibly set to 2 hours), this application breaks through the maximum delay range limit through message splitting and external storage strategies, realizes flexible support for arbitrary long delay durations, and significantly expands the diversity of application scenarios for message queue delayed message processing.

[0059] Optionally, the operation of sending a message carrying the target Unix timestamp to the message broker layer of the distributed message queue includes: introducing a local time wheel component on the client, the local time wheel component advancing at a fixed time slot granularity; encapsulating the message and the corresponding target Unix timestamp into a delayed task, and inserting the delayed task into the corresponding time slot of the local time wheel component; the local time wheel component advancing a second global pointer at a second fixed time interval, and scanning all delayed tasks in the time slot currently pointed to by the second global pointer; if the target Unix timestamp of a delayed task in the time slot currently pointed to by the second global pointer arrives, then the delayed task is executed, and the message carrying the target Unix timestamp is sent to the message broker layer.

[0060] In this embodiment of the invention, to further reduce network latency, decrease scheduling pressure on the message broker layer, and meet optimization requirements in low-latency, high-precision scenarios, this application also provides an extension scheme for a client-side local time wheel component. This scheme introduces a local time wheel component (such as HashedWheelTimer provided by Netty) on the client side, delegating the temporary storage and initial scheduling of delayed tasks to the client's local execution. Messages are only actually sent to the message broker layer when the task expires, thereby avoiding resource consumption caused by a large number of delayed messages prematurely entering the message broker layer.

[0061] refer to Figure 1 The system architecture diagram shown includes a client-side local time wheel component as an optional optimization scheme in the extension layer. This scheme can be enabled when users have low latency and accuracy requirements (e.g., allowance for millisecond-level errors) and wish to reduce network overhead. Specifically, the client no longer immediately sends messages carrying the target Unix timestamp to the message broker layer, but instead first performs the following operations locally: First, a local time wheel component is introduced on the client's extension layer side. This component advances at a fixed time slot granularity. The specific value of the time slot granularity can be configured according to business needs. For example, in high-precision scenarios, it can be set to 100 milliseconds or finer granularity, but the system resource overhead must be weighed. In this embodiment, 100 milliseconds is used as an example, but it is not intended to limit the invention.

[0062] Next, the client encapsulates the original message and its corresponding target Unix timestamp into a delayed task. This delayed task is an executable object (such as a Runnable object in Java) containing the message content to be sent and the target sending time of the message (i.e., the target Unix timestamp). Based on the difference between the target Unix timestamp and the client's current system time (i.e., the remaining delay duration), the client determines which time slot in the local time wheel component the delayed task should be inserted into and inserts it at the corresponding position.

[0063] Then, the local time wheel component advances the second global pointer at a second fixed time interval (e.g., 100 milliseconds). When the second global pointer points to a time slot, the local time wheel component scans all delayed tasks within that time slot, checking whether the target Unix timestamp for each delayed task has arrived (i.e., whether it is less than or equal to the client's current system time). It should be noted that this second fixed time interval is independent of the first fixed time interval of the message broker layer and can be configured separately according to the precision requirements of the local time wheel; for example, it can be set to finer granularity to meet high-precision scenarios.

[0064] If the target Unix timestamp of a delayed task within the time slot currently pointed to by the second global pointer has arrived, the local time wheel component immediately executes the delayed task, that is, it calls the message sending logic to send the message carrying the original target Unix timestamp to the message broker layer. Upon receiving the message, the message broker layer will perform subsequent processing according to the steps in S204 and S206 described above. Since the target timestamp of the message has arrived or is about to arrive, the message broker layer can quickly transfer it to a regular queue, thereby achieving timely message delivery.

[0065] It should be noted that the reference Figure 3 The client-side implementation flow shown is, although Figure 3 This primarily demonstrates the direct sending implementation, but the local time wheel approach can be seen as a further refinement of the "send" step: the client no longer sends directly, but first performs temporary storage and scheduling via the local time wheel, triggering the actual sending only when the target time arrives. Therefore, this approach differs from... Figure 3 The processes shown do not conflict, but rather provide an alternative implementation path.

[0066] Through the aforementioned client-side local time wheel scheme, this application achieves the following beneficial effects: Compared with existing technologies (such as pure Broker layer scheduling), by temporarily storing delayed tasks through the local time wheel, the resource consumption caused by a large number of delayed messages entering the network and message broker layer prematurely is reduced; in scenarios with low latency and high precision requirements, the fine-grained scheduling through the local time wheel improves response speed and reduces network latency; at the same time, the local time wheel component (such as NettyHashedWheelTimer) itself has efficient task insertion and cancellation capabilities (time complexity O(1)), further optimizing the performance on the client side. Thus, this scheme provides a more flexible optimization option for custom delayed message processing, suitable for business scenarios that are sensitive to network overhead or require local temporary storage processing.

[0067] Optionally, the operation of sending a message carrying the target Unix timestamp to the message broker layer of the distributed message queue includes: setting up an independent time wheel service as a middleware layer, receiving the message carrying the target Unix timestamp sent by the client through the independent time wheel service; the independent time wheel service persistently storing the message and inserting the message into the corresponding time slot of its own time wheel structure according to the target Unix timestamp; the independent time wheel service advancing a third global pointer at a third fixed time interval and scanning all messages in the time slot currently pointed to by the third global pointer, performing local transaction checks in conjunction with a transaction message mechanism during the scanning process; if the target Unix timestamp of a message in the time slot currently pointed to by the third global pointer arrives and the local transaction check passes, then the message is forwarded to the message broker layer.

[0068] In this embodiment of the invention, to meet the business needs of high reliability and complex scheduling scenarios, this application also provides an extension scheme for an independent middleware layer time wheel service. This scheme establishes an independent time wheel service as a middleware layer between the client and the message broker layer, centrally managing the reception, persistent storage, time wheel scheduling, and transaction guarantees of delayed messages. When a message expires, it is forwarded to the message broker layer, thereby decoupling the client and the message broker layer and ensuring eventual consistency of messages through a transaction mechanism.

[0069] refer to Figure 1 The system architecture diagram shown includes an independent middleware layer time wheel service as one of the optional optimization solutions in the extension layer. Figure 6 The scheduling flowchart for the extension layer's independent time wheel service is shown, as follows: Figure 6As shown, this scheme involves three layers: the client layer, the extension layer, and the consumer layer. The client layer contains the client, the extension layer contains an independent time wheel service, and the consumer layer contains the target queue and the consumer. This scheme can be enabled when users have high reliability requirements (e.g., cannot tolerate message loss, require transaction guarantees) and wish to reduce the scheduling pressure on the message broker layer. Specifically, the client no longer sends messages directly to the message broker layer, but instead first sends them to the independent time wheel service, which then performs the following operations: First, a separate time wheel service receives messages from clients carrying the target Unix timestamp. Unlike client-side local time wheel solutions, this service is deployed as a separate middleware layer with independent storage and computing resources, enabling it to handle larger-scale delayed task processing.

[0070] Next, an independent time wheel service persistently stores the received messages to ensure that delayed messages are not lost even in the event of a service restart or an anomaly, laying the foundation for reliable scheduling later. Persistent storage can be implemented using a database, a distributed file system, or the storage engine built into the message queue; this embodiment does not limit this approach.

[0071] Then, an independent time wheel service inserts the message into the corresponding time slot of its own time wheel structure based on the target Unix timestamp in the message. This time wheel structure can be a multi-level time wheel optimized based on Kafka's layered time wheel, supporting efficient task insertion and deletion operations. Similar to the layered circular time wheel of the message broker layer, this time wheel also consists of multiple levels of circular arrays, with the total time span of different levels increasing progressively. The levels are connected through an overflow mechanism to ensure that the time complexity of task scheduling is O(1).

[0072] An independent time wheel service advances the third global pointer at a fixed third time interval and scans all messages within the time slot currently pointed to by the third global pointer. During the scanning process, the service performs local transaction checks in conjunction with the transactional message mechanism. Specifically, when a message within a time slot is scanned, the service does not forward it immediately, but first checks the local transaction status associated with that message. For example, in a distributed transaction scenario, a client might perform local database operations while sending a delayed message; the independent time wheel service needs to ensure that only messages whose local transactions have been successfully committed are forwarded. If the local transaction check fails (e.g., transaction rollback or timeout), the message is discarded or placed in a retry queue.

[0073] If the target Unix timestamp of a message in the time slot currently pointed to by the third global pointer arrives and the local transaction check passes, the independent time wheel service forwards the message to the message broker layer. Upon receiving the message, the message broker layer will perform subsequent processing according to the steps in S204 and S206 described above: storing the message in a delayed queue, inserting it into the hierarchical circular time wheel, and transferring it to a regular queue for consumer consumption upon expiration.

[0074] Through the aforementioned independent middleware layer time wheel service solution, this application achieves the following beneficial effects: Compared to existing technologies (such as pure Broker layer scheduling or client-side local storage), this solution, by introducing an independent service layer, realizes centralized management and persistent storage of delayed tasks, avoiding task loss due to service restarts; combined with the RocketMQ transactional message mechanism, local transaction checks are performed before delayed task scheduling to ensure eventual message consistency, making it suitable for distributed transaction scenarios; through the horizontal scaling capability of the independent service, it can support delayed message processing with higher concurrency, meeting the business needs of highly reliable and complex scheduling scenarios. Therefore, this solution provides another important optimization option for custom delayed message processing, complementing the client-side local time wheel solution and together constituting the complete optimization system of the extension layer of this application.

[0075] Optionally, in the multiple levels of the circular array, the total time span of the levels corresponding to the circular arrays of different levels increases progressively; for a message already stored in the delay queue, if the delay duration of the message exceeds the total time span of the level that the current level can express, then the message is inserted into the corresponding time slot of the target level whose total time span is greater than that of the current level through the overflow mechanism.

[0076] In this embodiment of the invention, in order to achieve task scheduling with arbitrary delay duration under limited storage resources while maintaining O(1) time complexity for insertion and scheduling performance, this application further defines the hierarchical relationship and overflow mechanism of the layered circular time wheel. By setting the total time span of different levels to increase progressively and defining overflow rules between levels, delayed tasks can automatically flow between multiple time wheels, thereby breaking through the time range limitation of a single-layer time wheel.

[0077] refer to Figure 4The diagram illustrates a hierarchical circular time wheel structure, showcasing three levels of circular arrays: a first-level (second-level), a second-level (minute-level), and a third-level (hour-level) circular array. Each level of the circular array has a fixed total time span, with the total time span increasing progressively across different levels. For example, the first level has a 1-second granularity for each time slot, containing 60 time slots, resulting in a total time span of 60 seconds; the second level has a 1-minute granularity for each time slot, also containing 60 time slots, resulting in a total time span of 60 minutes; and the third level has a 1-hour granularity for each time slot, containing 24 time slots, resulting in a total time span of 24 hours. It should be noted that the number of levels and parameters shown in the figure are for illustrative purposes only. In actual applications, more levels (such as daily or monthly levels) and different time slot granularities and number of slots can be set according to business needs, as long as the total time span of different levels increases progressively.

[0078] For messages already stored in the delay queue, when the message broker layer inserts them into the hierarchical circular time wheel based on the target Unix timestamp, it needs to determine the specific level and time slot where the message should be placed. Specifically, the message broker layer first calculates the message's delay duration, which is the difference between the target Unix timestamp and the message broker layer's current system time. If the delay duration is less than or equal to the total time span of the current level (e.g., starting from the first level), the message is directly inserted into the corresponding time slot of the current level; if the delay duration exceeds the total time span of the current level, an overflow mechanism is triggered, and the message is delivered to the next level with a larger total time span for processing.

[0079] by Figure 4Taking the three-tier time wheel as an example, assuming the current system time is t0, and the target Unix timestamp of a certain message is t0 + 3 hours 15 minutes 20 seconds, i.e., the delay is 3 hours 15 minutes 20 seconds. The message broker layer first attempts to insert the message into the first tier (second level), but the total time span of the first tier is only 60 seconds, much less than 3 hours 15 minutes 20 seconds, thus triggering the overflow mechanism and delivering the message to the second tier (minute level). The total time span of the second tier is 60 minutes (i.e., 1 hour), still less than 3 hours 15 minutes 20 seconds, so the overflow mechanism is triggered again, delivering the message to the third tier (hour level). The total time span of the third tier is 24 hours, greater than 3 hours 15 minutes 20 seconds, so the message is finally inserted into the time slot corresponding to the 3-hour interval in the third tier (because the hour part of 3 hours 15 minutes 20 seconds is 3 hours). It's important to note that when inserting a message into the third level, the message broker layer needs to record the minutes and seconds of the message's remaining delay. This is to ensure accurate reconstruction of the original delay time during subsequent backflow from higher to lower levels. This backflow process is essentially a reverse application of the overflow mechanism. When the higher-level pointer advances to a certain time slot, the message in that slot is re-inserted into the corresponding time slot at a lower level based on its remaining delay, until it is finally terminated and transferred by the lowest level (e.g., at the second level).

[0080] Through the aforementioned progressively increasing hierarchical total time span design and overflow mechanism, this application achieves the following beneficial effects: Compared to existing technologies (such as single-layer time wheels that can only support a limited time range), the hierarchical circular time wheel, through multi-layer superposition, can theoretically support arbitrarily large latency ranges. Only the corresponding layers need to be added as required, for example, it can be extended to the daily, monthly, or even yearly level. Simultaneously, since the insertion and scheduling operations at each layer have O(1) time complexity, the overall performance will not decrease with the increase in layers, ensuring efficient scheduling for large-scale delayed tasks. Furthermore, the overflow mechanism allows tasks to automatically flow between layers without manual intervention or complex state management, significantly reducing the complexity of system implementation. Therefore, this solution, through the organic combination of hierarchical architecture design and overflow mechanism, achieves flexible support for arbitrary latency durations under limited storage resources, effectively solving the technical problems of complex scheduling architectures and low storage efficiency in existing technologies.

[0081] Optionally, the operation of transferring the message to be scheduled from the delayed queue to the normal queue includes: locking the state of the message to be scheduled; writing the message to be scheduled from the delayed queue to the normal queue; updating the metadata of the message to be scheduled; and triggering a notification mechanism to notify consumers to pull messages from the normal queue.

[0082] In this embodiment of the invention, in order to ensure that no concurrency conflicts, message loss or duplicate consumption occur during the process of transferring messages from the delayed queue to the normal queue, this application encapsulates the transfer operation in a transactional manner and ensures reliable message delivery through a series of atomic steps. Figure 5 The internal scheduling process of the message broker layer is shown, such as... Figure 5 As shown, when the first global pointer points to a time slot and detects an expired message, a message transfer operation is triggered. This operation specifically includes the following four sub-steps: First, the state of the message to be scheduled is locked. When the message broker layer is preparing to remove a message from the delay queue, it first locks the message, for example, by using a distributed lock or database row lock mechanism, marking the message as "transferring" to avoid conflicts caused by multiple threads or multiple broker nodes operating on the same message simultaneously in concurrent scenarios. For example, in a high-availability deployment mode, if the primary and backup nodes simultaneously detect that the same message has expired, the locking mechanism can ensure that only one node can successfully execute the subsequent transfer operation, thereby preventing the message from being transferred or consumed repeatedly.

[0083] Next, the message to be scheduled is written from the delayed queue to the regular queue. After successfully locking the message status, the message broker layer performs the actual queue transfer operation, that is, removing the message from the delayed queue (the queue that stores messages that have not yet expired) and writing it to the target regular queue (the queue that stores messages that have reached their consumption deadline). This step involves data movement of the underlying storage engine. For example, in RocketMQ, the delayed queue and the regular queue may correspond to different CommitLog files or index structures. The message broker layer completes the reliable migration of data through its internal storage interface, ensuring that the message content is not lost or corrupted.

[0084] Then, the metadata of the message to be scheduled is updated. After the message transfer is complete, the message broker layer needs to update the metadata information related to the message, such as modifying the message's queue offset, updating the message status to "expired" or "consumable," and recording the message's new position in the ordinary queue. Updating metadata is crucial to ensuring the traceability and manageability of messages throughout their entire lifecycle, and also provides a basis for subsequent mechanisms such as message retry and dead-letter handling. In distributed storage systems, metadata updates are typically completed within the same transaction as message write operations to ensure data consistency.

[0085] Finally, a notification mechanism is triggered to instruct consumers to retrieve messages from the regular queue. Once a message has been successfully transferred to the regular queue and its metadata has been updated, the message broker layer needs to proactively or passively notify consumers that new messages are available for consumption. This notification mechanism can take various forms, such as pushing long polling requests to consumers, updating the offset information for consumers to retrieve services, or broadcasting queue status change events. Upon receiving the notification, consumers can retrieve the message from the regular queue for business processing. A timely notification mechanism effectively reduces invalid requests from consumers due to polling, lowering overall system latency.

[0086] It should be noted that the above four steps are usually designed as atomic operations or transaction units in the internal implementation of the message broker layer. They rely on RocketMQ's built-in storage engine and high availability mechanism to ensure that even if the system crashes or restarts abnormally, the final state of the message transfer is consistent: either the transfer is successful and visible to the consumer, or the transfer fails and the message is still kept in the delayed queue waiting for rescheduling.

[0087] Through the aforementioned transactional message transfer mechanism, this application achieves the following beneficial effects: compared to existing technologies (such as simple queue transfer which may result in message loss or duplication), it avoids concurrent conflicts by locking the state, ensures data integrity and traceability by writing to ordinary queues and updating metadata, and improves the real-time performance of consumption by triggering a notification mechanism. Therefore, this solution significantly improves the reliability and consistency of the message scheduling process, reduces the risk of delivery failure, and enhances the overall stability of the system.

[0088] Optionally, the client and the message broker layer calibrate their respective system times through a clock synchronization protocol, which includes the NTP protocol or the PTP protocol.

[0089] In this embodiment of the invention, to ensure the accuracy of delayed message scheduling and avoid premature or delayed message delivery due to time discrepancies between the client and the message broker layer, this application further defines the system time synchronization mechanism. Since the core of this technical solution relies on the consistency between the target Unix timestamp calculated by the client and the current system time used by the message broker layer to determine whether a message is due, any time discrepancy can cause scheduling errors. Therefore, clock synchronization is the fundamental guarantee for achieving reliable delayed message scheduling.

[0090] In distributed system environments, the system times of different machines often drift to some extent, especially in long-running scenarios, where this time discrepancy can accumulate to the second or even minute level. For example, if the client's system time is 5 seconds ahead of the message broker layer's system time, the target Unix timestamp calculated by the client will be 5 seconds earlier than the actual expected delivery time. When a message arrives at the message broker layer, the broker layer, based on its own system time, determines whether the message is due, but in reality, it needs to wait 5 seconds longer than expected before transferring the message to the regular queue, resulting in delayed message delivery. Conversely, if the client's system time is slower than the message broker layer's, the message may be delivered prematurely. This time discrepancy is unacceptable for business scenarios requiring precise time triggering (such as scheduled tasks, flash sales, etc.).

[0091] To address the aforementioned issues, this application introduces a clock synchronization mechanism, requiring the client and message broker layer to calibrate their respective system times using a standard clock synchronization protocol. Specifically, this application supports the following two protocols: The first protocol is NTP (Network Time Protocol). NTP is a widely used time synchronization protocol on the Internet, capable of synchronizing device time to UTC (Coordinated Universal Time) standard time through a layered time server architecture. In actual deployment, the client and message broker layer can be configured to synchronize time from the same group of NTP servers, or through a hierarchical synchronization method (such as the message broker layer synchronizing from an external NTP server, and the client synchronizing from the message broker layer), ensuring that all nodes in the entire system have a consistent time base. The NTP protocol can typically synchronize the time of devices within a local area network to millisecond precision, and in a wide area network environment, it can achieve precision of tens of milliseconds, which is sufficient to meet the scheduling requirements of the default second-level precision in this application.

[0092] The second protocol is the PTP (Precision Time Protocol). PTP is a higher-precision time synchronization protocol, mainly used in local area network environments. It can improve the time synchronization accuracy between devices to sub-microsecond or even nanosecond levels through hardware timestamps and master-slave clock synchronization mechanisms. For business scenarios requiring millisecond or even microsecond-level high-precision scheduling (such as high-frequency trading, real-time data processing, etc.), this application can use the PTP protocol for time synchronization to ensure that the time deviation between the client and the message broker layer is extremely small, thereby supporting finer-grained time slot settings (such as millisecond-level time slot granularity).

[0093] refer to Figure 1The system architecture diagram shown does not explicitly depict a clock synchronization module. However, in actual deployment, the client layer and message broker layer can connect to an external NTP server or PTP master clock, respectively, to calibrate their system time through a periodic synchronization mechanism. Furthermore, in... Figure 7 The system architecture and data flow diagram shown implies a requirement for time consistency in the connection between the client layer and the message broker layer. The clock synchronization mechanism is the infrastructure that ensures this requirement.

[0094] It's important to note that the specific implementation of clock synchronization can be flexibly chosen based on the deployment environment and accuracy requirements. For example, in a cloud-native environment, a containerized NTP client can automatically synchronize the host machine time; in a physical machine deployment scenario, a system-level time synchronization service can be configured. Regardless of the specific implementation used, the core objective is to ensure that the current system time used by the client to calculate the target Unix timestamp maintains the smallest possible time deviation from the current system time used by the message broker layer to determine message expiration. Typically, this deviation is required to be less than the minimum advance interval of the time wheel (e.g., 1 second or 100 milliseconds).

[0095] Through the aforementioned clock synchronization mechanism, this application achieves the following beneficial effects: Compared to existing technologies (such as those that do not explicitly handle clock drift), calibrating the time deviation between the client and server via NTP or PTP protocols effectively avoids scheduling errors caused by clock inconsistencies, ensuring that messages are delivered at the precise time expected by the user. Simultaneously, the default second-level scheduling accuracy can be further improved by optimizing the time wheel advance interval and adopting the PTP protocol, meeting the business needs of high-precision scenarios. Therefore, this solution provides a reliable time foundation for the timely delivery of custom delayed messages.

[0096] Optionally, the method further includes: monitoring the task backlog in the hierarchical circular time wheel, determining the degree of task backlog in the hierarchical circular time wheel; and dynamically adjusting the hierarchical structure or time slot granularity of the hierarchical circular time wheel according to the degree of backlog.

[0097] In this embodiment of the invention, to address potential performance bottlenecks in high-concurrency scenarios and ensure efficient scheduling of the hierarchical circular time wheel under different load conditions, this application introduces a task backlog monitoring and dynamic adjustment mechanism. By monitoring the task backlog at each level of the time wheel in real time and dynamically adjusting the hierarchical structure or time slot granularity of the time wheel according to the backlog level, adaptive optimization of the system can be achieved, avoiding scheduling delays or resource exhaustion caused by task accumulation.

[0098] refer to Figure 7The system architecture and data flow diagram shown does not explicitly display the monitoring module. However, in actual deployment, a separate monitoring component can be deployed inside or around the message broker layer to collect the operational status data of the hierarchical ring time wheel. This monitoring component collects the following metrics at fixed time intervals (e.g., every minute or every second): the number of messages currently awaiting scheduling in each level's time slot, the average waiting time for tasks at each level, the time taken for the time wheel pointer to advance, and the system resource usage (e.g., CPU, memory). Through comprehensive analysis of these metrics, the current task backlog can be quantified.

[0099] Determining the degree of task backlog can employ various strategies. For example, a threshold can be set for each level; when the number of messages to be scheduled in a certain level exceeds a preset upper limit, it is determined that there is a backlog at that level. Alternatively, when the average waiting time of a task exceeds several times the time slot granularity, scheduling performance is determined to have degraded. In this application, the degree of backlog can be divided into multiple levels (such as mild, moderate, and severe), with different adjustment strategies triggered for different levels.

[0100] Based on the determined backlog level, the system dynamically adjusts one of the following parameters of the layered annular time wheel: The first adjustment method is to adjust the hierarchical structure. Adjusting the hierarchical structure includes increasing or decreasing the number of time wheel levels, or adjusting the total time span of each level. For example, when monitoring reveals that a large number of delayed tasks are concentrated in the hourly or daily range, causing a severe backlog of tasks in the third level (hourly level), the system can add a fourth level (daily level) above the third level to divert ultra-long delayed tasks to higher levels, thereby reducing the burden on the third level. Similarly, when it is found that the task load in a certain level is consistently low, the system can merge that level with adjacent levels, simplifying the time wheel structure to reduce memory overhead. Adjusting the hierarchical structure requires recalculating the distribution of tasks across levels, but thanks to the O(1) insertion characteristic of the time wheel, this adjustment can be performed online during system operation without downtime.

[0101] The second adjustment method involves adjusting the time slot granularity. Adjusting the time slot granularity includes refining or coarsening the granularity of a specific level. For example, when monitoring reveals a severe backlog of tasks at the first level (second-level), and the latency of most tasks is concentrated within the second range, the system can refine the time slot granularity of the first level from 1 second to 100 milliseconds. This distributes tasks within the same time slot across multiple slots with finer granularity, reducing the number of tasks in a single slot and improving scanning efficiency. Conversely, if the number of tasks at a certain level is small, but the time slot granularity is too fine, leading to memory waste, the system can coarsen the time slot granularity (e.g., adjusting it from 100 milliseconds to 1 second) to save resources. Adjusting the time slot granularity also needs to consider the cost of task redistribution, but due to the hierarchical nature of the time wheel, this adjustment can usually be limited to a specific level.

[0102] It's important to note that the implementation of the dynamic adjustment mechanism needs to be tailored to specific business scenarios and system resource conditions. For example, during periods of high concurrency peaks, the system may prioritize increasing the number of layers or refining the granularity to improve processing capacity; during periods of low load, the granularity can be appropriately coarsened or layers merged to conserve resources. Adjustment decisions can be executed automatically by a pre-defined rule engine or manually triggered by operations personnel through a management interface. Regardless of the method used, the core objective is to prevent performance bottlenecks through adaptive optimization and ensure stable system operation under various load conditions.

[0103] Through the aforementioned task backlog monitoring and dynamic adjustment mechanism, this application achieves the following beneficial effects: Compared to existing technologies (such as statically configured time wheel structures that cannot adapt to load changes), by monitoring the backlog in real time and dynamically adjusting the hierarchical structure or time slot granularity, this solution can effectively address performance challenges in high-concurrency scenarios and avoid message scheduling delays or loss. Simultaneously, the adaptive optimization mechanism improves the system's resource utilization and scalability, enabling the hierarchical circular time wheel to dynamically match processing capabilities according to the actual load, thereby reducing unnecessary resource overhead while ensuring scheduling performance. Therefore, this solution further solves the technical problems of insufficient scalability of time wheel algorithms in high-concurrency scenarios and the tendency to cause message scheduling delays or loss in existing technologies.

[0104] In summary, the embodiments of this method have the following beneficial effects: (1) Supports arbitrary delay duration and has high scheduling efficiency: This application adopts a multi-level ring array structure to construct a hierarchical ring time wheel. Each level has a progressively increasing total time span, and the levels are connected through an overflow mechanism, breaking through the time range limitation of a single-level time wheel. At the same time, task insertion and scheduling can be completed in O(1) time complexity, avoiding the high overhead of traditional scanning algorithms. Compared with existing technologies (such as the fixed delay level mechanism of RocketMQ 4.x), this application not only supports users to specify arbitrary delay duration, but also significantly improves system throughput and scalability, and reduces resource consumption.

[0105] (2) Support for delayed messages with arbitrary timestamps: This application calculates the target Unix timestamp at the client layer based on the current system time and any user-specified delay duration, writes it to the message attributes or calls a dedicated API, and performs timestamp validity verification before sending. Compared with existing technologies (such as RocketMQ 4.x's delayTimeLevel attribute, which only supports fixed levels), this application provides flexible time delay settings to meet diverse business needs, while reducing user errors in manual calculation through API encapsulation.

[0106] (3) Transactional message transfer mechanism: This application performs transactional transfer operations on expired messages at the message broker layer, including locking the message status, writing the message from the delayed queue to the ordinary queue, updating metadata, and triggering the notification mechanism. Compared with existing technologies (such as simple queue transfer which may result in message loss), this application ensures the reliability and consistency of messages through a transactional mechanism, reduces the risk of delivery failure, and improves system stability.

[0107] (4) Layered architecture design: This application adopts a layered architecture consisting of a client layer, a message broker layer, and an extension layer. Each layer works together through standardized interfaces. Compared with existing technologies (such as single-module design), the layered structure achieves modularity, facilitates expansion and maintenance, and improves the system's flexibility and customizability.

[0108] (5) Extension Layer Optimization Scheme: This application provides two optimization schemes in the extension layer: client-side local time wheel and independent middleware layer time wheel service. Compared with existing technologies (such as pure Broker layer scheduling), the client-side local time wheel is suitable for low-latency and high-precision scenarios, reducing network latency and improving response speed through local temporary storage; the independent middleware layer time wheel service is suitable for high-concurrency and high-reliability scenarios, ensuring eventual consistency through persistent storage and transactional message mechanisms.

[0109] (6) Clock synchronization mechanism: This application uses the NTP or PTP protocol to calibrate the time deviation between the client and the message broker layer. Compared with the prior art (such as not explicitly handling clock drift), this application reduces the scheduling error caused by time inconsistency. The default accuracy is about 1 second, which can be further improved by configuration, thereby improving the accuracy of message delivery.

[0110] (7) Maximum latency range handling: For ultra-long latency requirements that exceed the maximum latency range supported by the hierarchical ring time wheel (e.g., 40 days), this application handles the scheduling at the application layer through message splitting or external persistent storage. Compared with existing technologies (e.g., fixed time wheels cannot handle ultra-long latency), this application effectively manages long latency scenarios and avoids system resource bottlenecks through hierarchical overflow and application layer extension.

[0111] System Implementation Examples This embodiment provides a custom time-delayed message processing system based on a distributed message queue, including: a client layer, used to receive any delay duration specified by the user, calculate a target Unix timestamp based on the client's current system time and the arbitrary delay duration, and send a message carrying the target Unix timestamp to a message broker layer; the message broker layer includes: a delay queue, used to store the received messages; and a hierarchical circular time wheel, composed of multiple levels of circular arrays, each level of the circular array being divided into several time slots, each time slot corresponding to a fixed time slot granularity, with the granularity of time slots within the same level being the same; and... Each level of the circular array corresponds to a fixed total time span for the level, and the levels are connected through an overflow mechanism. The message insertion module is used to insert the message into the corresponding time slot of the hierarchical circular time wheel according to the target Unix timestamp. The message transfer module is used to advance the first global pointer at a first fixed time interval. When the first global pointer points to a time slot of the hierarchical circular time wheel, it scans all the messages to be scheduled in the time slot. If the target Unix timestamp of a message to be scheduled is less than or equal to the current system time of the message broker layer, the message to be scheduled is transferred from the delayed queue to the ordinary queue for consumption by the consumer.

[0112] It should be noted that the custom time-delay message processing system based on a distributed message queue provided in this embodiment can implement all the functions and steps in the above method embodiments, solve the same technical problems, and achieve the same technical effects. The similarities will not be repeated here.

[0113] Therefore, according to this embodiment, by organically combining the hierarchical ring time wheel scheduling mechanism, arbitrary timestamp support, transactional message transfer, hierarchical architecture design and extension layer optimization scheme, efficient, reliable and flexible custom delayed message processing is achieved. This effectively solves the technical problems of traditional message queue delayed message processing methods that cannot support user-defined arbitrary delay duration, have maximum delay time limits, and have complex scheduling architectures and insufficient scalability in high-concurrency scenarios.

[0114] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

[0116] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Furthermore, the above descriptions are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A custom time-delay message processing method based on a distributed message queue, characterized in that, include: The client receives any delay duration specified by the user, calculates the target Unix timestamp based on the client's current system time and the arbitrary delay duration, and sends the message carrying the target Unix timestamp to the message broker layer of the distributed message queue. The message broker layer stores the received message into a delay queue and inserts the message into the corresponding time slot of the hierarchical circular time wheel according to the target Unix timestamp; The hierarchical ring time wheel consists of multiple levels of ring arrays. Each level of the ring array is divided into several time slots, and each time slot corresponds to a fixed time slot granularity. The granularity of each time slot within the same level is the same. Furthermore, each level of the ring array corresponds to a fixed total time span of the level, and the levels are connected through an overflow mechanism. The message broker layer advances the first global pointer at a first fixed time interval. When the first global pointer points to a time slot of the hierarchical circular time wheel, it scans all the messages to be scheduled in the time slot. If the target Unix timestamp of a message to be scheduled is less than or equal to the current system time of the message broker layer, the message to be scheduled is transferred from the delayed queue to the ordinary queue for consumption by consumers.

2. The method according to claim 1, characterized in that, Before sending the message carrying the target Unix timestamp to the message broker layer of the distributed message queue, the operation also includes: Verify whether the target Unix timestamp is valid, the verification includes determining whether the target Unix timestamp exceeds a preset maximum delay range or is a negative value; If the verification fails, the exception handling mechanism will be triggered.

3. The method according to claim 2, characterized in that, Also includes: When the arbitrary delay duration specified by the user causes the calculated target Unix timestamp to exceed the maximum delay range supported by the hierarchical ring time wheel, the following scheduling processing is performed on the message carrying the target Unix timestamp at the application layer: The message is split into multiple consecutive sub-messages, the sum of the delay durations of each sub-message is equal to the arbitrary delay duration, and each sub-message is submitted to the message broker layer for execution in sequence; or The message is stored in an external persistent storage, and the external scheduling system re-delivers the message to the message broker layer at a time point that is a preset time away from the target Unix timestamp.

4. The method according to claim 1, characterized in that, The operation of sending a message carrying the target Unix timestamp to the message broker layer of the distributed message queue includes: A local time wheel component is introduced in the client, which advances at a fixed time slot granularity; The message and its corresponding target Unix timestamp are encapsulated into a delayed task, and the delayed task is inserted into the corresponding time slot of the local time wheel component; The local time wheel component advances the second global pointer at a second fixed time interval and scans all delayed tasks within the time slot currently pointed to by the second global pointer; If the target Unix timestamp of a delayed task in the time slot currently pointed to by the second global pointer arrives, the delayed task is executed, and a message carrying the target Unix timestamp is sent to the message broker layer.

5. The method according to claim 1, characterized in that, The operation of sending a message carrying the target Unix timestamp to the message broker layer of the distributed message queue includes: An independent time wheel service is set up as a middleware layer to receive messages sent by the client carrying the target Unix timestamp. The independent time wheel service persists the message and inserts it into the corresponding time slot of its own time wheel structure according to the target Unix timestamp; The independent time wheel service advances the third global pointer at a third fixed time interval and scans all messages in the time slot currently pointed to by the third global pointer. During the scanning process, a local transaction check is performed in conjunction with the transaction message mechanism. If the target Unix timestamp of a message in the time slot currently pointed to by the third global pointer arrives and the local transaction check passes, then the message is forwarded to the message broker layer.

6. The method according to claim 1, characterized in that, In the multiple levels of the circular array, the total time span of the levels corresponding to the circular arrays of different levels increases progressively. For a message that has been stored in the delay queue, if the delay duration of the message exceeds the total time span of the current level, the message is inserted into the corresponding time slot of the target level whose total time span is greater than that of the current level through the overflow mechanism.

7. The method according to claim 1, characterized in that, The operation of transferring the message to be scheduled from the delayed queue to the normal queue includes: Lock the status of the message to be scheduled; Write the message to be scheduled from the delay queue to the regular queue; Update the metadata of the message to be scheduled; Trigger a notification mechanism to notify consumers to retrieve messages from the regular queue.

8. The method according to claim 1, characterized in that, The client and the message broker layer calibrate their respective system times through a clock synchronization protocol, which includes the NTP protocol or the PTP protocol.

9. The method according to claim 1, characterized in that, Also includes: Monitor the task backlog in the hierarchical circular time wheel and determine the degree of task backlog in the hierarchical circular time wheel; The hierarchical structure or time slot granularity of the layered annular time wheel is dynamically adjusted according to the degree of accumulation.

10. A custom time-delay message processing system based on a distributed message queue, characterized in that, include: The client layer is used to receive any delay duration specified by the user, calculate the target Unix timestamp based on the client's current system time and the arbitrary delay duration, and send the message carrying the target Unix timestamp to the message broker layer. The message broker layer includes: A delay queue is used to store the received messages; The hierarchical circular time wheel consists of multiple levels of circular arrays. Each level of the circular array is divided into several time slots, and each time slot corresponds to a fixed time slot granularity. The granularity of each time slot within the same level is the same. Furthermore, each level of the circular array corresponds to a fixed total time span for the level, and the levels are connected through an overflow mechanism. The message insertion module is used to insert the message into the corresponding time slot of the hierarchical circular time wheel according to the target Unix timestamp; The message transfer module is used to advance the first global pointer at a first fixed time interval. When the first global pointer points to a time slot of the hierarchical circular time wheel, it scans all the messages to be scheduled in the time slot. If the target Unix timestamp of a message to be scheduled is less than or equal to the current system time of the message broker layer, the message to be scheduled is transferred from the delayed queue to the ordinary queue for consumption by consumers.

Images