CN111464621B - Method for detecting message sending and receiving quantity in asynchronous communication of distributed system - Google Patents
Method for detecting message sending and receiving quantity in asynchronous communication of distributed system Download PDFInfo
- Publication number
- CN111464621B CN111464621B CN202010237688.0A CN202010237688A CN111464621B CN 111464621 B CN111464621 B CN 111464621B CN 202010237688 A CN202010237688 A CN 202010237688A CN 111464621 B CN111464621 B CN 111464621B
- Authority
- CN
- China
- Prior art keywords
- message
- message queue
- counter
- consumer
- sender
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- 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/547—Messaging middleware
-
- 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)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention relates to a method for detecting the quantity of sent and received messages in asynchronous communication of a distributed system, which comprises the following steps: A. the sending party generates a message to be sent and sends the message and the current date to a prepared message queue; setting a counter in a Redis database; B. the sender sends the message queue to the consumer through the message middleware, the message middleware returns a success identifier to the sender, and the sender counts the counter by + 1; C. after the consumer normally finishes consuming the message, counting-1 by the counter, and deleting the message which finishes consuming from the message queue; D. and setting a detection task, detecting the count value of the date appointed by the task detection counter and the residual messages in the message queue, and if abnormal data exist, notifying related personnel to carry out early warning prompt. The invention can simply and effectively detect whether the number of the messages sent by the sender is consistent with the number of the messages consumed by the consumer.
Description
Technical Field
The invention relates to a method for detecting message reliability in communication, in particular to a method for detecting the quantity of sent and received messages in asynchronous communication of a distributed system.
Background
In many large internet companies today, distributed systems are mostly used for communication. In the communication process, decoupling operation needs to be carried out on the distributed system, and the simplest decoupling operation is to disassemble several independent modules from the existing system and deploy the modules in different machines. Many common problems arise, one of the most troublesome of which is the problem of how to make module calls between different systems.
The call is divided into synchronous call and asynchronous call according to different instantaneity. The understanding of synchronous call and asynchronous call can be illustrated by taking telephone call and text message as examples. When the user carries out telephone communication with a person, the calling is real-time, and after one party speaks, the other party can receive the call and respond; when sending short message, the other party will respond a little bit. Moreover, generally, people can only carry out real-time conversation with one person, other people can be busy when the people enter the conversation, and the short messages can receive a plurality of short messages at the same time and gradually return the messages without the condition.
Therefore, the advantages and disadvantages of synchronous call and asynchronous call are also obvious, asynchronous call can process a large number of requests at the same time, the dependency of the flow between systems is reduced, the occurrence of system blocking is avoided, and due to the advantages, the asynchronous call is applied in a large number. However, the asynchronous call also has a disadvantage that the robustness of communication is poor, because of the delay characteristic of the asynchronous call, a sender does not know whether a message is accurately delivered to a consumer on time after sending the message, and if the message is lost due to extreme scenes, such as network reasons, process crash and the like, in the communication process, the consumer never perceives the existence of the lost message. The system faults include benign errors (process crash, node crash, network fault), Byzantine (Byzantine) faults: faults occur in a random manner, such as bugs, are trapped and send data to the correct process/node in any manner, preventing the correct process. In the method, only how to ensure that the asynchronous message is not lost under the condition of benign errors is considered, or if the message is lost due to faults, early warning can be timely sent out, so that manual intervention processing is carried out, and the errors are prevented from being reserved and spread.
The most common asynchronous communication mode in the industry at present is realized by message middleware, such as message middleware of RabbitMq, ActiveMq, Kafka and the like, the message consistency is usually ensured by the function provided by the message middleware, the message can be ensured to be persisted at a message middleware server, and the message is ensured to be delivered to a consumer by a delivery-confirmation mechanism (ack mechanism), but if the message middleware has problems or network faults, the loss of the message cannot be completely avoided. In addition, in the actual service processing scenario, the message needs to distinguish different service times, there is a mechanism for initiating daily switching in the service system every day, and the daily switching time is different from the natural time, for example, the system switches from No. 2 to No. 3 in early morning 00:30 of No. 3. In the period of the final day, messages in different time periods (two days before and after) may be mixed in the same message queue, and a consumer cannot confirm whether all the messages in a certain time period are processed under the condition of shielding messages in other time periods.
Disclosure of Invention
The invention provides a method for detecting the number of messages sent and received in asynchronous communication of a distributed system, which can detect whether the number of messages sent by a sender is consistent with the number of messages consumed by consumers or not and ensure the integrity of data.
The invention discloses a method for detecting the number of messages sent and received in asynchronous communication of a distributed system, which comprises the following steps:
A. the sending party generates a message to be sent and sends the message and the current date to a prepared message queue; setting a counter in a Redis database system;
B. the sender sends the message queue to the consumer through the message middleware, after the message middleware successfully sends the message queue to the consumer, the message middleware returns a success identifier to the sender, and the sender calls an incr atomic counting method of a Redis database system to count the counter by + 1;
C. the consumer receives the message queue and begins to consume the messages in the message queue, if the consumption is normally finished, the consumer calls an incr atomic counting method of a Redis database system to count-1 of the counter, and the message which is finished to consume is deleted from the message queue;
D. setting a detection task, detecting the count value of the counter on the appointed date and the rest messages in the message queue through the detection task, and if the count value of the counter is not equal to 0 or the rest messages exist in the message queue when the detection task is executed, notifying related personnel of early warning prompt.
The counter counts +1 after the sender successfully sends the message, and the counter counts-1 after the consumer consumes the corresponding message, so that whether the number of the messages sent by the sender is consistent with the number of the messages consumed by the consumer is simply and effectively detected.
Further, in step a, the sender encapsulates the message content to be sent in the message into a message body, encapsulates the current date and the randomly generated unique message ID into the message attribute corresponding to the message body, and then assembles the message body and the message attribute into a complete message to be sent to the message queue.
On the basis, in order to clearly distinguish and count various messages, in the step a, a key1 which takes a fixed prefix 1+ a message queue name + a current date as a counter in a Redis database system as a sender is further included, and the key1 is packaged into the message attribute; setting an initial value of a counter in the Redis database system to be 0, setting the key1 and the initial value as a group of key-value pairs, and storing the key1 and the initial value pairs in a storage space of the Redis database system;
in step B, after the message middleware returns a success identifier to the sender, the sender calls an incr atomic counting method of the Redis database system, and counts +1 in the counter correspondingly according to key 1.
Correspondingly, in the step C, after receiving the message queue, the consumer analyzes and consumes the message according to the assembly format of the message, if the consumption is normally finished, the consumer calls an incr atomic counting method of the Redis database system, the fixed prefix 1+ the message queue name + the current date analyzed from the message attribute are used as the key1 of the counter, and the count-1 of the counter corresponding to the key1 is counted in the storage space of the Redis database system.
Step D, the detection task acquires a message queue name list needing to detect whether abnormal data exists or not through configuration, the detection task sequentially takes out each message queue name according to the message queue name list, then takes a fixed prefix 1+ a message queue name + a date as a key3 recorded by a detection counter, acquires a count value of the counter taking a key3 as a key from a storage space of a Redis database system, and if the count value is not equal to 0, the count value indicates that a message sent by a producer in the detected date is not consumed by a consumer, and informs related personnel of early warning prompt; the keys 3 have different values according to different detection dates, but each key3 is the same as the key1 on the day of the detection date.
Further, step a includes encapsulating, by the sender, the key2 into the message attribute with a fixed prefix 2+ message queue name + current date + unique message ID as key 2;
in step B, after the message middleware returns a successful identifier to the sender, the consumer adds a key2 as a new key in the storage space of the Redis database system, and the value of the key-value pair record is the key-value pair record of the message body analyzed by the consumer.
Correspondingly, the step C of deleting the message completing the consumption from the message queue is that the consumer deletes the data item with the key of 2 in the storage space of the Redis database system according to the fixed prefix 2+ the message queue name + the current date + the unique message ID parsed from the received message attribute as the key 2.
Step D, the detection task acquires a message queue name list needing to detect whether abnormal data exists or not through configuration, searches a matched key in a storage space of the Redis database system by taking a fixed prefix 2+ a message queue name + a date + a wildcard character as a key4, takes out a data item corresponding to the key, and informs related personnel of warning prompt, wherein the data item is data which is successfully sent to a message middleware by a sender in the detected date but is not successfully consumed by a consumer; the keys 4 have different values according to different detection dates, but each key4 is the same as the key2 of the current day of the detection date.
Optionally, there are at least two sending parties in step a, and the types of the generated messages are the same, and all the sending parties correspond to the same message queue. The messages of the same type mean that the structure of each message is consistent with the corresponding message queue, and only the content of the message is different. For example, all messages are of the deposit type, except that the depositor and deposit amount are different, and the other information is consistent. The same type of message means that the messages can be put together for counting, and the messages of different types need a plurality of counters for counting respectively.
Optionally, there are at least two consumers in step B, and all consumers correspond to the same message queue.
The beneficial effects of the invention include:
1. all scenarios requiring message delivery/reception through message middleware can be completed using the same component support without special processing for specific business programs.
2. The storage of the counter and the message content is realized by using a distributed cache Redis database, the Redis database is processed by a single thread, and the counting error caused by adding/subtracting calculation by a plurality of requests can be avoided. Meanwhile, the Redis database has high performance and cannot influence the service processing efficiency. Even if an exception occurs in the processing part of the Redis database, the normal delivery message cannot be influenced.
3. The problem that whether the number of the messages sent by the sender is consistent with the number consumed by the consumers or not under the condition that the total number of the messages sent is unknown can be effectively solved.
4. In some scenarios, such as the credit consumption system, after the date is switched, the end-of-day batch processing needs to wait for all the services in the previous day to be processed before the batch processing can be executed. The invention can detect whether all messages are completely consumed without missing in a specific time period (such as the day) and can not be disturbed by the service occurring in the next day.
The present invention will be described in further detail with reference to the following examples. This should not be understood as limiting the scope of the above-described subject matter of the present invention to the following examples. Various substitutions and alterations according to the general knowledge and conventional practice in the art are intended to be included within the scope of the present invention without departing from the technical spirit of the present invention as described above.
Drawings
Fig. 1 is a flow chart of a method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to the present invention.
Detailed Description
As shown in fig. 1, the method for detecting the number of messages sent and received in asynchronous communication in a distributed system of the present invention includes:
A. the sender generates a message to be sent and prepares a message Queue for loading the message. The sender packages the message content to be sent in the message into a message body, and packages the key1, the current date1 and a randomly generated unique message ID into a message attribute corresponding to the message body by using a fixed prefix 1, a message queue name and the current date as a key1 of a counter in a Redis database system. Setting a counter in the Redis database system, setting an initial value of the counter to be 0, and setting the key1 and the initial value as a group of key-value pairs to be stored in a storage space of the Redis database system.
The sender encapsulates the key2 into the message attribute with the fixed prefix 2+ message queue name + current date1+ unique message ID as key 2.
And assembling the message body and the message attribute into a complete message and sending the complete message to the message Queue.
B. And the sender sends the message queue to the consumer through the message middleware, after the message middleware successfully sends the message queue to the consumer, the message middleware returns a success identifier to the sender, the sender calls an incr atomic counting method of the Redis database system, and the corresponding count in the counter is counted by +1 according to key 1. And the consumer adds a key2 as a new key in the storage space of the Redis database system, and the value is the key-value pair record of the message body analyzed by the consumer.
When there are multiple senders and each sender sends the same type of message, the accumulation of key1 in the counter is the number of successfully sent messages, and each message is distinguished by the unique message ID in key2 and kept as a different record.
C. And the consumer receives the message queue, analyzes the message according to the message assembly format and starts consuming the message in the message queue. If the consumption is completed normally, the consumer calls an incr atomic counting method of the Redis database system, takes the fixed prefix 1+ the message queue name + the current date1 parsed from the message attribute as the key1 of the counter, and counts-1 of the counter corresponding to the key1 in the storage space of the Redis database system. And the fixed prefix 2+ the message queue name + the current date1+ the unique message ID parsed from the received message attributes is used as key2, and the data item with the key2 is deleted in the storage space of the Redis database system.
D. And setting a daily detection task, and detecting the current count value of the counter and the rest messages in the message queue through the detection task. The detection task acquires a message queue name list needing to detect whether abnormal data exists or not through configuration, the detection task sequentially takes out each message queue name according to the message queue name list, then takes a fixed prefix 1+ a message queue name + a date as a key3 recorded by a detection counter, acquires a count value of the counter with a key3 as a key from a storage space of a Redis database system, and if the count value is not equal to 0 (usually more than 0), the detection task indicates that a message sent by a producer in the detected date is not consumed by a consumer, and informs related personnel of early warning and prompting. The keys 3 have different values according to different detection dates, but each key3 is the same as the key1 on the day of the detection date.
And the detection task also uses a fixed prefix 2+ a message queue name + a date1+ a wildcard character as a key4 to search a matched key in a storage space of the Redis database system, and takes out a data item corresponding to the key, wherein the data item is data which is successfully sent to the message middleware by a sender in the detected date but is not successfully consumed by a consumer, and informs related personnel of early warning prompt. The keys 4 have different values according to different detection dates, but each key4 is the same as the key2 on the day of the detection date.
The related personnel processes the lost data according to the error abnormal reason and the service, for example, the lost data can be directly retransmitted and processed, and the data processing can be modified according to the data content.
Claims (10)
1. The method for detecting the quantity of the sent and received messages in the asynchronous communication of the distributed system is characterized by comprising the following steps:
A. the sending party generates a message to be sent and sends the message and the current date to a prepared message queue; setting a counter in a Redis database system;
B. the sender sends the message queue to the consumer through the message middleware, after the message middleware successfully sends the message queue to the consumer, the message middleware returns a success identifier to the sender, and the sender calls an incr atomic counting method of a Redis database system to count the counter by + 1;
C. the consumer receives the message queue and begins to consume the messages in the message queue, if the consumption is normally completed, the consumer calls an incr atomic counting method of a Redis database system to count-1 of the counter, and the message of which the consumption is completed is deleted from the message queue;
D. and setting a detection task, detecting the count value of the counter on the appointed date and the rest messages in the message queue through the detection task, and if the count value of the counter is not equal to 0 when the detection task is executed, notifying related personnel of early warning prompt.
2. The method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 1, wherein: in step A, a sender packages the message content to be sent in the message into a message body, packages the current date and the unique message ID generated randomly into the message attribute corresponding to the message body, and then assembles the message body and the message attribute into a complete message to be sent to a message queue.
3. The method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 2, wherein: step A, a key1 of a counter in a Redis database system is used by a sender by taking a fixed prefix 1+ a message queue name + a current date, and the key1 is encapsulated into the message attribute; setting an initial value of a counter in the Redis database system to be 0, setting the key1 and the initial value as a group of key-value pairs, and storing the key1 and the initial value pairs in a storage space of the Redis database system;
in step B, after the message middleware returns a success identifier to the sender, the sender calls an incr atomic counting method of the Redis database system, and counts +1 in the counter correspondingly according to key 1.
4. A method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 3, characterized in that: in the step C, after receiving the message queue, the consumer analyzes and consumes the message according to the assembly format of the message, if the consumption is normally finished, the consumer calls an incr atomic counting method of the Redis database system, the fixed prefix 1+ the message queue name + the current date analyzed from the message attribute are used as the key1 of the counter, and the count-1 of the counter corresponding to the key1 is counted in the storage space of the Redis database system.
5. A method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 3, characterized in that: step D comprises the steps that the detection task acquires a message queue name list needing to detect whether abnormal data exists or not through configuration, the detection task sequentially takes out each message queue name according to the message queue name list, then takes a fixed prefix 1+ a message queue name + a date as a key3 recorded by a detection counter, acquires a count value of the counter with the key3 as a key from a storage space of a Redis database system, and if the count value is not equal to 0, the detection task indicates that a message sent by a producer in the detected date is not consumed by a consumer, and informs related personnel of early warning prompt; the key3 is the same as the key1 of the day of the date detected.
6. The method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 2, characterized in that: step A, the method also comprises the step that a sender packs the key2 into the message attribute by taking the fixed prefix 2+ the message queue name + the current date + the unique message ID as the key 2;
in step B, after the message middleware returns a successful identifier to the sender, the consumer adds a key2 as a new key in the storage space of the Redis database system and records the key-value pair of the message body analyzed by the consumer as the value.
7. The method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 6, wherein: the step C of deleting the message with the consumption completed from the message queue is that the consumer deletes the data item with the key of 2 in the storage space of the Redis database system according to the fixed prefix 2+ the message queue name + the current date + the unique message ID parsed from the received message attribute as the key 2.
8. The method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 6, wherein: step D, the detection task acquires a message queue name list needing to detect whether abnormal data exists or not through configuration, the detection task uses a fixed prefix 2+ a message queue name + a date + a wildcard character as a key4 to search a matched key in a storage space of the Redis database system, and takes out a data item corresponding to the key, wherein the data item is data which is successfully sent to the message middleware by a sender in the detected date but unsuccessfully consumed by a consumer, and the data item informs related personnel of early warning prompt; the key4 is the same as the key2 of the day of the date detected.
9. Method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to one of claims 1 to 8, characterized in that: the step A has at least two sending sides, the types of the generated messages are the same, and all the sending sides correspond to the same message queue.
10. The method for detecting the number of messages sent and received in asynchronous communication in a distributed system according to claim 9, wherein: and B, at least two consumers are arranged, and all the consumers correspond to the same message queue.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010237688.0A CN111464621B (en) | 2020-03-30 | 2020-03-30 | Method for detecting message sending and receiving quantity in asynchronous communication of distributed system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010237688.0A CN111464621B (en) | 2020-03-30 | 2020-03-30 | Method for detecting message sending and receiving quantity in asynchronous communication of distributed system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111464621A CN111464621A (en) | 2020-07-28 |
| CN111464621B true CN111464621B (en) | 2022-06-24 |
Family
ID=71680116
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010237688.0A Active CN111464621B (en) | 2020-03-30 | 2020-03-30 | Method for detecting message sending and receiving quantity in asynchronous communication of distributed system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111464621B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112527521B (en) * | 2020-12-03 | 2023-07-04 | 中国联合网络通信集团有限公司 | Message processing method and device |
| CN112486707A (en) * | 2020-12-14 | 2021-03-12 | 中国人民银行清算总中心 | Redis-based message asynchronous consumption method and device |
| CN115802298B (en) * | 2022-10-31 | 2023-07-07 | 广州市玄武无线科技股份有限公司 | Method and system for processing short message submitting report and receipt report |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102668516A (en) * | 2011-12-02 | 2012-09-12 | 华为技术有限公司 | Method and apparatus for realizing message passing amid cloud information service |
| CN104092767A (en) * | 2014-07-21 | 2014-10-08 | 北京邮电大学 | Posting/subscribing system for adding message queue models and working method thereof |
| CN104731912A (en) * | 2015-03-24 | 2015-06-24 | 浪潮集团有限公司 | Message transmission method and device for message middleware MQ |
| GB201516102D0 (en) * | 2014-09-15 | 2015-10-28 | Ge Aviat Systems Llc | Mechanism and method for communication between a client and a server by accessing message data in a shared memory |
| CN105591877A (en) * | 2014-10-23 | 2016-05-18 | 阿里巴巴集团控股有限公司 | Method, device and system for service message transmission |
| CN107527171A (en) * | 2016-06-22 | 2017-12-29 | 阿里巴巴集团控股有限公司 | Realize system, method and the dispatch server and processing server of order management and control |
| CN107862082A (en) * | 2017-11-29 | 2018-03-30 | 努比亚技术有限公司 | High concurrent method of counting and web server based on MySQL counter tables |
| CN108881492A (en) * | 2018-08-08 | 2018-11-23 | 百卓网络科技有限公司 | A method of it solving Message Processing sequence and dredges Message Processing |
| CN110673965A (en) * | 2019-09-11 | 2020-01-10 | 杭州火小二科技有限公司 | Method and device for capturing second-killing commodities |
| CN110753129A (en) * | 2019-10-29 | 2020-02-04 | 深圳前海微众银行股份有限公司 | Message transmission method, system, device, equipment and computer readable storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7801120B2 (en) * | 2003-01-13 | 2010-09-21 | Emulex Design & Manufacturing Corporation | Method and system for efficient queue management |
-
2020
- 2020-03-30 CN CN202010237688.0A patent/CN111464621B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102668516A (en) * | 2011-12-02 | 2012-09-12 | 华为技术有限公司 | Method and apparatus for realizing message passing amid cloud information service |
| CN104092767A (en) * | 2014-07-21 | 2014-10-08 | 北京邮电大学 | Posting/subscribing system for adding message queue models and working method thereof |
| GB201516102D0 (en) * | 2014-09-15 | 2015-10-28 | Ge Aviat Systems Llc | Mechanism and method for communication between a client and a server by accessing message data in a shared memory |
| CN105591877A (en) * | 2014-10-23 | 2016-05-18 | 阿里巴巴集团控股有限公司 | Method, device and system for service message transmission |
| CN104731912A (en) * | 2015-03-24 | 2015-06-24 | 浪潮集团有限公司 | Message transmission method and device for message middleware MQ |
| CN107527171A (en) * | 2016-06-22 | 2017-12-29 | 阿里巴巴集团控股有限公司 | Realize system, method and the dispatch server and processing server of order management and control |
| CN107862082A (en) * | 2017-11-29 | 2018-03-30 | 努比亚技术有限公司 | High concurrent method of counting and web server based on MySQL counter tables |
| CN108881492A (en) * | 2018-08-08 | 2018-11-23 | 百卓网络科技有限公司 | A method of it solving Message Processing sequence and dredges Message Processing |
| CN110673965A (en) * | 2019-09-11 | 2020-01-10 | 杭州火小二科技有限公司 | Method and device for capturing second-killing commodities |
| CN110753129A (en) * | 2019-10-29 | 2020-02-04 | 深圳前海微众银行股份有限公司 | Message transmission method, system, device, equipment and computer readable storage medium |
Non-Patent Citations (1)
| Title |
|---|
| Flit Scheduling for Cut-Through Switching: Towards Near-Zero End-to-End Latency;Kyubo Shin等;《IEEE Access》;20190514;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111464621A (en) | 2020-07-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111464621B (en) | Method for detecting message sending and receiving quantity in asynchronous communication of distributed system | |
| US10528405B2 (en) | Methods, apparatus and computer programs for managing persistence | |
| US6617969B2 (en) | Event notification system | |
| US6970945B1 (en) | Systems and methods of message queuing | |
| CN106375458B (en) | Service calling system, method and device | |
| US6212268B1 (en) | Pre-scheduled callback service | |
| US8825798B1 (en) | Business event tracking system | |
| AU2007261542B2 (en) | Method and system for monitoring non-occurring events | |
| CN111045806A (en) | Method and system for realizing delay message queue | |
| US7590701B2 (en) | Apparatus and method for generating alert messages in a message exchange network | |
| US20020156601A1 (en) | Event monitoring and detection system | |
| CN110225109B (en) | Multi-queue data transmission method based on 'industrial and commercial connection' platform | |
| CN111030846A (en) | Block chain-based data uplink abnormal retry method | |
| CN111045837B (en) | Cross-service consumption method and storage medium | |
| CN112181627A (en) | Timing task scheduling method, device and system | |
| CN114443468A (en) | Excel table-based test comparison method and system | |
| US20040225546A1 (en) | Method and apparatus for monitoring business process flows within an integrated system | |
| WO2023147716A1 (en) | Flow control and billing methods, apparatuses and system, electronic device, medium and product | |
| CN111049730A (en) | RabbitMQ message retransmission and power of consumption idempotent solution method | |
| CN109634814A (en) | Fault early warning method, equipment, storage medium and device based on log stream | |
| JP5427497B2 (en) | Mail gateway | |
| WO2001033407A2 (en) | Systems and methods of message queuing | |
| CN109508356B (en) | Data abnormality early warning method, device, computer equipment and storage medium | |
| CN112232911A (en) | Asynchronous processing method and system for equity ordering | |
| CN111049723A (en) | Message pushing method, message management system, server and computer storage medium |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |