Method, device and storage medium for building permission pool and delay queue based on Redis

Abstract

The present invention relates to a method, device and storage medium for building a permission pool and a delay queue based on Redis, and is applied to the technical field of message push technology. The method comprises: the present application obtains the subscription relationship between a user and a template message, and builds a permission pool in Redis according to the subscription relationship. When a message needs to be pushed to a user, the message to be pushed in the message queue (first MQ) is synchronized to the delay queue, and the template messages subscribed to by the user are pushed to the user one by one through the delay queue (FIFO queue). The present application uses the FIFO queue built by Redis to avoid message omission and disorder caused by sending failure in the case of high concurrency, and the messages sent by the present application are all template messages subscribed by the user, which can avoid the waste of daily message push interface call times.

Description

Technical Field

[0001] The present invention relates to the field of message push technology, and in particular to a method, device and storage medium for building a permission pool and a delay queue based on Redis. Background Art

[0002] Currently, the WeChat mini-program message push interface has a limit on the number of calls. It can only be called a fixed number of times N per day. If this limit is exceeded, an error message will be directly returned and the push will fail. WeChat also has subscription restrictions. We can only push messages if the user logs in to the mini-program and clicks "allow push of selected template messages". After allowing, the number of template subscriptions will increase by one. If the user does not have the subscription number for the template message, pushing to the user will also directly return failure. However, we are currently pushing messages without judging the subscription relationship, resulting in a lot of wasted interface calls. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a method, device and storage medium for building a permission pool and delay queue based on Redis, so as to solve the problem in the prior art that the subscription relationship between the user and the template is not judged, but a push method is adopted. The message push interface has a limit on the number of messages pushed per day, resulting in a lot of wasted interface calls.

[0004] According to a first aspect of an embodiment of the present invention, a method for constructing a permission pool and a delay queue based on Redis is provided, the method comprising:

[0005] Obtain the subscription relationship between the user and the template message, and generate the first MQ of the subscription relationship between the user and the template in the redis database. Each time the user subscribes, a push message is stored in the first MQ for building the permission pool;

[0006] Synchronize the status queue of each push message in the first MQ in the tidb database to obtain the second MQ;

[0007] When the push interface needs to be called to push a message to the user, the message to be pushed in the first MQ is synchronously stored in the delay queue, and the status of the message in the delay queue in the second MQ is changed;

[0008] If the message in the delayed queue is pushed successfully, the corresponding pushed message in the first MQ is deleted and the status of the message in the second MQ is changed;

[0009] If the message push in the delay queue fails, the message is marked as allowing retry, and the status of the message in the second MQ is changed until all messages in the first MQ are cleared.

[0010] Preferably,

[0011] The push message includes the user ID, template ID and subscription times.

[0012] Preferably,

[0013] Each time the user subscribes, a push message is stored in the first MQ, including:

[0014] Each time the user subscribes, the push message is sent to the first MQ through the subscription message push interface. If the subscription message push interface times out or reports other exceptions, the message is resent through the MQ retry mechanism.

[0015] Preferably,

[0016] The status of each push message includes: unsent status, delayed queue status, sent successfully status and sent failed retry status.

[0017] Preferably,

[0018] If the message push fails in the delayed queue, it includes:

[0019] The push timeout occurs, the number of daily calls to the message push interface is exhausted, or other exceptions are reported.

[0020] Preferably,

[0021] If the push times out or reports other exceptions, mark the message as allowing retry and change the status of the message in the second MQ;

[0022] When the number of calls to the message push interface per day is exhausted, the push of the message and the remaining messages in the delay queue is stopped until the number of calls to the message push interface per day is refreshed and pushed again the next day.

[0023] According to a second aspect of an embodiment of the present invention, a device for building a permission pool and a delay queue based on Redis is provided, the device comprising:

[0024] Permission pool construction module: used to obtain the subscription relationship between the user and the template message, generate the first MQ of the subscription relationship between the user and the template in the Redis database, and store a push message in the first MQ every time the user subscribes to build the permission pool;

[0025] State storage module: used to synchronize the state queue of each push message in the first MQ in the tidb database to obtain the second MQ;

[0026] Delay queue building module: when the push interface needs to be called to push messages to users, it is used to synchronously store the messages to be pushed in the first MQ into the delay queue, and at the same time change the status of the messages in the delay queue in the second MQ;

[0027] The first sending module is used to delete the corresponding pushed message in the first MQ and change the status of the message in the second MQ if the message in the delay queue is pushed successfully;

[0028] The second sending module is used to mark the message as allowing for retry if the message push in the delay queue fails, and change the status of the message in the second MQ until all messages in the first MQ are cleared.

[0029] According to a third aspect of an embodiment of the present invention, a storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a main controller, each step in the above method is implemented.

