Method, device, computer readable medium and electronic device for implementing a delay queue

Abstract

Embodiments of the present application provide a method, device, computer readable medium and electronic device for implementing a delay queue, the method comprising: after receiving task information of a delay task submitted by a client, storing task identification information and an expiration time in a database; scanning the database to put task identification information of expired delay tasks in the database into a ready queue; taking out the task identification information and putting it into a running queue, and delivering task information corresponding to the task identification information to the client, so that the client processes the delay task corresponding to the task information; and if no confirmation message corresponding to the task information is received from the client, re-storing task identification information corresponding to the task information in the running queue in the database to re-attempt to process the delay task. Embodiments of the present application are based on a message queue, which can prevent loss of delay messages and ensure data reliability.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and more specifically, to a method, apparatus, computer-readable medium, and electronic device for implementing a delayed queue. Background Technology

[0002] Delayed queues are message queues with a delay function. With the rapid development of Internet services, delayed queues have been widely used.

[0003] However, existing delayed queues may experience data loss when delivering delayed messages, resulting in poor data reliability. Summary of the Invention

[0004] Embodiments of this application provide a method, apparatus, computer-readable medium, and electronic device for implementing a delayed queue, which can at least to some extent prevent the loss of delayed messages and ensure data reliability.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to one aspect of the embodiments of this application, a method for implementing a delayed queue is provided. The method includes: after receiving task information of a delayed task submitted by a client, storing the task identifier information and expiration time of the delayed task in a database; scanning the database to place the task identifier information of the delayed tasks that have expired in the database into a ready queue according to the expiration time; retrieving the task identifier information from the ready queue and placing it into a running queue, and delivering the task information corresponding to the task identifier information to the client so that the client can process the delayed task corresponding to the task information; if no confirmation message corresponding to the task information is received from the client, then re-storing the task identifier information corresponding to the task information in the running queue into the database to retry processing the delayed task corresponding to the task information, wherein the confirmation message is used to indicate that the client has completed processing the corresponding delayed task.

[0007] According to one aspect of the embodiments of this application, an apparatus for implementing a delayed queue is provided. The apparatus includes: a storage unit, configured to store the task identifier information and expiration time of the delayed task in a database after receiving task information of a delayed task submitted by a client; a scanning unit, configured to scan the database to place the task identifier information of the delayed tasks that have expired in the database into a ready queue according to the expiration time; an extraction and delivery unit, configured to extract the task identifier information from the ready queue and place it into a running queue, and deliver the task information corresponding to the task identifier information to the client so that the client can process the delayed task corresponding to the task information; and a retry unit, configured to, if no confirmation message corresponding to the task information is received from the client, re-store the task identifier information corresponding to the task information in the running queue into the database to retry processing the delayed task corresponding to the task information, wherein the confirmation message is used to indicate that the client has completed processing the corresponding delayed task.

[0008] In some embodiments of this application, based on the foregoing scheme, the retry unit is configured to: determine a new expiration time based on the current time, and re-store the task identifier information corresponding to the task information in the running queue and the new expiration time into the database, so that if no confirmation message corresponding to the task information is received from the client after the new expiration time is reached, the task identifier information is retrieved from the database and placed into the ready queue to retry processing the delayed task corresponding to the task information.

[0009] In some embodiments of this application, based on the foregoing scheme, the retry unit is configured to: if no confirmation message corresponding to the task information is received from the client and the number of retries for the task information does not reach a preset threshold, then the task identifier information corresponding to the task information in the running queue is re-stored into the database.

[0010] In some embodiments of this application, based on the foregoing scheme, after retrieving the task identifier information from the ready queue and placing it into the running queue, the retry unit is further configured to: if an acknowledgment message corresponding to the task information is received from the client, retrieve the task identifier information corresponding to the task information from the running queue and discard it; if no acknowledgment message corresponding to the task information is received from the client and the number of retries for the task information reaches a preset threshold, place the task identifier information into a dead-letter queue, wherein the dead-letter queue is used to store the task identifier information of delayed tasks for which the client has not yet returned an acknowledgment message when the number of retries reaches the preset threshold.

[0011] In some embodiments of this application, based on the foregoing scheme, the storage unit is configured to store the task identifier information and expiration time of the delayed task as bucket elements in the bucket group into the database, so as to store the bucket group through the database, wherein the bucket group includes multiple buckets.

[0012] In some embodiments of this application, based on the foregoing scheme, the scanning unit is configured to scan the corresponding buckets in the bucket group through the thread corresponding to each bucket, so as to put the task identification information of the delayed tasks that have expired in each bucket into the ready queue according to the expiration time.

[0013] In some embodiments of this application, based on the foregoing scheme, before delivering the task information corresponding to the task identifier information to the client, the extraction and delivery unit is further configured to: receive a long polling request initiated by the client and suspend the long polling request; if it is confirmed within a predetermined time period after receiving the long polling request that there is no task identifier information in the ready queue, return an empty result to the client so that the client can re-initiate the long polling request after receiving the empty result; the extraction and delivery unit is configured to: if it is confirmed within a predetermined time period after receiving the long polling request that there is task identifier information in the ready queue, then deliver the task information corresponding to the task identifier information to the client.

[0014] In some embodiments of this application, based on the foregoing scheme, the scanning unit is configured to: place the task identifier information of the expired delayed task in the database into a ready queue corresponding to the type of the delayed task according to the expiration time; the extraction and delivery unit is configured to: retrieve the task identifier information from the ready queue corresponding to the type of the delayed task and place it into a running queue corresponding to the type of the delayed task.

[0015] In some embodiments of this application, based on the foregoing scheme, the storage unit is configured to: use the task identifier information of the delayed task as an element, use the expiration time of the delayed task as the score associated with the element, and store the element and the score associated with the element in an ordered set of the database accordingly; the scanning unit is configured to: filter out elements in the ordered set of the database whose associated scores are within a specified score range to obtain the task identifier information of the delayed tasks that have expired in the database, and put the task identifier information into the ready queue.

[0016] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method for implementing a delay queue as described in the above embodiments.

[0017] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the delay queue implementation method as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions, causing the computer device to perform the delayed queue implementation method as described in the above embodiments.

[0019] In some embodiments of this application, after the task information corresponding to the task identifier information is delivered to the client, if no confirmation message corresponding to the task information is received from the client, that is, if the client has not properly processed the corresponding delayed task, the task identifier information corresponding to the task information in the running queue will be re-stored into the database. This allows the client to retry processing the delayed task corresponding to the task information, preventing message loss due to client crash or processing failure after message delivery and ensuring data reliability.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0022] Figure 1 A schematic diagram illustrating the principle of delay queues in related technologies is shown;

[0023] Figure 2 A schematic diagram of an exemplary system architecture that can implement the technical solutions of the embodiments of this application is shown;

[0024] Figure 3 A flowchart illustrating an implementation method of a delay queue according to an embodiment of this application is shown;

[0025] Figure 4 A schematic diagram of the overall architecture of a delay queue according to an embodiment of this application is shown;

[0026] Figure 5 An embodiment according to this application is shown. Figure 3 A flowchart detailing step 310 is provided.

[0027] Figure 6 An embodiment according to this application is shown. Figure 3 Flowcharts detailing steps 310 and 320;

[0028] Figure 7 A schematic diagram of a bucket assembly according to an embodiment of this application is shown;

[0029] Figure 8 An embodiment according to this application is shown. Figure 5 A flowchart detailing step 320 is provided.

[0030] Figure 9 A schematic diagram illustrating the principle of a client performing long polling on a delayed queue according to an embodiment of this application is shown;

[0031] Figure 10 A schematic diagram summarizing the technologies employed to achieve message timeliness according to an embodiment of this application is shown;

[0032] Figure 11A An embodiment according to this application is shown. Figure 3 A flowchart detailing step 340 is provided.

[0033] Figure 11B Another embodiment according to this application is shown. Figure 3 A flowchart detailing step 340 is provided.

[0034] Figure 12 A schematic diagram illustrating the principle of implementing data reliability according to an embodiment of this application is shown;

[0035] Figure 13 A schematic diagram illustrating the effect of a solution according to an embodiment of this application on message timeliness is shown.

[0036] Figure 14 A block diagram of an implementation apparatus for a delay queue according to an embodiment of this application is shown;

[0037] Figure 15 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0038] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0039] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0040] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0041] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0042] Currently, there are two main delay queue schemes in related technologies:

[0043] Option 1: RocketMQ is an open-source message queue that also provides delayed message functionality. Its main principle is a Timer + queue. Each delay duration corresponds to one Timer and one queue. Messages with the same delay duration are placed in the same queue. Therefore, messages in each queue are sorted by their due date, from earliest to latest. Since different delay durations correspond to different Timers and queues, arbitrary delays cannot be specified. It only supports 18 fixed delay durations: 1 second, 5 seconds, 10 seconds...2 hours. The maximum supported delay is two hours.

[0044] Option 2: TDMQ uses a time wheel plus queue approach, storing delayed messages in high-level physical topics. The index of the delayed message and the original message are stored in different topics. Only the message ID is moved in the time wheel, and the message content does not move with the time wheel.

[0045] Figure 1A schematic diagram illustrating the principle of delay queues in related technologies is shown. Please refer to [link / reference]. Figure 1 As shown, TDMQ can include the following processes:

[0046] 1. When the producer sends a message to the broker node, the server determines that it is a delayed message and sends the delayed message to day-delay-topic-x, and sends the message index (messageId) to the index topic of the corresponding time.

[0047] 2. The delayed message index is divided into days, hours, and minutes. The current minute index is loaded into memory and placed into the memory time wheel. The executor reads the message ID of the current second, pulls the delayed message from day-delay-topic-x, and delivers it to the original business topic.

[0048] 3. Delayed messages are split into different topics by day. This ensures that data with the same delay time is in the same delayed topic, which facilitates data cleanup of delayed messages (the delayed topic for that day can be deleted after all delayed messages for that day have been processed).

[0049] However, both of the above delay queue schemes have certain drawbacks:

[0050] 1. RocketMQ's delayed messages only support 18 fixed durations: 1s, 5s, 10s...2h. The maximum delay is only two hours. It cannot specify arbitrary durations, resulting in poor flexibility.

[0051] 2. TDMQ has a maximum latency of 10 days and cannot support messages with a latency of more than 10 days.

[0052] In addition, other delayed queue solutions also suffer from poor message real-time performance and the possibility of message loss, resulting in poor data reliability.

[0053] To address this, this application first provides a method for implementing a delayed queue. The delayed queue implementation method provided by the embodiments of this application can overcome the aforementioned deficiencies, not only supporting delays of arbitrary lengths and improving the flexibility of the delayed queue, but also improving message real-time performance and further ensuring data reliability.

[0054] Figure 2 A schematic diagram of an exemplary system architecture that can implement the technical solutions of the embodiments of this application is shown. Please refer to... Figure 2As shown, the system architecture 200 may include: a delayed queue server 210, an e-commerce platform server 220, and multiple user terminals. Specifically, the multiple user terminals include a first user terminal 231, a second user terminal 232, and a third user terminal 233. Communication connections are established between each user terminal and the e-commerce platform server 220, as well as between the delayed queue server 210 and the e-commerce platform server 220. Each user terminal runs an e-commerce platform client. The e-commerce platform server 220 deploys an e-commerce platform server, which also embeds a delayed queue client SDK. The delayed queue server 210 deploys a delayed queue server. Taking the delayed queue server 210 as the execution terminal in this embodiment as an example, when the delayed queue implementation method provided in this application is applied... Figure 2 In the system architecture shown, a process can be as follows: First, a user on a user terminal accesses the e-commerce platform server in e-commerce platform server 220 through the e-commerce platform client on the user terminal, thereby submitting an order for a certain product to the e-commerce platform, but without placing an order or making payment. E-commerce platform server 220 sends a message corresponding to the order to the delayed queue server in the delayed queue client SDK embedded in the e-commerce platform server, specifying a delay duration for the message. When the message expires, the delayed queue server returns the message to the delayed queue client SDK, and the e-commerce platform server can then process the message. If the user still has not placed an order or made payment at this point, the e-commerce platform server can cancel the order. Throughout the entire process, the delayed queue server delivers the message to the delayed queue client SDK in a timely and reliable manner.

[0055] In some embodiments of this application, the delayed queue server includes a task pool, a database, a ready queue, a running queue, a dead-letter queue, and multiple scanning threads.

[0056] In some embodiments of this application, the delay duration specified for the message corresponding to the order is 30 minutes.

[0057] It should be understood that Figure 2 The number of delayed queue servers, e-commerce platform servers, and user terminals shown in the diagram is merely illustrative. Depending on implementation needs, there can be any number of delayed queue servers, e-commerce platform servers, and user terminals. For example, the delayed queue servers and / or e-commerce platform servers can be a server cluster consisting of multiple servers, and the number of user terminals can be less than three or more than three.

[0058] It should be noted that, Figure 2 The illustration shown is merely one embodiment of this application. Although in Figure 2In the embodiment of this solution, the solution is applied to an e-commerce platform, but in other embodiments of this application, it can also be applied to various other network service platforms; although in Figure 2 In the embodiment of the solution, this solution is specifically applied to the scenario where orders are automatically canceled due to overdue payment. However, in other embodiments of this application, it can also be applied to other scenarios on e-commerce platforms, such as scenarios where products are automatically delisted or automatically given a five-star review if no review is given within seven days of receiving the product. Although in Figure 2 In the embodiment, the delayed queue server provides services to only one delayed queue client. However, in other embodiments of this application, the delayed queue server can act as a centralized server, simultaneously providing services to multiple delayed queue clients, and each delayed queue client can be applied to different platforms or scenarios. Figure 2 In the embodiments described, both the delayed queue client and the delayed queue server are deployed on a server. However, in other embodiments of this application, the delayed queue client and the delayed queue server may also be deployed on other types of terminal devices such as in-vehicle terminals, smartphones, and desktop computers. This application does not limit the scope of protection in any way, nor should it restrict the scope of protection of this application.

[0059] It is easy to understand that the delayed queue implementation method provided in the embodiments of this application is generally executed by a server, and correspondingly, the delayed queue implementation device is generally located in the server. However, in other embodiments of this application, the terminal device may also have similar functions to the server, thereby executing the delayed queue implementation scheme provided in the embodiments of this application.

[0060] Therefore, the solutions in this application can be applied to terminals or servers. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0061] The solutions in this application can be applied to the field of cloud computing. Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go.

[0062] As a provider of fundamental cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called an IaaS (Infrastructure as a Service) platform) is established. Various types of virtual resources are deployed in the resource pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0063] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS (Infrastructure as a Service) layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0064] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0065] Figure 3 A flowchart illustrating an implementation method of a delayed queue according to an embodiment of this application is shown. This delayed queue implementation method can be executed by various computing and processing devices, such as user terminals or cloud servers. User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, wearable devices, etc. Embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving. Please refer to... Figure 3 As shown, the implementation method of this delay queue includes at least the following steps:

[0066] In step 310, after receiving the task information of the delayed task submitted by the client, the task identifier information and expiration time of the delayed task are stored in the database.

[0067] The task information (job message) of a delayed task is the delayed message, and the client is the submitter of the delayed message. In e-commerce scenarios, the task information of a delayed task may include order-related information such as the order number.

[0068] The task identifier for a delayed task can be a string containing letters, numbers, and other elements. This identifier can be generated by the client and submitted to the delayed queue server, or it can be generated by the delayed queue server based on the task information submitted by the client. It's easy to understand that both the task identifier and the task information correspond to the delayed task.

[0069] When submitting task information for a delayed task, the client can also specify the delay time. The delay queue server can calculate the expiration time of the delayed task using the formula "expiration time = current time + delay time". Alternatively, in other embodiments of this application, the client can directly specify the expiration time of the delayed task to the delay queue server.

[0070] The database can be a non-relational database, such as Redis (Remote Dictionary Server).

[0071] The following is combined Figure 4 The solution of this application embodiment is further described below. The delayed queue server is the delayed queue. Figure 4 A schematic diagram of the overall architecture of a delay queue according to an embodiment of this application is shown. See also... Figure 4 As shown, the delay queue specifically includes several sub-modules such as the Job Pool, Buckets, Ready Queue, Running Queue, and Dead Letter Queue, as well as several scanning threads such as Timer, Poller, and Cleaner.

[0072] After receiving the task information of the delayed task submitted by the client, the task information is stored in the task pool. Specifically, the task identifier information (jobId) can be used as the key and the serialized task information as the value, and the key-value pair can be stored using the Redis string data structure.

[0073] Figure 5 An embodiment according to this application is shown. Figure 3 A flowchart detailing step 310 is provided. Please refer to [link / reference]. Figure 5 As shown, storing the task identifier information and expiration time of a delayed task in the database may specifically include the following steps:

[0074] In step 310', the task identifier information and expiration time of the delayed task are stored in the database as bucket elements of the bucket group, so as to store the bucket group through the database.

[0075] A bucket group consists of multiple buckets.

[0076] Please continue reading Figure 4 As shown, buckets can be stored using a Redis database. A bucket group consists of multiple buckets, and each element in a bucket is called a bucket item. Each bucket item can include the task identifier information and expiration time of a delayed task. Each bucket can contain multiple bucket items. After storing the bucket items in the Redis database, the bucket items in each bucket can be sorted in ascending order of their expiration times.

[0077] In one embodiment of this application, the task identifier information and expiration time of the delayed task are stored in the database as bucket elements of the bucket group to store the bucket group through the database. This includes: converting the task identifier information of the delayed task based on the CRC32 algorithm to obtain the converted value; performing a modulo operation on the number of buckets in the bucket group based on the converted value, and taking the bucket numbered with the modulo result as the target bucket; and storing the task identifier information and expiration time of the delayed task as bucket elements in the target bucket.

[0078] Specifically, the CRC32 algorithm can be used to convert the string-based task identification information into a numerical value. Based on this, the target bucket is determined by taking the remainder of the number of buckets in the bucket group based on the converted value. This allows multiple task identification information to be distributed and evenly stored in multiple buckets.

[0079] In step 320, the database is scanned to place the task identification information of delayed tasks that have expired in the database into the ready queue according to their expiration time.

[0080] The expiration time can be used to determine which delayed tasks have expired, and the corresponding task identifier information can then be retrieved from the Redis database. The task identifier information of delayed tasks placed in the ready queue will be deleted from the database.

[0081] Figure 6 An embodiment according to this application is shown. Figure 3 A flowchart detailing steps 310 and 320 is provided. Please refer to [link / reference]. Figure 6 As shown, storing the task identifier information and expiration time of a delayed task in the database may specifically include the following steps:

[0082] In step 310", the task identifier information of the delayed task is used as an element, and the expiration time of the delayed task is used as the score associated with the element. The elements and the scores associated with the elements are stored in an ordered set in the database.

[0083] In Redis, an ordered set is a sorted set, also known as a zset. Task identifiers can be used as elements or members of a zset, and expiration times can be used as scores.

[0084] Step 320 may specifically include the following steps:

[0085] In step 320", the task identification information of the delayed tasks that have expired in the database is obtained by filtering out the elements whose scores are associated in the ordered set of the database within the specified score range, and the task identification information is put into the ready queue.

[0086] The zrangeByScore command provided by Redis can be used to quickly filter out the task identifiers of delayed tasks that have expired. The zrangeByScore command sorts the task identifiers according to their corresponding scores before filtering, which can improve the filtering efficiency.

[0087] Filtering out elements whose associated scores fall within a specified score range can specifically involve filtering out task identifiers whose expiration time is less than the current time.

[0088] In this embodiment of the application, by storing the elements and the scores associated with the elements in an ordered set of the database, the delay queue can support delays of any length.

[0089] Figure 7 A schematic diagram of a bucket assembly according to an embodiment of this application is shown. Please refer to... Figure 7 As shown, after the client submits a delay message, the buckets are responsible for storing the task identifier information and expiration time of the delayed task. Specifically, a hash operation is used to determine which bucket to store the task identifier information and expiration time of the delayed task in. Each bucket stores a Zset Score and a Zset Member, where the Zset Score is the expiration time and the Zset Member is the task identifier information.

[0090] Figure 8 An embodiment according to this application is shown. Figure 5 A flowchart detailing step 320 is provided. Please refer to [link / reference]. Figure 8 As shown, step 320 may also include the following steps:

[0091] In step 320', the corresponding thread for each bucket scans the corresponding buckets in the bucket group to put the task identification information of the delayed tasks that have expired in each bucket into the ready queue according to the expiration time.

[0092] Please see Figure 4 and Figure 7 As shown, the Timer thread is responsible for scanning the buckets. A Timer thread can be set up for each bucket to scan it. The Timer thread will put the task identifier information of the delayed tasks that have expired into the ready queue.

[0093] In this embodiment, by dividing the bucket group into multiple buckets and distributing the task identification information among the multiple buckets, the amount of task identification information stored in each bucket can be reduced. On this basis, by setting a Timer thread for each bucket to scan it, each Timer thread can scan each bucket in parallel, which greatly improves the efficiency of scanning. When using the zrangeByScore command to filter out the task identification information of the delayed tasks that have expired, the time complexity can reach O(log(N)+M), where N is the number of bucket elements in the bucket and M is the number of task identification information returned.

[0094] In one embodiment of this application, storing the task identifier information and expiration time of a delayed task into a database includes: storing the task identifier information and expiration time of the delayed task into a database, and sorting the task identifier information in the database in ascending order of expiration time;

[0095] Based on the expiration time, the task identifier information of the delayed tasks that have expired in the database is placed into the ready queue. This includes: retrieving a predetermined number of task identifier information from the top of the database at predetermined intervals, and placing the task identifier information of the delayed tasks that have expired from the retrieved task identifier information into the ready queue.

[0096] Specifically, the task identifiers in each bucket can be sorted in ascending order according to the expiration time of each task identifier. Each Timer thread retrieves the first n task identifiers from the corresponding bucket every second, filters out the task identifiers of expired delayed tasks from the retrieved task identifiers, and then puts the task identifiers of expired delayed tasks into the ready queue.

