CN113900835A - Method for guaranteeing message sequential consumption in asynchronous communication - Google Patents
Method for guaranteeing message sequential consumption in asynchronous communication Download PDFInfo
- Publication number
- CN113900835A CN113900835A CN202111144387.4A CN202111144387A CN113900835A CN 113900835 A CN113900835 A CN 113900835A CN 202111144387 A CN202111144387 A CN 202111144387A CN 113900835 A CN113900835 A CN 113900835A
- Authority
- CN
- China
- Prior art keywords
- message
- queue
- type
- attribute
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 53
- 238000004891 communication Methods 0.000 title claims abstract description 21
- 238000004519 manufacturing process Methods 0.000 claims abstract description 36
- 230000003252 repetitive effect Effects 0.000 claims description 8
- JLYXXMFPNIAWKQ-UHFFFAOYSA-N γ Benzene hexachloride Chemical compound ClC1C(Cl)C(Cl)C(Cl)C(Cl)C1Cl JLYXXMFPNIAWKQ-UHFFFAOYSA-N 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 claims description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/541—Client-server
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention belongs to the technical field of communication, and particularly relates to a method for guaranteeing message sequential consumption in asynchronous communication. The method comprises the following steps: step 1: the production end prepares the message content to be sent, defines the message type and puts the message type into the message attribute; sending the data to a consumer; step 2: the consumption end directly processes the message based on the message type or processes the message according to the latest message, or processes the message according to the sequence of the message, thereby ensuring that the consumption end consumes according to the fixed sequence of the production end; the problem of serious data errors is prevented.
Description
Technical Field
The invention belongs to the technical field of communication, and particularly relates to a method for guaranteeing message sequential consumption in asynchronous communication.
Background
At present, large-scale internet companies often adopt distributed systems, and the distributed systems are characterized in that each module is independently deployed to realize the decoupling of complex services. Distributed systems are generally more flexible, but other problems often exist, one of the most troublesome being the problem of how calls between different systems are made. The calling is divided into synchronous calling and asynchronous calling according to different instantaneity.
The advantages and disadvantages of synchronous calling and asynchronous calling are obvious, asynchronous calling can process a large number of requests by colleagues, the dependency of the flow among systems is reduced, and the occurrence of system blocking is avoided; because of the above advantages, asynchronous calls are heavily used. However, the asynchronous call has a disadvantage that the communication sequence is present, and because of the delay characteristic of the asynchronous call, the sender sends the messages to the message queue in a fixed sequence when sending the messages, but because the distributed system has a plurality of consumers, and the consumers also have a multi-thread situation inside, the consumers do not need to consume the messages in the fixed sequence of the sender. In this scenario, there is a high probability of serious data error problems due to out-of-order message consumption.
Disclosure of Invention
The invention discloses a method for guaranteeing message sequential consumption in asynchronous communication, which aims to solve the problem that serious data errors are caused by the out-of-sequence message consumption when a consumer does not consume according to a fixed sequence of a sender in the background art.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows:
a method for ensuring sequential consumption of messages in asynchronous communications, comprising the steps of:
step 1: the production end prepares the message content to be sent, defines the message type and puts the message type into the message attribute; sending the data to a consumer;
step 2: the consumer processes the message based on the message type.
The production end of the invention predefines the message type, the consumption end analyzes the data packet sent by the production end to obtain the message type, and processes the message based on the message type, thereby ensuring that the consumption end consumes according to the fixed sequence of the production end; the problem of serious data errors is prevented.
Specifically, the message types include an asynchronous communication scene type with no sequence requirement, a processing scene type based on a recently sent message, and a scene type processed according to a message sending sequence.
Preferably, the step 1 comprises:
step 1.1: a production end prepares message content to be sent, a message queue to be delivered and a message type corresponding to a current service scene;
step 1.2: the production end takes the data prepared in the step 1.1 as the input parameter and puts the message type determined in the step 1.1 into the message attribute of the message content;
step 1.3: in the message sending method, the input parameter is checked first, and the message content prepared in step 1.1 is put into the message body.
Preferably, when the message type determined in step 1.1 is an asynchronous communication scenario type with no sequence requirement, step 1 further includes the following steps for continuing step 1.3:
step 1.4: assembling the message body and the message attribute into a complete message and sending the complete message to a queue; completing message sending;
correspondingly, the step 2 comprises the following steps:
step 2.1: a plurality of consumption terminals receive and consume the message contents in the queue; analyzing to obtain a message body and message attributes;
step 2.2: the consumption end determines that the current message type is an asynchronous communication scene type without a sequence requirement based on the message attribute, so that the subsequent consumption processing is directly carried out without managing the sequence problem of the messages; and the consumer end completes message processing.
Preferably, when the message type determined in step 1.1 is a processing scenario type based on a recently sent message, step 1 includes the following steps for continuing step 1.3:
step 1.4: randomly generating a unique and non-repetitive data A; the production end adds a queue name to a fixed prefix to be called key, a set assignment method of Redis is called, and the value of the key is set as data A;
step 1.5: the production end repeats the steps 1.1 to 1.3, randomly generates a unique and non-repetitive data B, calls a set assignment method of Redis by adding a queue name to a fixed prefix to be called as a key, sets the value of the key as the data B, and puts the current message type, the key value key for identifying the current service sending data and the identification data B into the message attribute; assembling the message body and the message attribute into a complete message and sending the complete message to a queue;
correspondingly, the step 2 comprises the following steps:
step 2.1: the consumption end receives the message content in the consumption queue, acquires the message attribute of the message content, and acquires the processing scene type based on the message attribute, wherein the message type is based on the recently sent message; removing Redis according to the key, obtaining a storage field in the message by a get method, and comparing the storage field with an identification character string sent from the message attribute;
step 2.2: if the data B acquired in Redis is inconsistent with the data A sent in the message attribute, the consumption end knows that the message is not the latest message, directly terminates the processing flow and does not execute the subsequent flow;
step 2.3: and if the data B acquired in the Redis is consistent with the data B transmitted in the message attribute in comparison, the consumer knows that the message is the latest transmitted message and carries out the subsequent processing flow.
Preferably, when the message type determined in step 1.1 is a scene type processed according to the message sending sequence; step 1 comprises the following steps for continuing said step 1.3:
step 1.4: randomly generating a unique and non-repetitive character string A, calling a 1push method of Redis by using a fixed prefix and a queue name as a List at a production end, and placing the character string A into the head of the Redis queue List;
step 1.5: the production end puts the message type, the key value key for identifying the current sending data of the service and the identification character string A into the message attribute; the message body and the message attribute are assembled into a complete message and are sent to a queue;
step 1.6: the production end repeatedly executes the flow from the step 1.1 to the step 1.5 and sends a same message, wherein the data of the message attribute comprises a message type, a key and a character string B;
correspondingly, the step 2 comprises the following steps:
step 2.1: the consumption end receives and consumes the message content in the queue and obtains the attribute value in the message attribute; determining the message type in the message attribute as a scene type processed according to the message sending sequence, removing Redis according to the List, and acquiring a data item at the tail of the List queue in the Redis by a method of LLEn and LINDEX;
step 2.2: if the character string B sent from the message attribute is inconsistent with the character string A of the queue tail field obtained from Redis, returning the message to the delay queue; if the comparison is consistent, the consumption end calls an Rtop method of Redis, the tail element character string A in the queue is removed, and the consumption end carries out subsequent processing flow.
Preferably, when the message type determined in step 1.1 is a scene type processed according to the message sending sequence, the message in the delay queue is returned in step 2.2, and the message is returned to the normal queue after a preset time, and the consuming end repeatedly executes steps 2.1 to 2.2 until the message is consumed completely.
Preferably, the data a and the data B may be character strings, numbers, dates, lists and the like.
In summary, due to the adoption of the technical scheme, the invention has the beneficial effects that: 1. the invention processes the message based on the message type by defining the message type and the consuming terminal, thereby solving the problems of sequential consumption in the scene of the message sequential consumption requirement and avoiding the data or state error caused by the phenomenon that the message is sent first and then is consumed out of order.
2. The invention supports a plurality of scenes, including asynchronous communication scene types without sequence requirements, processing scene types based on recently sent messages and scene types processed according to message sending sequences, and users can flexibly select a mode according to the requirements of specific services so as to deal with complicated and changeable service scenes.
3. The invention realizes atomic operation under the condition of ensuring efficiency by means of a distributed cache type database redis which is a single-thread cache database with improved performance, and avoids concurrent processing interference.
Drawings
The invention will now be described, by way of example, with reference to the accompanying drawings, in which:
FIG. 1 is a flow chart of the asynchronous communication scenario type without sequence requirements of the present invention.
FIG. 2 is a flowchart of the present invention for processing types of scenarios based on recently sent messages.
FIG. 3 is a flow chart of the scene type processing in message sending order of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. The components of embodiments of the present application, generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the present application, presented in the accompanying drawings, is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, shall fall within the protection scope of the present application.
The following describes an embodiment of the present invention in detail with reference to fig. 1 to 3;
a method for guaranteeing message sequential consumption in asynchronous communication, referring to fig. 1, the processing steps of asynchronous communication scene type without sequential requirement are as follows:
step 1: the production end prepares the message content to be sent, defines the message type and puts the message type into the message attribute; sending the data to a consumer;
the method specifically comprises the following steps:
step 1.1: a production end prepares a Message content Message to be sent, a Message Queue to be delivered and a Message type 'NoOrderType' corresponding to a current service scene;
step 1.2: the production end takes the data prepared in the step 1.1 as a reference, and puts the Message type 'NoOrderType' determined in the step 1.1 into the Message Property of the Message content Message;
step 1.3: in the Message sending method, firstly, the input parameter data is checked, and the Message content Message prepared in the step 1.1 is put into the Message Body;
step 1.4: assembling the message Body and the message Property into a complete message and sending the complete message to a Queue; completing message sending;
step 2: the consumer processes the message based on the message type.
Specifically, the step 2 includes the following steps:
step 2.1: a plurality of consumption terminals receive and consume Message contents messages in the Queue; analyzing to obtain a message Body and a message attribute Property;
step 2.2: the consumption end determines that the current message type is an asynchronous communication scene type 'NoOrderType' without a sequence requirement based on the message Property, and directly performs the following consumption treatment without managing the sequence problem of the messages; and the consumer end completes message processing.
Referring to fig. 2, when the message type is a processing scenario type based on a recently sent message, the processing steps are as follows:
step 1: the production end prepares the message content to be sent, defines the message type and puts the message type into the message attribute; sending the data to a consumer;
specifically, the step 1 includes the following steps:
step 1.1: a production end prepares Message content Message needing to be sent, a Message Queue needing to be delivered and a Message type 'the LatestType' corresponding to a current service scene; "TheLatestType" is a processing scene type based on the most recently sent message;
step 1.2: the production end takes the data prepared in the step 1.1 as a reference, and puts the Message type 'TheLatestType' determined in the step 1.1 into the Message Property of the Message content Message;
step 1.3: in the Message sending method, the incoming parameter is checked first, and the Message content Message prepared in step 1.1 is put into the Message Body.
Step 1.4: if the production end judges that the message type is 'the LatestType', a unique and non-repetitive character string ValueA is randomly generated; the production end adds a queue name to a fixed prefix 1 to be called key, calls a set assignment method of Redis, and sets the value of the key as a character string ValueA;
step 1.5: the production end repeats the steps 1.1 to 1.3, randomly generates a unique non-repeated character string ValueB, adds a queue name to a fixed prefix and is called key, calls a set assignment method of Redis, sets the value of the key as the character string ValueB, and puts the current message type, the key value for identifying the current data sent by the service and the identification character string ValueB into the message attribute; assembling the message body and the message attribute into a complete message and sending the complete message to a queue;
step 2: the consumer processes the message based on the message type.
The step 2 comprises the following steps:
step 2.1: the consumption end receives the Message content Message in the consumption Queue, acquires the Message attribute Property of the Message content Message, and acquires the processing scene type 'TheLatestType' with the Message type based on the Message attribute Property, wherein the Message type is based on the recently sent Message; according to the key to remove Redis, obtaining a storage field in the key by a get method, and comparing the storage field with an identification character string sent from the message Property;
step 2.2: if the value B acquired in Redis is inconsistent with the value A transmitted in the message attribute, the consumption end knows that the message is not the latest message, directly terminates the processing flow and does not execute the subsequent flow;
step 2.3: if the value b obtained in the Redis is consistent with the value b sent in the message attribute, the consumer knows that the message is the latest message, and performs the subsequent processing flow.
Referring to fig. 3, when the message type is a scene type processed in a message transmission order, the following processing steps are included:
step 1: the production end prepares the message content to be sent, defines the message type and puts the message type into the message attribute; sending the data to a consumer;
specifically, the step 1 includes the following steps:
step 1.1: a production end prepares a Message content Message to be sent, a Message Queue to be delivered and a Message type 'InOrderType' corresponding to a current service scene; "InOrderType" is the scene type processed in the order of message sending;
step 1.2: the production end takes the data prepared in the step 1.1 as a reference, and puts the Message type 'TheLatestType' determined in the step 1.1 into the Message Property of the Message content Message;
step 1.3: in the Message sending method, the incoming parameter is checked first, and the Message content Message prepared in step 1.1 is put into the Message Body.
Step 1.4: the production end judges that the self-defined message type is 'InOrderType', randomly generates a unique non-repetitive character string Item1, calls a 1push method of Redis by taking a fixed prefix and a queue name as List, and puts Item1 into the head of the Redis queue List;
step 1.5: the production end puts the message type 'InOrderType', a key value key for identifying the currently sent data of the service and an identification character string Item1 into the message Property; assembling the message Body and the message Property into a complete message and sending the complete message to a Queue;
step 1.6: the production end repeatedly executes the flow from the step 1.1 to the step 1.5 and sends a same message, wherein the data of the message attribute comprises the message type, the key and the character string Item 2;
step 2: the consumer processes the message based on the message type.
The step 2 comprises the following steps:
step 2.1: the consumption end receives and consumes the Message content Message in the Queue, and obtains the attribute value in the Message attribute Property; determining that the message type in the message Property is a scene type 'InOrderType' processed according to the message sending sequence, removing Redis according to the List, and acquiring a data item at the tail of the List queue in the Redis by a method of LLEn and LINDEX;
step 2.2: if the Item2 sent from the message Property is inconsistent with the queue end field Item1 obtained from Redis, returning the message to the delay queue; if the comparison is consistent, the consumption end calls an Rtop method of Redis, the last element Item1 in the queue is removed, and the consumption end carries out subsequent processing flow.
Preferably, when the message type determined in step 1.1 is a scene type processed according to the message sending sequence, the message in the delay queue is returned in step 2.2, and the message is returned to the normal queue after a preset time, and the consuming end repeatedly executes steps 2.1 to 2.2 until the message is consumed completely.
The above-mentioned embodiments only express the specific embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present application. It should be noted that, for those skilled in the art, without departing from the technical idea of the present application, several changes and modifications can be made, which are all within the protection scope of the present application.
Claims (10)
1. A method for ensuring sequential consumption of messages in asynchronous communications, comprising the steps of:
step 1: the production end prepares the message content to be sent, defines the message type and puts the message type into the message attribute; sending the data to a consumer;
step 2: the consumer processes the message based on the message type.
2. The method of claim 1, wherein the message types include asynchronous communication scene type without sequence requirement, processing scene type based on the most recently sent message, and processing scene type according to the message sending sequence.
3. The method of claim 2, wherein the step 1 comprises:
step 1.1: a production end prepares message content to be sent, a message queue to be delivered and a message type corresponding to a current service scene;
step 1.2: the production end takes the data prepared in the step 1.1 as the input parameter and puts the message type determined in the step 1.1 into the message attribute of the message content;
step 1.3: in the message sending method, the input parameter is checked first, and the message content prepared in step 1.1 is put into the message body.
4. The method as claimed in claim 3, wherein when the message type determined in step 1.1 is the asynchronous communication scene type without sequence requirement, the step 1 further comprises the following steps for continuing step 1.3:
step 1.4: assembling the message body and the message attribute into a complete message and sending the complete message to a queue; the message transmission is completed.
5. The method of claim 4, wherein the step 2 comprises the steps of:
step 2.1: a plurality of consumption terminals receive and consume the message contents in the queue; analyzing to obtain a message body and message attributes;
step 2.2: the consumption end determines that the current message type is an asynchronous communication scene type without a sequence requirement based on the message attribute, so that the subsequent consumption processing is directly carried out without managing the sequence problem of the messages; and the consumer end completes message processing.
6. A method as claimed in claim 3, wherein when the message type determined in step 1.1 is a processing scenario type based on the most recently sent message, said step 1 comprises the following steps for continuing step 1.3:
step 1.4: randomly generating a unique and non-repetitive data A; the production end adds a queue name to a fixed prefix to be called key, a set assignment method of Redis is called, and the value of the key is set as data A;
step 1.5: the production end repeats the steps 1.1 to 1.3, randomly generates a unique and non-repetitive data B, calls a set assignment method of Redis by adding a queue name to a fixed prefix to be called as a key, sets the value of the key as the data B, and puts the current message type, the key value key for identifying the current service sending data and the identification data B into the message attribute; and assembling the message body and the message attribute into a complete message and sending the complete message to the queue.
7. The method of claim 6, wherein the step 2 comprises the steps of:
step 2.1: the consumption end receives the message content in the consumption queue, acquires the message attribute of the message content, and acquires the processing scene type based on the message attribute, wherein the message type is based on the recently sent message; removing Redis according to the key, obtaining a storage field in the message by a get method, and comparing the storage field with an identification character string sent from the message attribute;
step 2.2: if the data B acquired in Redis is inconsistent with the data A sent in the message attribute, the consumption end knows that the message is not the latest message, directly terminates the processing flow and does not execute the subsequent flow;
step 2.3: and if the data B acquired in the Redis is consistent with the data B transmitted in the message attribute in comparison, the consumer knows that the message is the latest transmitted message and carries out the subsequent processing flow.
8. The method of claim 3, wherein when the message type determined in step 1.1 is a scene type processed according to the message sending sequence; step 1 comprises the following steps for continuing said step 1.3:
step 1.4: randomly generating a unique and non-repetitive character string A, calling a 1push method of Redis by using a fixed prefix and a queue name as a List at a production end, and placing the character string A into the head of the Redis queue List;
step 1.5: the production end puts the message type, the key value key for identifying the current sending data of the service and the identification character string A into the message attribute; the message body and the message attribute are assembled into a complete message and are sent to a queue;
step 1.6: and the production end repeatedly executes the flow from the step 1.1 to the step 1.5 and sends a same message, wherein the data of the message attribute comprises the message type, the key and the character string B.
9. The method of claim 8, wherein the step 2 comprises the steps of:
step 2.1: the consumption end receives and consumes the message content in the queue and obtains the attribute value in the message attribute; determining the message type in the message attribute as a scene type processed according to the message sending sequence, removing Redis according to the List, and acquiring a data item at the tail of the List queue in the Redis by a method of LLEn and LINDEX;
step 2.2: if the character string B sent from the message attribute is inconsistent with the character string A of the queue tail field obtained from Redis, returning the message to the delay queue; if the comparison is consistent, the consumption end calls an Rtop method of Redis, the tail element character string A in the queue is removed, and the consumption end carries out subsequent processing flow.
10. The method as claimed in claim 9, wherein when the message type determined in step 1.1 is a scene type processed according to the message sending sequence, the message in the delay queue in step 2.2 is returned to the normal queue after a preset time, and the consuming end repeatedly executes steps 2.1 to 2.2 until the message is completely consumed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111144387.4A CN113900835A (en) | 2021-09-28 | 2021-09-28 | Method for guaranteeing message sequential consumption in asynchronous communication |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111144387.4A CN113900835A (en) | 2021-09-28 | 2021-09-28 | Method for guaranteeing message sequential consumption in asynchronous communication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113900835A true CN113900835A (en) | 2022-01-07 |
Family
ID=79189012
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111144387.4A Pending CN113900835A (en) | 2021-09-28 | 2021-09-28 | Method for guaranteeing message sequential consumption in asynchronous communication |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113900835A (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11055027B1 (en) * | 2019-11-15 | 2021-07-06 | Rapid7, Inc. | Dynamic queue management |
-
2021
- 2021-09-28 CN CN202111144387.4A patent/CN113900835A/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11055027B1 (en) * | 2019-11-15 | 2021-07-06 | Rapid7, Inc. | Dynamic queue management |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103345420B (en) | Batch calls the mthods, systems and devices of api interface | |
| CN111555963B (en) | Message pushing method and device, electronic equipment and storage medium | |
| CN111045806A (en) | Method and system for realizing delay message queue | |
| CN108322437B (en) | Adaptive communication method and device for multiple protocol devices | |
| CN111447257A (en) | Message conversion method and device | |
| CN105100250A (en) | Message distribution method, message distribution server and message distribution system | |
| CN112702259A (en) | Delayed message pushing method and device and message middleware | |
| CN111124717A (en) | Message delivery method, system and computer storage medium | |
| CN114915652B (en) | Message pushing method and device, electronic equipment and storage medium | |
| CN113900835A (en) | Method for guaranteeing message sequential consumption in asynchronous communication | |
| CN113783913A (en) | Message pushing management method and device | |
| CN114221925B (en) | Message pushing method and device, electronic equipment and storage medium | |
| CN113783773B (en) | Message scheduling method and system | |
| CN114339637B (en) | Short message splicing method, device, equipment and storage medium | |
| CN112241621A (en) | Method and device for identifying client environment through user agent | |
| CN112738823B (en) | Interface data interaction method, distributed unit and central unit | |
| CN112202914B (en) | Message pushing method and device | |
| CN112968825B (en) | Message sending method, device, equipment and storage medium | |
| US9160811B2 (en) | Client provisioning with enhanced linking | |
| CN112181672B (en) | Block chain data processing method, block chain system and computer storage medium | |
| CN114897532A (en) | Operation log processing method, system, device, equipment and storage medium | |
| CN112287236A (en) | Text message pushing method and device, computer equipment and storage medium | |
| CN113556370A (en) | Service calling method and device | |
| CN113115337B (en) | MIMO-based 5G multimode terminal transmission control method and device | |
| CN112162872A (en) | Message processing method and device, storage medium and electronic device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |