CN112199212A - Asynchronous notification method and system - Google Patents
Asynchronous notification method and system Download PDFInfo
- Publication number
- CN112199212A CN112199212A CN202011065831.9A CN202011065831A CN112199212A CN 112199212 A CN112199212 A CN 112199212A CN 202011065831 A CN202011065831 A CN 202011065831A CN 112199212 A CN112199212 A CN 112199212A
- Authority
- CN
- China
- Prior art keywords
- target data
- notification
- message
- failure
- component
- 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 35
- 238000012544 monitoring process Methods 0.000 claims abstract description 20
- 230000007246 mechanism Effects 0.000 claims description 8
- 230000000694 effects Effects 0.000 abstract description 3
- 238000012545 processing Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 238000003032 molecular docking Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000010355 oscillation 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
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2471—Distributed queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
- G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Fuzzy Systems (AREA)
- Computational Linguistics (AREA)
- Probability & Statistics with Applications (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the invention provides an asynchronous notification method, which comprises the following steps: the method comprises the following steps: the message sending component sends the target data acquired from the plurality of clients to the MQ cluster by calling an internal push service API (application program interface); step two: when the message sending component fails to send the target data to the MQ cluster, the system writes the target data into a failure data table; step three: when the message sending component successfully sends the target data to the MQ cluster, the message monitoring component pulls the target data in the MQ cluster; step four: when the URL address does not exist in a blacklist, the Notify notification component asynchronously notifies the target data to the user server; the embodiment of the invention realizes the effects of improving the performance and flexibly configuring the asynchronous callback notification function.
Description
Technical Field
The present invention relates to the field of communications technologies, and in particular, to an asynchronous notification method and system.
Background
With the development of the main business of a company, the functions of products are continuously increased and improved, and various interaction quantity with clients is continuously increased, wherein in the processing business, the asynchronous callback notifying the clients is a very important interaction means, so that a caller is definitely aware of the final result of the request.
Due to the development requirement of the service, it is necessary for the service side to notify the calling side of the user calling result, the existing technical scheme has single function and high coupling, and each service system needs to develop a set of notification callback system.
Summary of the invention
In order to overcome the shortcomings of the prior art, the invention provides an asynchronous notification method to solve the problem of how to improve the performance and how to notify flexible configuration.
The technical scheme adopted by the invention for solving the technical problems is as follows: an asynchronous notification method comprising the steps of:
the method comprises the following steps: the message sending component sends the target data acquired from the plurality of clients to the MQ cluster by calling an internal push service API (application program interface);
step two: when the message sending component fails to send the target data to the MQ cluster, the system writes the target data into a failure data table;
step three: when the message sending component successfully sends the target data to the MQ cluster, the message monitoring component pulls the target data in the MQ cluster;
step four: and when the URL address does not exist in the blacklist, the Notify notification component asynchronously notifies the target data to the user server.
Preferably, before the message sending component sends the target data obtained from the source end to the MQ cluster by calling the internal push service API interface, the steps further include:
the messaging component obtains the target data from the plurality of clients.
Preferably, before the Notify notification component does not Notify the user server when there is a URL address in the blacklist, the method further includes:
manually configuring the blacklist in advance, and specifying a specific URL address which is not notified;
or the system automatically adds the blacklist list, and when the URL address meets the passing rule, the URL address is listed as the blacklist.
Preferably, after the Notify notification component asynchronously notifies the user server of the target data, the method further includes:
the message monitoring component checks whether the URL address is in a failure data table;
when the URL address is checked to be in the failure data table, resetting the recorded failure times;
when the check URL address is not in the failure data table, no operation is performed.
Preferably, after the Notify notification component asynchronously notifies the user server of the target data, the method further includes:
when the Notify notification component asynchronously notifies the user server of the target data failure, the message monitoring component captures a failure message notification corresponding to the target data.
Preferably, after capturing a failure message notification corresponding to the target data, the message listening component further includes:
when the number of times of the failure message notification is the first time, writing the URL address corresponding to the failure message notification into the notification failure table, and +1 the number of times of the failure message notification;
and when the number of times of the failure message notification is not the first time, directly adding +1 to the number of times of the failure message notification.
Preferably, after capturing a failure message notification corresponding to the target data, the message listening component further includes:
a snoop message retry mechanism is initiated and repeated 5 times by default.
Preferably, after the system writes the target data into the failure data table, the steps further include:
and querying the failure data table by adopting an Elastic Job distributed timing mode.
Preferably, after querying the failure data table using Elastic Job distributed timing, the steps further include:
and calling the Notify notification component to asynchronously Notify the user server of the target data inquired from the failure data table.
An asynchronous notification system, the system comprising:
the sending unit is used for sending the target data acquired from the plurality of clients to the MQ cluster by the message sending component by calling an internal push service API (application program interface);
the writing unit is used for writing the target data into a failure data table by the system when the message sending component unsuccessfully sends the target data to the MQ cluster;
the pulling unit is used for pulling the target data in the MQ cluster by the message monitoring component when the message sending component successfully sends the target data to the MQ cluster;
and the notification unit is used for asynchronously notifying the target data to the user server by the Notify notification component when the URL address does not exist in the blacklist list.
The invention has the beneficial effects that: the message sending component sends the target data acquired from the plurality of clients to the MQ cluster by calling an internal push service API (application program interface); when the message sending component fails to send the target data to the MQ cluster, the system writes the target data into a failure data table; when the message sending component successfully sends the target data to the MQ cluster, the message monitoring component pulls the target data in the MQ cluster; when the URL address does not exist in a blacklist, the Notify notification component asynchronously notifies the target data to the user server; therefore, the effects of improving the performance and flexibly configuring the asynchronous callback notification function are achieved.
Drawings
Fig. 1 is a flow chart diagram of an asynchronous notification method.
FIG. 2 is a functional block diagram of an asynchronous notification system.
FIG. 3 is an asynchronous callback notification component deployment profile.
Fig. 4 is another flow diagram of an asynchronous notification method.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
The following detailed description of specific implementations of the present invention is provided in conjunction with specific embodiments:
the first embodiment is as follows:
fig. 1 shows an implementation flow of an asynchronous notification method provided in a first embodiment of the present invention, and for convenience of description, only the relevant parts related to the first embodiment of the present invention are shown, which are detailed as follows:
in step S101, the message sending component sends the target data obtained from the multiple clients to the MQ cluster by calling the internal push service API interface;
preferably, before the message sending component sends the target data obtained from the source end to the MQ cluster by calling the internal push service API interface, the steps further include:
the messaging component obtains the target data from the plurality of clients.
In step S102, step two: when the message sending component fails to send the target data to the MQ cluster, the system writes the target data into a failure data table;
preferably, before the Notify notification component does not Notify the user server when there is a URL address in the blacklist, the method further includes:
manually configuring the blacklist in advance, and specifying a specific URL address which is not notified;
or the system automatically adds the blacklist list, and when the URL address meets the passing rule, the URL address is listed as the blacklist.
In step S103, when the message sending component successfully sends the target data to the MQ cluster, the message monitoring component pulls the target data in the MQ cluster;
in step S104, step four: and when the URL address does not exist in the blacklist, the Notify notification component asynchronously notifies the target data to the user server.
Preferably, after the Notify notification component asynchronously notifies the user server of the target data, the method further includes:
the message monitoring component checks whether the URL address is in a failure data table;
when the URL address is checked to be in the failure data table, resetting the recorded failure times;
when the check URL address is not in the failure data table, no operation is performed.
Preferably, after the Notify notification component asynchronously notifies the user server of the target data, the method further includes:
when the Notify notification component asynchronously notifies the user server of the target data failure, the message monitoring component captures a failure message notification corresponding to the target data.
Preferably, after capturing a failure message notification corresponding to the target data, the message listening component further includes:
when the number of times of the failure message notification is the first time, writing the URL address corresponding to the failure message notification into the notification failure table, and +1 the number of times of the failure message notification;
and when the number of times of the failure message notification is not the first time, directly adding +1 to the number of times of the failure message notification.
Preferably, after capturing a failure message notification corresponding to the target data, the message listening component further includes:
a snoop message retry mechanism is initiated and repeated 5 times by default.
Preferably, after the system writes the target data into the failure data table, the steps further include:
and querying the failure data table by adopting an Elastic Job distributed timing mode.
Preferably, after querying the failure data table using Elastic Job distributed timing, the steps further include:
and calling the Notify notification component to asynchronously Notify the user server of the target data inquired from the failure data table.
It will be understood by those skilled in the art that all or part of the steps in the method for implementing the above embodiments may be implemented by relevant hardware instructed by a program, and the program may be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc.
Example two:
fig. 2 shows a structure of an asynchronous notification system provided in the second embodiment of the present invention, and for convenience of description, only the parts related to the second embodiment of the present invention are shown, which are detailed as follows:
the sending unit 201 is used for the message sending component to send the target data acquired from the plurality of clients to the MQ cluster by calling the internal push service API interface;
a writing unit 202, configured to, when the sending of the target data to the MQ cluster by the message sending component is unsuccessful, write the target data into a failure data table by the system;
the pulling unit 203 is configured to, when the message sending component successfully sends the target data to the MQ cluster, pull the target data in the MQ cluster by the message monitoring component;
a notifying unit 204, configured to Notify the user server asynchronously with the Notify notification component when the URL address does not exist in the blacklist.
In the embodiment of the application, a message sending component sends target data acquired from a plurality of clients to an MQ cluster by calling an internal push service API (application programming interface); when the message sending component fails to send the target data to the MQ cluster, the system writes the target data into a failure data table; when the message sending component successfully sends the target data to the MQ cluster, the message monitoring component pulls the target data in the MQ cluster; when the URL address does not exist in a blacklist, the Notify notification component asynchronously notifies the target data to the user server; thereby realizing the effects of improving the performance and flexibly configuring the asynchronous callback notification function; the detailed implementation of each unit can refer to the description of the first embodiment, and is not repeated herein.
Example three:
fig. 3 shows a deployment profile of an asynchronous callback notification component according to a third embodiment of the present invention, and for convenience of illustration, only the portions related to the third embodiment of the present invention are shown, where the deployment profile includes:
RMQ message sender component: each service group sends RMQ the callback notice to the message server through the interface provided by the application; RMQ message Server: all messages sent by the message sender are stored in the cluster of the server; RMQ a message listening component; and the message monitoring component acquires the MQ message and analyzes the message after receiving the message. Specifically, RMQ consumption client API is used to implement distributed listening messages, which are processed as soon as the MQ server has a new message; notify notification component: and externally accessing the application, and accessing the application to a server of the docking client through an http request to fulfill the aim of callback notification.
Example four:
fig. 4 is another schematic flow chart of an asynchronous notification method provided in the fourth embodiment of the present invention, and for convenience of description, only the parts related to the fourth embodiment of the present invention are shown, where the parts include:
firstly, each service group calls an internal message push service (internally using a dubbo technology) provided by the system, the required callback request information is sent to the RMQ server, other things are processed by the system execution scheme, and each service system is not considered any more.
If the message is sent successfully, the message is pushed RMQ to the server for subsequent processing. If the transmission is not successful, the notification message is recorded in a fault-tolerant database table and processed by a fault-tolerant processing mechanism.
After the message is pushed to the RMQ server, the message monitoring service will acquire the information recalled to the merchant, and perform the service processing: if the callback address is a blacklist, if so, not notifying, otherwise, performing callback notification; with the expansion of the service function, the system can add other service logic processing, such as wind control information, at any time.
When the merchant is informed of the request for the merchant callback address, there may be situations of access failure, such as: the callback address server of the merchant is down, the network oscillation request is overtime, and the like. The system will then by default repeat the notification 5 times at intervals (30 seconds, 1 minute, 2 minutes, 3 minutes, 4 minutes), any one of which is successful, the system considers that the notification is successful and clears the accumulated number of failed notifications, if not, the system will save the accumulated number of failed notifications to the database, up to 100 times (default 100, configurable) will automatically record into the blacklist and note the cause of the blacklist.
A polling task component: the polling task component is an executor of a fault-tolerant mechanism, data in a fault-tolerant table can be checked by the polling task component at regular intervals (default 3 seconds), messages are pushed unsuccessfully and are abnormally processed, supplementary notification is carried out, notification messages are not omitted, the notification messages are removed after the notification is finished, and next polling execution cannot be repeatedly processed.
If there is a failure in the notification process, it will be consistent with the processing business logic of step 4.
Detailed flow description:
and the message sending service receives the calling of the source service data and sends the message data to the MQ cluster.
If the message sending service fails to send the message, the system writes the request information into a message push failure database table (send _ err), and the subsequent fault-tolerant mechanism processes the request information.
After the message is successfully sent, the monitoring service pulls the pushed data in the MQ cluster.
And processing the pulled data. Specifically, firstly () whether there is the URL address information in the blacklist list, if there is the URL address information, no notification is performed, the task is ended, and the monitoring service notifies the MQ cluster that the message processing is completed. And if the blacklist does not exist, carrying out the next step, and starting to call a Notify component to carry out asynchronous callback. Data content in the black list: 1. configuring manually in advance, directly appointing concrete non-notification address, 2, automatically adding system notification strategy, when said notification address is continuous for 3 days, and continuously notifying for 100 times every day, and making said request address be black list
And the asynchronous callback component (Notify notification component) receives the notification calling information and notifies the message to the corresponding URL link address server through the https request.
If the notification service returns a success to the system, it indicates that the merchant has been successfully notified.
And the monitoring service informs the MQ cluster that the message processing is finished, and simultaneously checks whether the notification address appears in the notification failure table, if so, the recorded failure times are cleared, and if not, what is not done.
If the notification service returns an unsuccessful result, the listening service will treat the notification message as a notification failure message.
If the failure is the first failure, writing the failure into a failure notification table, and simultaneously notifying the failure times of +1, if the failure is the previous failure, directly notifying the failure times of + 1.
And starting a listening message retry mechanism at the same time, namely performing repeated notification, and repeating for 5 times by default.
If the notification is successful when the default number is not reached, the 8 th step will be returned to.
If the retries are not successful, step 11 is performed, and the listening service notifies the MQ cluster that the message is processed and exits the retries.
Message push failure fault tolerance mechanism processing flow:
the method adopts the Elastic Job distributed timing task and the database query mode, and because of the standby scheme, the method only triggers when the MQ sends a problem
And inquiring (send _ err) at intervals of 3 seconds to push a failure fault-tolerant table.
And directly calling a Notify component to perform asynchronous callback on the inquired data.
The callback result processing returned by the Notify component is then as logical as the processing of the listening service.
In addition, if the notification fails, the notification failure number +1 is recorded in the bar to prepare for polling and retry.
During which if any callback is successful, the message is deleted in the (send _ err) fault tolerant table and the record will not be processed again the next time the polling task is started.
If the number of failed notifications for a record reaches the default number of repeated notifications, the message is deleted in the (send _ err) fault-tolerant table and the record will not be processed again the next time the polling task starts.
In the embodiment of the present invention, an asynchronous notification system may be implemented by corresponding hardware or software units, and each unit may be an independent software or hardware unit, or may be integrated into a software or hardware unit, which is not limited herein.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps of the embodiments described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation.
Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (10)
1. An asynchronous notification method, comprising the steps of:
the method comprises the following steps: the message sending component sends the target data acquired from the plurality of clients to the MQ cluster by calling an internal push service API (application program interface);
step two: when the message sending component fails to send the target data to the MQ cluster, the system writes the target data into a failure data table;
step three: when the message sending component successfully sends the target data to the MQ cluster, the message monitoring component pulls the target data in the MQ cluster;
step four: and when the URL address does not exist in the blacklist, the Notify notification component asynchronously notifies the target data to the user server.
2. The asynchronous notification method of claim 1, wherein before the message sending component sends the target data obtained from the source end to the MQ cluster by calling the internal push service API interface, the steps further comprise:
the messaging component obtains the target data from the plurality of clients.
3. The asynchronous notification method according to claim 2, wherein before the Notify notification component does not Notify the user server when there is a URL address in the blacklist, the steps further comprise:
manually configuring the blacklist in advance, and specifying a specific URL address which is not notified;
or the system automatically adds the blacklist list, and when the URL address meets the passing rule, the URL address is listed as the blacklist.
4. The asynchronous notification method of claim 3, wherein after the Notify notification component asynchronously notifies the user server of the target data, the method further comprises:
the message monitoring component checks whether the URL address is in a failure data table;
when the URL address is checked to be in the failure data table, resetting the recorded failure times;
when the check URL address is not in the failure data table, no operation is performed.
5. The asynchronous notification method of claim 3, wherein after the Notify notification component asynchronously notifies the user server of the target data, the method further comprises:
when the Notify notification component asynchronously notifies the user server of the target data failure, the message monitoring component captures a failure message notification corresponding to the target data.
6. The asynchronous notification method of claim 5, wherein the message listening component captures a failure message notification corresponding to the target data, and further comprising:
when the number of times of the failure message notification is the first time, writing the URL address corresponding to the failure message notification into the notification failure table, and +1 the number of times of the failure message notification;
and when the number of times of the failure message notification is not the first time, directly adding +1 to the number of times of the failure message notification.
7. The asynchronous notification method of claim 5, wherein the message listening component captures a failure message notification corresponding to the target data, and further comprising:
a snoop message retry mechanism is initiated and repeated 5 times by default.
8. An asynchronous notification method according to claim 2, wherein after the system writes the target data into the failure data table, the steps further comprise:
and querying the failure data table by adopting an Elastic Job distributed timing mode.
9. An asynchronous notification method according to claim 3, wherein after querying said failure data table using Elastic Job distributed timing, said steps further comprise:
and calling the Notify notification component to asynchronously Notify the user server of the target data inquired from the failure data table.
10. An asynchronous notification system, the system comprising:
the sending unit is used for sending the target data acquired from the plurality of clients to the MQ cluster by the message sending component by calling an internal push service API (application program interface);
the writing unit is used for writing the target data into a failure data table by the system when the message sending component unsuccessfully sends the target data to the MQ cluster;
the pulling unit is used for pulling the target data in the MQ cluster by the message monitoring component when the message sending component successfully sends the target data to the MQ cluster;
and the notification unit is used for asynchronously notifying the target data to the user server by the Notify notification component when the URL address does not exist in the blacklist list.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011065831.9A CN112199212A (en) | 2020-09-30 | 2020-09-30 | Asynchronous notification method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011065831.9A CN112199212A (en) | 2020-09-30 | 2020-09-30 | Asynchronous notification method and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112199212A true CN112199212A (en) | 2021-01-08 |
Family
ID=74013666
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011065831.9A Pending CN112199212A (en) | 2020-09-30 | 2020-09-30 | Asynchronous notification method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112199212A (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040193653A1 (en) * | 2003-03-28 | 2004-09-30 | Howard Robert M. | Systems and methods for employing a trigger-based mechanism to detect a database table change and registering to receive notification of the change |
| CN104731912A (en) * | 2015-03-24 | 2015-06-24 | 浪潮集团有限公司 | Message transmission method and device for message middleware MQ |
| CN106713226A (en) * | 2015-11-12 | 2017-05-24 | 卓望数码技术（深圳）有限公司 | Remote procedure call processing method used for distributed system and remote procedure call processing system thereof |
| CN109660617A (en) * | 2018-12-18 | 2019-04-19 | 中电科华云信息技术有限公司 | A kind of information push method based on server cluster |
| CN110377433A (en) * | 2019-06-04 | 2019-10-25 | 威富通科技有限公司 | Asynchronous notification method, device and payment gateway, the storage medium of payment result |
-
2020
- 2020-09-30 CN CN202011065831.9A patent/CN112199212A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040193653A1 (en) * | 2003-03-28 | 2004-09-30 | Howard Robert M. | Systems and methods for employing a trigger-based mechanism to detect a database table change and registering to receive notification of the change |
| CN104731912A (en) * | 2015-03-24 | 2015-06-24 | 浪潮集团有限公司 | Message transmission method and device for message middleware MQ |
| CN106713226A (en) * | 2015-11-12 | 2017-05-24 | 卓望数码技术（深圳）有限公司 | Remote procedure call processing method used for distributed system and remote procedure call processing system thereof |
| CN109660617A (en) * | 2018-12-18 | 2019-04-19 | 中电科华云信息技术有限公司 | A kind of information push method based on server cluster |
| CN110377433A (en) * | 2019-06-04 | 2019-10-25 | 威富通科技有限公司 | Asynchronous notification method, device and payment gateway, the storage medium of payment result |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113742107B (en) | Processing method for avoiding message loss in message queue and related equipment | |
| CN111030784A (en) | Information synchronization method and device | |
| WO2013078689A1 (en) | Method and device for realizing message transfer in cloud message service | |
| CN112328418B (en) | Method and system for improving MQ synchronization reliability | |
| CN111277639A (en) | Method and device for maintaining data consistency | |
| CN104853138A (en) | Video conference network monitoring method, server and client | |
| CN105472024A (en) | Cross-region data synchronizing method based on message pushing mode | |
| CN101938374A (en) | System performance monitoring and alarming method and system | |
| CN111416823A (en) | Data transmission method and device | |
| CN109684128B (en) | Cluster overall fault recovery method of message middleware, server and storage medium | |
| CN112751743B (en) | Message sending exception processing method, message sending device and electronic equipment | |
| CN112199212A (en) | Asynchronous notification method and system | |
| CN111259032A (en) | Service processing method and device | |
| CN111049730A (en) | RabbitMQ message retransmission and power of consumption idempotent solution method | |
| CN115544034A (en) | Data consistency method and service system | |
| CN110442461A (en) | A kind of message dilivery method, storage medium | |
| CN111625323A (en) | Distributed task processing method, device, equipment and computer readable storage medium | |
| CN115964133A (en) | Message management method, device, equipment and storage medium | |
| US20090106781A1 (en) | Remote call handling methods and systems | |
| CN114490188A (en) | Method and device for synchronizing main database and standby database | |
| CN115509769A (en) | Kafka deployment method and device in private cloud and electronic equipment | |
| CN112468598A (en) | Method for realizing message compensation pushing based on AMQP protocol | |
| CN114884906A (en) | Failure retry notification method and device based on quick recovery | |
| CN112181688A (en) | Large-batch data processing method and system based on Rockettmq middleware | |
| CN114007111B (en) | Resource distribution method, device, electronic equipment and 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 |