[0097] In step 330, the task identifier information is retrieved from the ready queue and placed into the running queue. The task information corresponding to the task identifier information is then delivered to the client so that the client can process the delayed task corresponding to the task information.

[0098] The ready queue stores the task identifiers of delayed tasks that have expired. Delayed tasks need to be processed after they expire; the run queue stores the task identifiers of delayed tasks currently being processed. Both the ready and run queues can be stored using Redis lists.

[0099] Please continue reading Figure 4 As shown, the Poller thread adds task IDs stored in the ready queue to the run queue. Based on client poll requests, the Poller thread blocks as it retrieves task identifiers from the ready queue and atomically adds them to the run queue. Then, the Poller thread retrieves the corresponding task information from the task pool and returns it to the client. A poll request is a polling request initiated by the client to the delayed queue server to request task information.

[0100] In e-commerce scenarios, after receiving task information, the client can perform corresponding operations based on the order number in the task information.

[0101] In one embodiment of this application, placing the task identifier information of the delayed task that has expired in the database into the ready queue according to the expiration time includes: placing the task identifier information of the delayed task that has expired in the database into the ready queue corresponding to the type of the delayed task according to the expiration time;

[0102] Retrieving task identification information from the ready queue and placing it into the running queue includes: retrieving task identification information from the ready queue corresponding to the type of the delayed task and placing it into the running queue corresponding to the type of the delayed task.

[0103] Please continue reading Figure 4 As shown, multiple topics are set up, each with a corresponding ready queue and a run queue. Each ready queue and run queue can store one or more task IDs (task identification information). A Poller thread can be set up for each topic. Each Poller thread can retrieve the task identification information from the ready queue corresponding to its own thread and put the task identification information into the run queue corresponding to its own thread.

[0104] A topic refers to a subject or type. Different delayed tasks can correspond to the same or different topics, and the same client can also correspond to the same or different topics. A topic can indicate delayed tasks in a specific scenario. Therefore, in this embodiment, the delayed queue can process delayed tasks from different scenarios simultaneously, and the delayed queue can be opened as a centralized delayed service to users in different scenarios or even domains. This is easy to understand, although... Figure 4 The ready queue and the running queue only store task IDs, but in other embodiments of this application, other information may also be stored.

[0105] In one embodiment of this application, before delivering the task information corresponding to the task identifier information to the client, the method for implementing the delayed queue further includes: receiving a long polling request initiated by the client and suspending the long polling request; if it is confirmed within a predetermined time period after receiving the long polling request that there is no task identifier information in the ready queue, returning an empty result to the client so that the client can re-initiate the long polling request after receiving the empty result;

[0106] Deliver the task information corresponding to the task identifier to the client, including:

[0107] If, after receiving a long polling request, it is confirmed within a predetermined time period that task identification information exists in the ready queue, the task information corresponding to the task identification information will be delivered to the client.

[0108] Long polling requests initiated by the client are poll requests that the Poller thread can handle. Figure 9 This diagram illustrates the principle of a client performing long polling on a delayed queue according to an embodiment of this application. Please refer to... Figure 9 As shown, after receiving a long polling request, the delayed queue server will suspend the request and then retrieve the task identifier information for the corresponding topic from the ready queue. If there is no task identifier information for the corresponding topic in the ready queue within 30 seconds, an empty result will be returned to the client as a response. If there is task identifier information for the corresponding topic in the ready queue within 30 seconds, the task identifier information will be returned to the client immediately.

[0109] In this embodiment, the client SDK performs long polling on the delayed queue server, which greatly reduces the server load as the client SDK does not poll the delayed queue server frequently. At the same time, it can also ensure that the expired task identifier information can be consumed by the client immediately when there is expired task identifier information, thereby improving the real-time performance of messages.

[0110] Figure 10 A schematic diagram summarizing the technologies employed to achieve message timeliness according to an embodiment of this application is shown. Please refer to... Figure 10 As shown, the following three technologies were mainly adopted to achieve timely messaging:

[0111] 1. Use Redis Zset to quickly filter out expiration information and support specifying arbitrary delays.

[0112] 2. Bucket grouping enables parallel scanning and shortens queue length, improving efficiency.

[0113] 3. Implement long polling, consuming messages immediately upon expiration, while reducing the pressure on the server from the client.

[0114] Based on the above technologies, the average message delivery delay can be less than 1 second.

[0115] In step 340, if no confirmation message corresponding to the task information is received from the client, the task identifier information corresponding to the task information in the run queue is re-stored into the database to retry processing the delayed task corresponding to the task information.

[0116] The acknowledgment message is used to indicate to the client that the corresponding delayed task has been completed.

[0117] After the client completes the corresponding delayed task, it returns an acknowledgment message (ACK) to the delayed queue server. At this point, the task information is deleted from the task pool. Then, if no task information corresponding to a certain task identifier is found in the task pool, the task identifier information is deleted from the database. If the delayed queue server does not receive an acknowledgment message corresponding to the task information from the client, it means that the client has not correctly completed the corresponding delayed task. In this case, the subsequent process will be executed to reprocess the corresponding delayed task by re-storing the task identifier information corresponding to the task information in the run queue into the database.

[0118] Please continue reading Figure 4 As shown, the Cleaner thread is used to clean up the run queue. A corresponding Cleaner thread can be set for the run queue under each topic. If no confirmation message corresponding to the task information is received from the client, the Cleaner thread is responsible for re-storing the task identification information corresponding to the task information in the run queue into the database.