[0030] The technical solutions provided by the embodiments of the present invention may have the following beneficial effects:

[0031] This application obtains the subscription relationship between the user and the template message, and builds a permission pool in Redis based on the subscription relationship. When it is necessary to push messages to the user, the messages to be pushed in the message queue (first MQ) are synchronized to the delay queue, and the subscribed template messages are pushed to the user one by one through the delay queue (FIFO queue). This application uses the FIFO queue built by redis to avoid message omissions and disorder caused by sending failures in high concurrency situations. In addition, the messages sent by this application are all template messages subscribed by the user, which can avoid the waste of daily message push interface calls.

[0032] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0034] Figure 1 This is a flowchart of a method for building a permission pool and a delay queue based on Redis according to an exemplary embodiment;

[0035] Figure 2 is a system diagram of an apparatus for constructing a permission pool and a delay queue based on Redis according to an exemplary embodiment;

[0036] In the accompanying figure: 1-authority pool construction module, 2-state storage module, 3-delay queue construction module, 4-first sending module, 5-second sending module. DETAILED DESCRIPTION

[0037] Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. In the following description, when referring to the drawings, like numbers in different figures represent like or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present invention, as detailed in the appended claims.

[0038] Example 1

[0039] Figure 1 FIG. 1 is a flow chart of a method for constructing a permission pool and a delay queue based on Redis according to an exemplary embodiment. Figure 1 As shown, the method includes:

[0040] S1, obtain the subscription relationship between the user and the template message, generate the first MQ of the subscription relationship between the user and the template in the Redis database, and store a push message in the first MQ every time the user subscribes to build the permission pool;

[0041] S2: Synchronize the status queue of each push message in the first MQ in the tidb database to obtain the second MQ;

[0042] S3, when the push interface needs to be called to push a message to the user, the message to be pushed in the first MQ is synchronously stored in the delay queue, and the status of the message in the delay queue in the second MQ is changed;

[0043] S4, if the message in the delayed queue is pushed successfully, the corresponding pushed message in the first MQ is deleted, and the status of the message in the second MQ is changed;

[0044] S5: If the message push in the delay queue fails, the message is marked as allowing retry, and the status of the message in the second MQ is changed until all messages in the first MQ are cleared;

[0045] It is understandable that in the existing technology, the messages sent to WeChat subscription accounts are basically priority messages. The so-called priority messages are to configure two message channels - WeChat subscription accounts and SMS, and give priority to pushing WeChat subscription account messages. If the sending is successful, the process ends. If the push fails, an SMS message will be sent to the user. However, sending SMS messages is charged, and the SMS fee is paid by the courier, which increases their delivery costs and reduces their income. If we can increase the success rate of WeChat subscription account messages, we can increase the income of the courier and achieve cost reduction and efficiency improvement. However, the WeChat applet message push interface currently has a limit on the number of calls, and can only be called a fixed number of times N per day. If this limit is exceeded, an error message will be directly returned and the push will fail.And WeChat has set subscription restrictions. Only when the user clicks "Allow Push" for the selected template message when logging in to the applet can we push the message. After allowing, the template subscription count increases by one. If the user does not have a subscription count for this template message and we still push the message to the user, it will directly return a failure. However, currently, we push all messages without checking this subscription relationship, resulting in a waste of many interface call times. To solve the above problems, the present application adopts the following specific measures: Obtain the subscription relationship between the user and the template message. That is, each time the user subscribes to a certain template message, it indicates that the user can receive the content of this template message. At this time, when sending this template message to the user, the user can successfully receive it. After obtaining the subscription relationship between the user and the template, generate the first MQ (message queue), that is, the task bar, for the user's subscription relationship with the template in the redis database. Each time the user subscribes, store a push message (a task) in the first MQ to build a permission pool. At the same time, synchronize the status queue of each push message in the first MQ to the tidb database to obtain the second MQ. Use MQ to ensure the consistency of the two databases. The so-called second MQ is used to represent the processing status of each task in the first MQ. At the same time, when it is necessary to call the push interface to push a message to the user, synchronize the messages to be pushed in the first MQ to the delay queue, and at the same time change the status of the messages in the delay queue in the second MQ. Through a simple FIFO (delay) queue, it solves the problem that in the case of high concurrency, the messages that occupy the subscription count in the front push fail, and the messages that should have been successfully pushed in the back fail because the subscription count is not enough and the disorder of message sending. For the messages in the delay queue, if the push is successful, delete the corresponding push message in the first MQ, indicating that the push task has been completed, and at the same time change the status of this message in the second MQ. If the message push in the delay queue fails, mark that the message is allowed to be retried, and retry through the retry mechanism of MQ, and at the same time change the status of this message in the second MQ until all messages in the first MQ are cleared. The present application obtains the subscription relationship between the user and the template message, and constructs a permission pool in Redis according to the subscription relationship. When it is necessary to push a message to the user, synchronize the messages to be pushed in the message queue (the first MQ) to the delay queue, and push the template messages subscribed by the user to the user one by one through the delay queue (FIFO queue). The FIFO queue constructed by the present application using redis can avoid the missed sending and disorder of messages caused by sending failures in the case of high concurrency, and the messages sent by the present application are all template messages subscribed by the user, which can avoid the waste of daily message push interface call times.

[0046] Preferably,

[0047] The push message includes the user ID, template ID, and subscription count;

[0048] It is understandable that when constructing the first MQ, each task should include the user ID, template ID and number of subscriptions. It is worth emphasizing that the number of subscriptions mentioned here refers to the number of subscriptions of the user at one time. Even if it is the same template message, if the user subscribes again after a period of time, a new task will be created in the first MQ, rather than adding or subtracting the number of subscriptions based on the original task.

[0049] Preferably,

[0050] Each time the user subscribes, a push message is stored in the first MQ, including:

[0051] Each time the user subscribes, the push message is sent to the first MQ through the subscription message push interface. If the subscription message push interface times out or reports other exceptions, the message is resent through the MQ retry mechanism;

[0052] It is understandable that after obtaining the user's subscription relationship, a task message will be generated in the first MQ. If in the process of generating the task message, if the subscription message push interface times out or reports other exceptions, it will be resent through the MQ retry mechanism. This can effectively avoid the problem of obtaining the user's subscription relationship but not generating the task message in the first MQ.

[0053] Preferably,

[0054] The status of each push message includes: unsent status, delayed queue status, sent successfully status and sent failed retry status;

[0055] It can be understood that after obtaining the user's subscription relationship and generating a task message in the first MQ, the status of the message in the second MQ is unsent. If the message is synchronized to the delay queue, the status of the message in the second MQ is modified to the delay queue status. If the message in the delay queue is sent successfully, the task is cleared in the first MQ, and the status of the message in the second MQ is modified to sent successfully. If the message in the delay queue fails to send, the status of the message in the second MQ is modified to send failed retry.

[0056] Preferably,

[0057] If the message push fails in the delayed queue, it includes:

[0058] Push timeout, the number of daily calls to the message push interface is exhausted, or other exceptions are reported;

[0059] It is understandable that there are two possibilities for the failure to send template messages in the delay queue. One is a problem with the system itself, that is, push timeout or other errors. The other is that the number of calls to the message push interface mentioned above is limited per day. When the number of calls is exhausted, the message sending failure will occur.

[0060] Preferably,

[0061] If the push times out or reports other exceptions, mark the message as allowing retry and change the status of the message in the second MQ;

[0062] When the number of calls to the message push interface per day is exhausted, the push of the message and the remaining messages in the delay queue is stopped until the number of calls to the message push interface per day is refreshed the next day and the messages are pushed again;

[0063] It is understandable that for the two problems mentioned above, if the system itself has a timeout or other error, the message will be marked and retried. If the number of calls to the message push interface per day is exhausted, then any subsequent messages will not be sent, and the sending of all messages in the delayed queue can only be suspended, waiting for the number of calls to the message push interface to be refreshed the next day before pushing again.

[0064] Example 2

[0065] Figure 2 1 is a system diagram of an apparatus for constructing a permission pool and a delay queue based on Redis according to an exemplary embodiment, the apparatus comprising:

[0066] Permission pool construction module 1: used to obtain the subscription relationship between the user and the template message, generate the first MQ of the subscription relationship between the user and the template in the Redis database, and store a push message in the first MQ every time the user subscribes to build the permission pool;

[0067] State storage module 2: used to synchronize the state queue of each push message in the first MQ in the tidb database to obtain the second MQ;

[0068] Delay queue construction module 3: used to synchronously store the message to be pushed in the first MQ into the delay queue when the push interface needs to be called to push a message to the user, and at the same time change the status of the message in the delay queue in the second MQ;

[0069] The first sending module 4 is used for deleting the corresponding pushed message in the first MQ and changing the status of the message in the second MQ if the message in the delay queue is pushed successfully;

[0070] The second sending module 5 is used for marking the message as allowing retry if the message push in the delay queue fails, and changing the status of the message in the second MQ until all messages in the first MQ are cleared;

[0071] It can be understood that in this embodiment, the permission pool construction module 1 is used to obtain the subscription relationship between the user and the template message, and the first MQ of the subscription relationship between the user and the template is generated in the redis database. Each time the user subscribes, a push message is stored in the first MQ for building the permission pool; the state storage module 2 is used to synchronize the state queue of each push message in the first MQ in the tidb database to obtain the second MQ; the delay queue construction module 3 is used to synchronize the messages to be pushed in the first MQ to the delay queue when the push interface needs to be called to push messages to the user, and at the same time change the status of the messages in the delay queue in the second MQ; the first sending module 4 is used to delete the corresponding push message in the first MQ if the message in the delay queue is successfully pushed, and at the same time change the second MQ Q; the second sending module 5 is used to mark the message as allowing for retry if the message push in the delay queue fails, and at the same time change the status of the message in the second MQ until all messages in the first MQ are cleared; this application obtains the subscription relationship between the user and the template message, and builds a permission pool in Redis based on the subscription relationship. When it is necessary to push a message to the user, the message to be pushed in the message queue (first MQ) is synchronized to the delay queue, and the template message subscribed to is pushed to the user one by one through the delay queue (FIFO queue). The FIFO queue built by redis in this application can avoid message omission and disorder caused by sending failure in the case of high concurrency, and the messages sent by this application are all template messages subscribed by the user, which can avoid the waste of daily message push interface calls.

[0072] Example 3:

[0073] This embodiment provides a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed by a host controller, each step in the above method is implemented;

[0074] It is understandable that the storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0075] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.

[0076] It should be noted that, in the description of the present invention, the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" is at least two.

[0077] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention pertain.

[0078] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0079] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0080] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing module, or each unit may exist physically separately, or two or more units may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or in the form of software functional modules. If the integrated modules are implemented in the form of software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium.

[0081] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0082] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0083] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.

Claims

1. A method for building a permission pool and delay queue based on Redis, characterized in that: The method comprises: Obtain the subscription relationship between the user and the template message, and generate the first MQ of the subscription relationship between the user and the template in the redis database. Each time the user subscribes, a push message is stored in the first MQ for building the permission pool; Synchronize the status queue of each push message in the first MQ in the tidb database to obtain the second MQ; When the push interface needs to be called to push a message to the user, the message to be pushed in the first MQ is synchronously stored in the delay queue, and the status of the message in the delay queue in the second MQ is changed at the same time. The delay queue is a FIFO queue built based on Redis; If the message in the delayed queue is pushed successfully, the corresponding pushed message in the first MQ is deleted and the status of the message in the second MQ is changed; If the message push in the delay queue fails, the message is marked as allowed to be retried, and the status of the message in the second MQ is changed until all messages in the first MQ are cleared; If the message push fails in the delayed queue, it includes: Push timeout, the number of daily calls to the message push interface is exhausted, or other exceptions are reported; If the push times out or reports other exceptions, mark the message as allowing retry and change the status of the message in the second MQ; When the number of calls to the message push interface per day is exhausted, the push of the message and the remaining messages in the delay queue is stopped until the number of calls to the message push interface per day is refreshed and pushed again the next day.

2. The method according to claim 1, characterized in that The push message includes the user ID, template ID and subscription times.

3. The method according to claim 2, characterized in that Each time the user subscribes, a push message is stored in the first MQ, including: Each time the user subscribes, the push message is sent to the first MQ through the subscription message push interface. If the subscription message push interface times out or reports other exceptions, the message is resent through the MQ retry mechanism.

4. The method according to claim 3, characterized in that The status of each push message includes: unsent status, delayed queue status, sent successfully status and sent failed retry status.

5. A device for building a permission pool and delay queue based on Redis, characterized in that: The device comprises: Permission pool construction module: used to obtain the subscription relationship between the user and the template message, generate the first MQ of the subscription relationship between the user and the template in the Redis database, and store a push message in the first MQ every time the user subscribes to build the permission pool; State storage module: used to synchronize the state queue of each push message in the first MQ in the tidb database to obtain the second MQ; Delay queue construction module: when the push interface needs to be called to push messages to users, it is used to synchronously store the messages to be pushed in the first MQ into the delay queue, and at the same time change the status of the messages in the delay queue in the second MQ. The delay queue is a FIFO queue built based on Redis; The first sending module is used to delete the corresponding pushed message in the first MQ and change the status of the message in the second MQ if the message in the delay queue is pushed successfully; The second sending module is used to mark the message as allowing for retry if the message push in the delay queue fails, and change the status of the message in the second MQ until all messages in the first MQ are cleared; If the message push fails in the delayed queue, it includes: Push timeout, the number of daily calls to the message push interface is exhausted, or other exceptions are reported; If the push times out or reports other exceptions, mark the message as allowing retry and change the status of the message in the second MQ; When the number of calls to the message push interface per day is exhausted, the push of the message and the remaining messages in the delay queue is stopped until the number of calls to the message push interface per day is refreshed and pushed again the next day.

6. A storage medium, characterized in that The storage medium stores a computer program, which, when executed by the main controller, implements the steps of the method for building a permission pool and a delay queue based on Redis as described in any one of claims 1 to 4.

Images