[0119] Figure 11A An embodiment according to this application is shown. Figure 3 A flowchart detailing step 340 is provided. Please refer to [link / reference]. Figure 11A As shown, re-storing the task identifier information corresponding to the task information in the run queue into the database to retry processing the delayed task corresponding to the task information may specifically include the following steps:

[0120] In step 340', a new expiration time is determined based on the current time, and the task identifier information corresponding to the task information in the running queue and the new expiration time are re-stored into the database. This is so that if no confirmation message corresponding to the task information is received from the client after the new expiration time, the task identifier information is retrieved from the database and placed into the ready queue to retry processing the delayed task corresponding to the task information.

[0121] Specifically, the new expiration time can be calculated as "new expiration time = current time + ttr". ttr is a pre-set time limit for the client to provide confirmation information. That is, if the client has not provided an ACK after the ttr time has elapsed, the task identification information will be placed in the ready queue, and then the task information corresponding to the task identification information will be re-delivered to the client.

[0122] In this embodiment of the application, by setting a new expiration time, leeway can be provided for situations where the client processing time is too long, avoiding the waste of resources by directly redelivering.

[0123] Figure 11B Another embodiment according to this application is shown. Figure 3 A flowchart detailing step 340 is provided. Please refer to [link / reference]. Figure 11B As shown, if no confirmation message corresponding to the task information is received from the client, the task identifier information corresponding to the task information in the run queue will be re-stored into the database. This may include the following steps:

[0124] In step 340", if no confirmation message corresponding to the task information is received from the client and the number of retries for the task information has not reached the preset threshold, the task identifier information corresponding to the task information in the running queue will be re-stored into the database.

[0125] For details, please continue to see Figure 4 As shown, the Cleaner thread polls the run queue under each topic, takes out n task identifiers from the run queue each time, and determines whether the number of retries for the task information corresponding to each task identifier has reached the preset threshold. If the preset threshold has not been reached, the corresponding task identifier will be put back into Buckets. If the client has not responded with ACK after the TTR time has passed, the task identifier will be put into the ready queue.

[0126] In this embodiment, task information can be delivered multiple times to avoid data loss due to task information not being consumed properly during a single delivery.

[0127] In one embodiment of this application, after retrieving task identifier information from the ready queue and placing it into the run queue, the method for implementing the delay queue further includes:

[0128] If an acknowledgment message corresponding to the task information is received from the client, the task identifier information corresponding to the task information is retrieved from the run queue and discarded. If no acknowledgment message corresponding to the task information is received from the client and the number of retries for the task information reaches a preset threshold, the task identifier information is placed in the dead letter queue. The dead letter queue is used to store the task identifier information of delayed tasks for which the client has not responded with an acknowledgment message when the number of retries reaches the preset threshold.

[0129] Please continue reading Figure 4 As shown, if no acknowledgment message corresponding to the task information is received from the client and the number of retries for the task information reaches a preset threshold, the Cleaner thread will also put the task identification information into the dead-letter queue, indicating that the client is currently unable to consume messages normally. Task identification information in the dead-letter queue can be retried after a period of time. After the task identification information is put into the dead-letter queue, the corresponding task information will be deleted from the task pool.

[0130] Specifically, dead-letter queues can be set up for each topic. A crucial characteristic of delayed queues is data reliability; it is essential to ensure that delayed messages delivered by clients are not lost, and that clients must consume them after the specified delay (unless the client's service itself malfunctions).

[0131] Figure 12 A schematic diagram illustrating the principle of implementing data reliability according to an embodiment of this application is shown. Please refer to... Figure 12 As shown, to prevent message loss due to sudden network interruption when retrieving task information and delivering it to the client, or to prevent the client from crashing before processing the message, the Poller thread uses Redis's brpoplpush command to retrieve task IDs from the ready queue and place them into the running queue. It then delivers the task information corresponding to the task IDs to the client. If the client consumes the task information normally, it will send an ACK. The Cleaner thread retrieves a portion of task identification information from the corresponding running queue each time. If the client has already sent an ACK, the task identification information corresponding to these tasks is discarded. If the client does not send an ACK and the retry count exceeds the limit, it indicates an error in the client service; after multiple deliveries, the task information is still not consumed normally. In this case, the corresponding task identification information is placed in the dead-letter queue. If the client does not send an ACK and the retry count has not exceeded the limit, the corresponding task identification information is put back into the bucket. The next time, the Timer thread will scan the task identification information from the bucket and put it back into the ready queue.

[0132] Therefore, based on Figure 12The mechanism shown in the embodiment can ensure that even if there is a network anomaly or the client is temporarily unavailable, the client can still consume the delayed message normally.

[0133] Figure 13 A schematic diagram illustrating the effect of a solution according to an embodiment of this application on message timeliness is shown. Please refer to... Figure 13 As shown, the horizontal axis represents time, and the vertical axis represents the average delay of message delivery. It can be seen that, regardless of the topic, the average delay of message delivery at any time is less than 1 second, which shows that the solution of this application embodiment has strong real-time performance.

[0134] In summary, the delayed queue implementation method provided in this application embodiment is the first to implement a delayed queue based on Redis Zset, supporting the specification of arbitrary delay duration; by using Redis Zset, Bucket grouping, and implementing long polling on the client, it ensures that the consumer can consume the message immediately after the specified delay time, achieving high real-time performance with an average delivery delay of less than 1 second; by introducing a running queue, message ACK mechanism, retry strategy, and dead letter queue, it prevents message loss due to client crash or processing failure after message delivery, ensuring message reliability.

[0135] The following describes an apparatus embodiment of this application, which can be used to execute the delay queue implementation method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the delay queue implementation method described above.

[0136] Figure 14 A block diagram of an implementation apparatus for a delay queue according to an embodiment of the present application is shown.

[0137] Reference Figure 14As shown, a delay queue implementation apparatus 1400 according to an embodiment of this application includes: a storage unit 1410, a scanning unit 1420, a retrieval and delivery unit 1430, and a retry unit 1440. The storage unit 1410, upon receiving task information for a delayed task submitted by the client, stores the task identifier information and expiration time of the delayed task into a database. The scanning unit 1420 scans the database to place the task identifier information of expired delayed tasks in the database into a ready queue based on the expiration time. The extraction and delivery unit 1430 retrieves the task identifier information from the ready queue and places it into a running queue, and delivers the task information corresponding to the task identifier information to the client so that the client can process the delayed task corresponding to the task information. The retry unit 1440, if no confirmation message corresponding to the task information is received from the client, re-stores the task identifier information corresponding to the task information in the running queue into the database to retry processing the delayed task corresponding to the task information. The confirmation message indicates that the client has completed processing the corresponding delayed task.

[0138] In some embodiments of this application, based on the aforementioned scheme, the retry unit 1440 is configured to: determine a new expiration time based on the current time, and re-store the task identifier information corresponding to the task information in the running queue and the new expiration time into the database, so that if no confirmation message corresponding to the task information is received from the client after the new expiration time is reached, the task identifier information is retrieved from the database and placed into the ready queue to retry processing the delayed task corresponding to the task information.

[0139] In some embodiments of this application, based on the aforementioned scheme, the retry unit 1440 is configured to: if no confirmation message corresponding to the task information is received from the client and the number of retries for the task information does not reach a preset threshold, then the task identifier information corresponding to the task information in the running queue is re-stored into the database.

[0140] In some embodiments of this application, based on the foregoing scheme, after retrieving the task identifier information from the ready queue and placing it into the running queue, the retry unit 1440 is further configured to: if an acknowledgment message corresponding to the task information is received from the client, retrieve the task identifier information corresponding to the task information from the running queue and discard it; if no acknowledgment message corresponding to the task information is received from the client and the number of retries for the task information reaches a preset threshold, place the task identifier information into a dead-letter queue, wherein the dead-letter queue is used to store the task identifier information of delayed tasks for which the client has not yet returned an acknowledgment message when the number of retries reaches the preset threshold.

[0141] In some embodiments of this application, based on the foregoing scheme, the storage unit 1410 is configured to store the task identifier information and expiration time of the delayed task as bucket elements in the bucket group into the database, so as to store the bucket group through the database, wherein the bucket group includes multiple buckets.

[0142] In some embodiments of this application, based on the aforementioned scheme, the scanning unit 1420 is configured to scan the corresponding buckets in the bucket group through the thread corresponding to each bucket, so as to put the task identification information of the delayed tasks that have expired in each bucket into the ready queue according to the expiration time.

[0143] In some embodiments of this application, based on the foregoing scheme, before delivering the task information corresponding to the task identifier information to the client, the extraction and delivery unit 1430 is further configured to: receive a long polling request initiated by the client and suspend the long polling request; if it is confirmed within a predetermined time period after receiving the long polling request that there is no task identifier information in the ready queue, return an empty result to the client so that the client can re-initiate the long polling request after receiving the empty result; the extraction and delivery unit 1430 is configured to: if it is confirmed within a predetermined time period after receiving the long polling request that there is task identifier information in the ready queue, then deliver the task information corresponding to the task identifier information to the client.

[0144] In some embodiments of this application, based on the foregoing scheme, the scanning unit 1420 is configured to: place the task identifier information of the delayed task that has expired in the database into the ready queue corresponding to the type of the delayed task according to the expiration time; the extraction and delivery unit 1430 is configured to: retrieve the task identifier information from the ready queue corresponding to the type of the delayed task and place it into the running queue corresponding to the type of the delayed task.

[0145] In some embodiments of this application, based on the foregoing scheme, the storage unit 1410 is configured to: use the task identifier information of the delayed task as an element, use the expiration time of the delayed task as a score associated with the element, and store the element and the score associated with the element in an ordered set of the database accordingly; the scanning unit 1420 is configured to: filter out elements in the ordered set of the database whose scores are within a specified score range, obtain the task identifier information of the delayed task that has expired in the database, and put the task identifier information into the ready queue.

[0146] Figure 15 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0147] It should be noted that, Figure 15 The computer system 1500 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0148] like Figure 15 As shown, the computer system 1500 includes a Central Processing Unit (CPU) 1501, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1502 or programs loaded from storage portion 1508 into Random Access Memory (RAM) 1503, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1503. The CPU 1501, ROM 1502, and RAM 1503 are interconnected via bus 1504. An Input / Output (I / O) interface 1505 is also connected to bus 1504.

[0149] The following components are connected to I / O interface 1505: an input section 1506 including a keyboard, mouse, etc.; an output section 1507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1508 including a hard disk, etc.; and a communication section 1509 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1509 performs communication processing via a network such as the Internet. A drive 1510 is also connected to I / O interface 1505 as needed. Removable media 1511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1510 as needed so that computer programs read from them can be installed into storage section 1508 as needed.

[0150] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1509, and / or installed from removable medium 1511. When the computer program is executed by central processing unit (CPU) 1501, it performs various functions defined in the system of this application.

[0151] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0152] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0153] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0154] In one aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0155] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0156] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0157] It is understood that in the specific implementation of this application, data related to delayed tasks is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0158] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0159] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for implementing a delayed queue, characterized in that, The method is executed by the server, and the method includes: After receiving the task information of the delayed task submitted by the client, the task identifier information and expiration time of the delayed task are stored in the database; The database is scanned to place the task identification information of the delayed tasks that have expired in the database into the ready queue according to the expiration time; Receive long polling requests initiated by the client and suspend the long polling requests; If, after receiving the long polling request, it is confirmed within a predetermined time period that there is no task identifier information in the ready queue, an empty result is returned to the client so that the client can re-initiate the long polling request after receiving the empty result; If, after receiving the long polling request, it is confirmed within a predetermined time period that there is task identification information in the ready queue, the task identification information is taken out from the ready queue and placed into the running queue, and the task information corresponding to the task identification information is delivered to the client so that the client can process the delayed task corresponding to the task information. If a confirmation message corresponding to the task information is received from the client, the task identifier information corresponding to the task information is retrieved from the running queue and discarded. If no confirmation message corresponding to the task information is received from the client, the task identifier information corresponding to the task information in the running queue is re-stored into the database to retry processing the delayed task corresponding to the task information. The confirmation message is used to indicate that the client has completed processing the corresponding delayed task.

2. The method for implementing a delayed queue according to claim 1, characterized in that, The step of re-storing the task identifier information corresponding to the task information in the running queue into the database, so as to retry processing the delayed task corresponding to the task information, includes: A new expiration time is determined based on the current time, and the task identifier information corresponding to the task information in the running queue and the new expiration time are re-stored into the database. This is so that if no confirmation message corresponding to the task information is received from the client after the new expiration time, the task identifier information is retrieved from the database and placed into the ready queue to retry processing the delayed task corresponding to the task information.

3. The method for implementing a delayed queue according to claim 1, characterized in that, If no confirmation message corresponding to the task information is received from the client, the task identifier information corresponding to the task information in the run queue is re-stored into the database, including: If no confirmation message corresponding to the task information is received from the client and the number of retries for the task information does not reach a preset threshold, then the task identifier information corresponding to the task information in the running queue is re-stored into the database.

4. The method for implementing a delayed queue according to claim 3, characterized in that, After retrieving task identification information from the ready queue and placing it into the run queue, the method further includes: If no confirmation message corresponding to the task information is received from the client and the number of retries for the task information reaches a preset threshold, the task identification information is placed in a dead-letter queue. The dead-letter queue is used to store the task identification information of delayed tasks for which the client has not returned a confirmation message when the number of retries reaches the preset threshold.

5. The method for implementing a delayed queue according to claim 1, characterized in that, The step of storing the task identifier information and expiration time of the delayed task into the database includes: The task identifier information and expiration time of the delayed task are stored in the database as bucket elements of the bucket group, so that the bucket group is stored in the database and the bucket group includes multiple buckets.

6. The method for implementing a delayed queue according to claim 5, characterized in that, The database scan, which involves placing the task identifier information of expired delayed tasks in the database into the ready queue based on the expiration time, includes: The corresponding thread of each bucket scans the corresponding buckets in the bucket group, and puts the task identification information of the delayed tasks that have expired in each bucket into the ready queue according to the expiration time.

7. The method for implementing a delay queue according to any one of claims 1-6, characterized in that, The step of adding the task identifier information of the expired delayed tasks in the database to the ready queue according to the expiration time includes: Based on the expiration time, the task identifier information of the delayed tasks that have expired in the database is placed into the ready queue corresponding to the type of the delayed task; The step of retrieving task identifier information from the ready queue and placing it into the running queue includes: Take the task identifier information from the ready queue corresponding to the type of the delayed task and put it into the run queue corresponding to the type of the delayed task.

8. The method for implementing a delay queue according to any one of claims 1-6, characterized in that, The step of storing the task identifier information and expiration time of the delayed task into the database includes: Using the task identifier information of the delayed task as an element, and the expiration time of the delayed task as a score associated with the element, the element and the score associated with the element are stored in an ordered set in the database. The step of adding the task identifier information of the expired delayed tasks in the database to the ready queue according to the expiration time includes: By filtering out elements whose scores fall within a specified score range from the ordered set of the database, the task identification information of the delayed tasks that have expired in the database is obtained, and the task identification information is placed into the ready queue.

9. An apparatus for implementing a delayed queue, characterized in that, The device is installed on the server, and the device includes: The storage unit is used to store the task identifier information and expiration time of the delayed task into the database after receiving the task information of the delayed task submitted by the client. A scanning unit is used to scan the database to place the task identification information of the delayed tasks that have expired in the database into the ready queue according to the expiration time. The extraction and delivery unit is used to retrieve task identification information from the ready queue and put it into the running queue, and deliver the task information corresponding to the task identification information to the client so that the client can process the delayed task corresponding to the task information; The retry unit is used to re-store the task identifier information corresponding to the task information in the running queue into the database if no confirmation message corresponding to the task information is received from the client, so as to retry processing the delayed task corresponding to the task information. The confirmation message is used to indicate that the client has completed the processing of the corresponding delayed task. Before delivering the task information corresponding to the task identifier information to the client, the extraction and delivery unit is further configured to: receive a long polling request initiated by the client and suspend the long polling request; if it is confirmed within a predetermined time period after receiving the long polling request that there is no task identifier information in the ready queue, return an empty result to the client so that the client can re-initiate the long polling request after receiving the empty result; the extraction and delivery unit is configured to: if it is confirmed within a predetermined time period after receiving the long polling request that there is task identifier information in the ready queue, then deliver the task information corresponding to the task identifier information to the client; After retrieving the task identifier information from the ready queue and placing it into the running queue, the retry unit is further configured to: if a confirmation message corresponding to the task information is received from the client, retrieve the task identifier information corresponding to the task information from the running queue and discard it.

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

11. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the method of implementing a delay queue as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method for implementing a delay queue as described in any one of claims 1 to 8.

Images